В какой момент рефакторинг становится не стоящим?
https://stackoverflow.com/questions/615614
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Скажем, у вас есть программа, которая в настоящее время работает так, как она должна. Приложение имеет очень плохой код, оно потребляет много памяти, не масштабируется и требует значительных изменений для реализации любых изменений в функциональности.
В какой момент рефакторинг становится менее логичным, чем полная перестройка?
Решение
Джоэл написал хорошее эссе на эту тему:
То, что вы никогда не должны делать, часть 1
Ключевой урок, который я получил от этого, заключается в том, что, хотя старый код ужасен, он наносит вред вашим глазам и вашему эстетическому чувству, но вполне вероятно, что большая часть этого кода исправляет недокументированные ошибки и проблемы. Т.е. в него встроено много знаний о предметной области, и вам будет трудно или невозможно воспроизвести его. Вы будете постоянно бороться с ошибками.
Книга, которую я нашел очень полезной, - Эффективная работа с устаревшим кодом , автор Michael. C. Перья. Он предлагает стратегии и методы для подхода даже к действительно уродливому унаследованному коду.
Другие советы
Одним из преимуществ рефакторинга по сравнению с перестроением является то, что ЕСЛИ вы можете выполнять рефакторинг шаг за шагом, то есть с приращениями, вы можете тестировать приращения в контексте всей системы, ускоряя разработку и отладку.
Старый и развернутый код, даже когда он уродлив и медленен, имеет преимущество в том, что он был тщательно протестирован, и это преимущество теряется, если вы начинаете с нуля.
Инкрементный подход к рефакторингу также помогает гарантировать, что всегда есть продукт, который можно отправить (и он постоянно совершенствуется).
В Интернете есть хорошая статья о том, как Netscape 6 был написан с нуля, и это было плохая идея для бизнеса .
Ну, самый простой ответ: если на рефакторинг потребуется больше времени, чем на восстановление, вам нужно просто восстановить.
Если это личный проект, то вы, возможно, захотите его перестроить, так как, вероятно, вы узнаете больше из сборки с нуля, чем из рефакторинга, и это одна из главных целей личных проектов.
Тем не менее, в профессиональной среде с ограниченным временем вы всегда должны идти на все, что обходится компании с наименьшей суммой денег (при той же выплате) в долгосрочной перспективе, что означает выбор того, что займет меньше времени.
Конечно, это может быть немного сложнее, чем это. Если другие люди могут работать над функциями во время проведения рефакторинга, то это может быть лучшим выбором, если все будут ждать создания совершенно новой версии. В этом случае для восстановления может потребоваться меньше времени, чем для всего лишь , которое потребовалось бы для рефакторинга, но необходимо принять во внимание весь проект и всех участников проекта.
Когда вы тратите больше времени на рефакторинг, чем на написание кода.
В тот момент, когда программа не делает то, что должна. Рефакторинг (изменение кода без изменения функциональности) имеет смысл тогда и только тогда, когда функциональность "соответствует назначению".
Если вы можете позволить себе время для полной перестройки приложения, не нужно постепенно улучшать функциональность и не хотите сохранять какой-либо существующий код, то переписывание, безусловно, является жизнеспособной альтернативой. С другой стороны, вы можете использовать рефакторинг для постепенного перезаписи, медленно заменяя существующие функции эквивалентными функциями, которые лучше написаны и более эффективны.
Если приложение очень маленькое, вы можете переписать его с нуля. Если приложение большое, никогда не делайте этого. Перепишите его постепенно, шаг за шагом, подтверждая, что вы ничего не сломали.
Приложение является спецификацией. Если вы переписываете его с нуля, вы, скорее всего, столкнетесь с множеством коварных ошибок, потому что «никто не знал, что вызов этой функции должен был вернуть 3 в этом очень специфическом случае». (недокументированное поведение ...).
Всегда веселее переписать с нуля, чтобы ваш мозг мог заставить вас думать, что это правильный выбор. Будьте осторожны, скорее всего, нет.
Я работал с такими приложениями в прошлом. Лучший подход, который я нашел, - постепенный: когда вы работаете над кодом, находите вещи, которые выполняются несколько раз, группируйте их вместе в функциях. Держите тетрадь (вы знаете, настоящую, с бумагой, карандашом или ручкой), чтобы вы могли отмечать свой прогресс. Используйте это в сочетании с вашим VCS, а не вместо него. Записную книжку можно использовать для обзора новых функций, созданных вами в ходе рефакторинга, и VCS, конечно, заполняет пробелы для деталей.
Со временем вы соберете много кода в более подходящие места. Дублирование кода в этот период времени будет практически невозможным, поэтому делайте это как можно лучше, пока не достигнете точки, когда вы можете действительно запустить процесс рефакторинга, проверяя весь кодовая база и работа над ней в целом.
Если у вас недостаточно времени для этого процесса (который займет очень много времени), то, вероятно, лучше переписать с нуля, используя тестовый подход.
весит дядя Боб со следующим:
Когда реорганизация является правильной стратегией?
Я рад, что вы задали этот вопрос. Вот и ответ. <Сильный> Никогда.
Послушай, ты устроил беспорядок, теперь убери его.
Один из вариантов - написать модульные тесты, чтобы охватить существующее приложение, а затем начать реорганизовывать его по крупицам, используя модульные тесты, чтобы убедиться, что все работает как прежде.
В идеальном мире у вас уже есть модульные тесты для программы, но, учитывая ваши комментарии о качестве приложения, я думаю, вы этого не сделаете ...
Нет документа, нет оригинального автора, нет контрольного примера и куча оставшихся ошибок.
Мне не очень повезло с небольшими добавочными изменениями, когда код, который я наследую, действительно плох. Теоретически, небольшой поэтапный подход звучит хорошо, но на практике все, чем он заканчивается, - это лучшее, но все еще плохо разработанное приложение, которое, как все думают, теперь является ВАШИМ дизайном. Когда вещи ломаются, люди больше не думают, что это из-за предыдущего кода, теперь это становится ВАШЕЙ ошибкой. Поэтому я бы не использовал слово «редизайн», «рефакторинг» или что-либо еще, что подразумевает под типом менеджера то, что вы меняете вещи по-своему, если я действительно не собирался делать это по-своему. В противном случае, даже если вы исправили десятки проблем, любые проблемы, которые все еще существовали (но не были обнаружены), теперь будут относиться к вашей переделке. И будьте уверены, что если код плохой, то ваши исправления обнаружат намного больше ошибок, которые раньше просто игнорировались, потому что код был настолько плох для начала.
Если вы действительно знаете, как разрабатывать программные системы, я бы сделал редизайн всей системы. Если вы не НАСТОЯЩИМ знаете, как проектировать ХОРОШЕЕ программное обеспечение, то я бы сказал, что нужно придерживаться небольших постепенных изменений, так как в противном случае вы можете получить кодовую базу, столь же плохую, как и оригинал.
Одна ошибка, которую часто делают при редизайне, заключается в том, что люди игнорируют исходную базу кода. Тем не менее, редизайн не должен означать полное игнорирование старого кода. Старый код все еще должен был выполнять то же, что и ваш новый код, поэтому во многих случаях необходимые вам шаги уже в старом коде. Скопируйте и вставьте, а затем настройте чудеса при перепроектировании систем. Я обнаружил, что во многих случаях перепроектирование и переписывание приложения и кража фрагментов из исходного кода намного быстрее и намного надежнее, чем небольшие постепенные изменения.
