Как быстро проанализировать влияние изменения программы?
В последнее время мне нужно провести анализ влияния на изменение определения столбца БД широко используемой таблицы (например, PRODUCT, USER и т. Д.). Я считаю, что это очень трудоемкая, скучная и трудная задача. Я хотел бы спросить, есть ли какая-либо известная методология для этого?
Этот вопрос также относится к изменениям в приложении, файловой системе, поисковой системе и т. Д. Сначала я думал, что такого рода функциональные отношения должны быть предварительно задокументированы или как-то отслеживать, но потом я понимаю, что все может иметь изменения, это будет быть невозможно сделать это.
Я даже не знаю, что нужно пометить на этот вопрос, пожалуйста, помогите.
Извините за мой плохой английский.
3 ответа
В конечном итоге эта задача не может быть автоматизирована или сведена к алгоритму, в противном случае был бы инструмент для предварительного просмотра измененных изменений. Чем лучше вы написали код в начале, тем легче задача.
Позвольте мне объяснить, как достичь ответа: изоляция - это ключ. Сопоставление всего со свойствами объекта может помочь вам автоматизировать обзор.
Я могу привести вам пример. Если вам удастся сопоставить ваш конкретный случай с приведенным ниже, это спасет вам жизнь.
OR/M изменить шаблон
Как Hibernate или Entity Framework...
Изменения в столбце базы данных можно просто просмотреть, проанализировав, какой код использует свойство определенного объекта. Поскольку все столбцы БД сопоставлены со свойствами объекта, и при условии, что ни один код не использует чистый SQL, вы можете пойти на свои оценки
Это очень простой шаблон для управления изменениями.
Чтобы свести проблему файловой системы / сети или файла данных к описанному выше шаблону, вам понадобятся другие программные шаблоны. Я имею в виду, что если вы можете свести сложный сценарий к изменению свойств ваших объектов, вы можете использовать свою среду IDE для обнаружения изменений, в том числе кода, который нуждается в небольшом изменении для компиляции или должен быть переписан вообще.
- Если вы хотите управлять изменениями в удаленной службе, когда вы изначально пишете свое программное обеспечение, поместите эту службу в интерфейс. Так что вам останется только изменить его реализацию
- Если вы хотите управлять возможным изменением формата файла данных (например, длина изменения поля в позиционном формате, переупорядочение столбцов), напишите сервис, который отображает этот файл на объект (например, с помощью анализатора BeanIO)
- Если вы хотите управлять возможным изменением путей файловой системы, спроектируйте свое приложение так, чтобы оно использовало больше переменных времени выполнения
- Если вы хотите управлять возможным изменением алгоритмов шифрования, включите их в службы (например, HashService, CryptoService, SignService)
Если вы сделаете выше, ваш ручной обзор требований будет легче. Потому что общая задача - ручная, но с помощью автоматизированных инструментов. Вы можете попробовать изменить имя свойства класса и увидеть его побочные эффекты в компиляторе.
Худший случай
Очевидно, что если вам нужно изменить имя, тип и длину определенного столбца в базе данных в программном обеспечении с простым SQL-кодом, жестко закодированным и разбитым в нескольких местах кода, и, что еще хуже, во многих таблицах есть аналогичные именования столбцов, плюс без документации по проекту (сделал Я пишу наихудший случай, верно?) Из 10000+ классов, у вас нет другого пути, кроме как вручную исследовать свой проект, используя инструменты поиска, но не полагаясь на них.
И если у вас нет плана тестирования, который является документом, из которого вы можете надеяться создать набор программных тестов, настало время его составить.
Конечно. Технически, по крайней мере, можно узнать, какой код касается столбца БД (читает или записывает его), определяя фрагменты программы.
Методология: Найдите все элементы кода SQL в ваших источниках. Определите, какие из них касаются рассматриваемого столбца. (Осторожно: ВЫБРАТЬ ВСЕ может коснуться вашей колонки, поэтому вам необходимо знать схему). Определите, какие переменные читают или пишут этот столбец. Следуйте за этими переменными, куда бы они ни шли, и определяйте код и переменные, на которые они влияют; следуйте всем этим переменным тоже. (Это равносильно вычислению прямого среза). Аналогично, найдите источники переменных, используемых для заполнения столбца; следуйте за ними обратно к их коду и источникам, а также следуйте за этими переменными. (Это равносильно вычислению обратного среза).
Все элементы среза потенциально влияют / затрагиваются изменениями. В выбранном фрагменте могут быть условия, которые явно выходят за рамки условий, ожидаемых вашим новым вариантом использования, и вы можете исключить этот код из рассмотрения. Все остальное в срезах вы можете проверить / изменить, чтобы внести изменения.
Теперь ваше изменение может повлиять на какой-то другой код (например, на новое место для использования столбца БД или объединить значение из столбца БД с некоторым другим значением). Вы также захотите проверить верхний и нижний фрагменты кода, который вы изменяете.
Вы можете применить этот процесс для любых изменений, которые вы можете внести в базу кода, а не только в столбцы БД.
Вручную это не легко сделать в большой базе кода, и это, конечно, не быстро. Для кода C и C++ есть некоторая автоматизация, но не так много для других языков.
Вы можете получить неправильное приближение, запустив тестовые наборы, в которых участвует нужная вам переменная или действие, и проверив охват тестов. (Ваше приближение улучшается, если вы запускаете тестовые случаи, которые, как вы уверены, НЕ охватывают желаемую переменную или действие и исключают весь код, который он охватывает).
Просто добавляю мои 2 цента. Я предполагаю, что вы работаете в производственной среде, поэтому должны быть уже написаны модульные тесты, интеграционные тесты и системные тесты.
Если да, то хороший способ проверить ваши изменения - снова запустить все эти тесты и создать любые новые тесты, которые могут потребоваться.
И чтобы подчеркнуть очевидное, не интегрируйте изменения кода в основную базу производственного кода без выполнения этих тестов.
И снова изменения, которые работали нормально в тестовой среде, могут не работать в производственной среде. Иметь какую-либо форму системы управления конфигурацией исходного кода, такую как Subversion, GitHub, CVS и т. Д. Это позволяет вам откатить ваши изменения