Как утвердить это, Рефакторинг равен первоначальному кодексу

Вы идете вниз по скользкому склону, если вы думаете, что вы можете обнаружить, что от Eye-Bearing программа. И, как уже говорил один из других респондентов, вопрос о том, являются ли две программы равны неразрешены (на машине Turging).

Если у вас нет тестов подразделений, я предлагаю вам хотя бы настроить регрессионный ремень жгут. Снимок какого-либо ввода и некоторая выходная версия 1 программы принимает / производит, запустить ее через версию два и убедиться, что результаты одинаковы.

Если это GUI, я надеюсь, что он имеет разделение MVC, поэтому вы можете проверить модель отдельно, в противном случае вы можете застрять.

. верхний предел). Но я боюсь, что создание такой программы гораздо сложнее, чем писать модульные тесты для программы A, что вы должны действительно сделать.

Я все равно хотел бы сказать «запустить ваши агрегаты»;). Единственный вариант, который вы должны быть уверены, что результат такой же, является неизменной. Вы можете добавить их сами перед рефактором конкретного кода. Занимает больше времени в начале, но сэкономит вам много времени в долгосрочной перспективе.

Я боюсь сказать, что нет такой вещи, как алгоритм, который может подтвердить, что программа семантически идентична другой программе - она ​​вроде бывает проблема, а также это доказано неразрешимо.

Еще один немного более автоматизированный метод будет сравнивать выходы из обеих программ. Тем не менее, это может быть трудно для любой большой программы, так как там, вероятно, не имеет четко определенного входного диапазона ...

Возможно, его время вы написали тесты подразделения, которые вы найдете, так что не хватает?

Редактировать: Учитывая, что вы принимаете человека Алгоритмы - это то, что я обычно делаю. Я бы изучил код, который будет повторно, и понять его семантику. Напишите хотя бы тест на единицу или какой-то автоматический тест для этой части базы кода. Выполните рефактор, затем посмотрите, проходит ли тест. Если это так, у вас есть хороший шанс, что рефакторист (*) ничего не нарушил.

(*) Здесь я имею в виду рефакторов, чтобы меняться внедрение / алгоритм и т. Д., Не просто простой переименовать и перенаправить код и делать общие строки кода в методы / базовые классы и т. Д. Те, кто может почти глазное яблоко, при условии, что у вас есть Хорошее понимание базы кода.

Я бы пошел С ответом Итай, но просто давая еще один вариант.
Если вы готовы заплатить за это, есть продукт из Agitar , который автоматически генерирует тесты JUnit для существующего кода. Эти тесты - это тесты «Характеристики», которые предназначены для проверки кода, что он делает в настоящее время. Затем, как только вы вносите изменения, вы можете увидеть, какие перерывы вы хотели только измениться.

Доступна дополнительная информация здесь .

Я сделал следующее в проекте с некоторыми огромными классами Бога с необходимостью рефакторинга:

Используйте AOP, чтобы «давить» состояние вашего объекта и параметры в начале вашего метода и в конце. Сбросьте возвращаемое значение тоже.

Затем запишите множество сценариев с кодом, который вам необходимо изменить, и воспроизвести их, используя свой повторный код.

Это не математическое, это немного тяжело, чтобы настроить, но после того, как вы получите хороший набор не регрессионных тестов.

Дампер легко настроить с помощью инструмента, такого как xstream.

Вопрос: Как я могу подтвердить рефакторинг, то есть математический идентичный предыдущей версии? Хотелось бы, чтобы там был инструмент, но я также принимаю «основные человеческие алгоритмы» в качестве решений.

Я согласен с CHII, что это исключенно невозможно. Если вам действительно нужно решить его (вместо того, чтобы написать адаптер для устаревшего кода, создавая новое вещество свободно связанным со старым кодом), вы должны взять особо уход за подклассами, переопределенными методами и т. Д. Написание модулей, которые могут помочь, но Если вы на самом деле не знаете, что должен делать код, как вы можете написать тесты подразделения для него? Вы можете написать только тесты подразделений, чтобы убедиться, что новый код делает то, что вы предполагаете, что старый код сделал.

Вопрос: как я могу подтвердить рефакторинг, это математическое идентично предыдущей версии? я Желаю было инструмент, но я тоже принять «основные человеческие алгоритмы» как решения.

Строго говоря, рефакторинги являются набором известных преобразований, которые были доказаны для сохранения семантики кода. См. Ориентированные объектно-ориентированные рамки . Все остальное следует назвать повторную разработку , но я согласен, что оба используются взаимозаменяемо.

Расчет о сохранности семантики - это сложно, и является открытой темой исследования. См. Например, Формализация преобразований программных преобразований поведения .

До тех пор, пока у нас не будет эффективным инструментом, чтобы проверить семантическое сохранение, лучшее в самом деле, на самом деле полагаться на тестирование . Другой подход, чтобы получить больше уверенности в ваших изменениях, было бы добавление утверждений и контрактов . Это заставит вас сделать обзор и подумать о том, что могло изменить, каковы инварианты, что может быть сломано более глубоко.

Я немного удивлен, что до сих пор никто не упомянул книгу Майкла Фезерса Эффективная работа с устаревшим кодом . Он имеет дело с этой конкретной ситуацией с множеством практических советов на разных языках. Я рекомендую его всем, кто занимается устаревшими проектами.