В какой точке рефакторинг становится не стоящим того?

У меня не было большой удачи с небольшими возрастающими изменениями, когда код, который я наследовал, действительно плох. В теории небольшой поэтапный подход звучит хорошим, но на практике все, с чем это заканчивается, является лучшим, но все еще плохо разработанным приложением, что все думают, теперь ВАШ дизайн. Когда вещи повреждаются, люди больше не думают, что это из-за предыдущего кода, это теперь становится ВАШИМ отказом. Так, я не использовал бы модернизацию слова, осуществил бы рефакторинг или что-либо еще, что подразумевает к типу менеджера, что Вы изменяете вещи на свой путь, если я действительно не собирался сделать это мой путь. Иначе, даже при том, что Вы, возможно, решили десятки проблем, любые проблемы, которые все еще существовали (но не были обнаружены) теперь будут приписанными Вашему переделывать. И уверьте, что, если код плох затем, Ваши меры раскроют намного больше ошибок, которые были просто проигнорированы прежде, потому что код был так плох для начала.

Если Вы действительно знаете, как разработать программные системы затем, я сделал бы модернизацию целой системы. Если Вы ДЕЙСТВИТЕЛЬНО не знаете, как разработать программное обеспечение GOOD затем, я сказал бы, что палка с небольшими возрастающими изменениями, поскольку можно иначе закончить с кодовой базой, которая так же плоха как оригинал.

Одна ошибка, которая часто делается, когда перепроектирование состоит в том, что люди игнорируют исходную кодовую базу. Однако модернизация не должна означать, полностью игнорируют старый код. Старый код все еще должен был сделать то, что должен сделать Ваш новый код, таким образом, во многих случаях шаги, в которых Вы нуждаетесь, уже находятся в старом коде. Копия и Вставка затем настраивают, творит чудеса при перепроектировании систем. Я нашел, что во многих случаях, перепроектируя и переписывая приложение и крадя отрывки из исходного кода намного более быстро и намного более надежен, чем небольшие возрастающие изменения.

Никакой документ, никакое исходное устройство записи, никакой тестовый сценарий и набор остающихся ошибок.

Одна опция состояла бы в том, чтобы записать модульные тесты, чтобы покрыть существующее приложение и затем начать осуществлять рефакторинг его поразрядно, с помощью модульных тестов, чтобы удостовериться, что все работает как прежде.

В идеальном мире у Вас уже были бы модульные тесты на программу, но, учитывая Ваши комментарии о качестве приложения я предполагаю, что Вы не делаете...

Дядя Bob взвешивается со следующим:

Когда модернизация является правильной стратегией?

Я рад, что Вы задали тот вопрос. Вот ответ. Никогда.

Посмотрите, Вы сделали путаницу, теперь очистите ее.

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

Приложение является спецификацией. Если Ваш переписывать его с нуля Вы, скорее всего, столкнетесь с большим количеством коварных ошибок, потому что "никто не знал, что вызов к этой функции, как предполагалось, возвратился 3 в том очень конкретном случае" (недокументированное поведение...).

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

В точке, где программное обеспечение не делает то, что это, как предполагается, делает. Рефакторинг (изменение кода, не изменяя функциональность) имеет смысл, если и только если функциональность "как предназначается".

Я работал с такими приложениями в прошлом. Лучший подход, который я нашел, является постепенным: Когда Вы работаете над кодом, найдите вещи, которые сделаны многократно, собирают в группу их в функциях. Сохраните ноутбук (Вы знаете, реальный, с бумагой, и карандашом или пером) так, чтобы можно было отметить успех. Используйте это в сочетании со своим VCS, не вместо него. Ноутбук может использоваться для обеспечения обзора новых функций, которые Вы создали как часть рефакторинга, и VCS, конечно, восполняет пробелы для деталей.

Со временем Вы консолидируете много кода в более соответствующие места. Дублирование кода в течение этого промежутка времени будет почти невозможным, так же просто сделайте это настолько лучше всего, как Вы можете, пока Вы не достигли точки, где можно действительно запустить процесс рефакторинга, аудит всей кодовой базы и работу над ним в целом.

Если у Вас есть недостаточно времени для того процесса (который займет очень долгое время), то, переписывая с нуля использование теста первый подход, вероятно, лучше.

Когда Вы проводите больше времени, осуществляя рефакторинг, чем на самом деле написание кода.

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

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

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

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

Robert L. Glass предлагает это

Модификация снова использованного кода особенно подвержена ошибкам. Если больше чем 20 - 25 процентов компонента должны быть пересмотрены, это более эффективно и продуктивно для записи этого с нуля.

Одно преимущество рефакторинга по восстановлению - то, что, ЕСЛИ можно сделать рефакторинг шаг за шагом, т.е. в инкрементах, можно протестировать инкременты в контексте целой системы, делая разработку и отладив быстрее.

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

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

Существует хорошая статья о сети о том, как Netscape 6 был записан с нуля, и это было бизнес-мудро плохая идея.

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