Скажите, что у вас есть программа, которая в настоящее время функционирует так, как предполагается. Приложение имеет очень плохой код позади него, ест много памяти, является незаменимым и потребует серьезной перезаписи для реализации любых изменений в функциональности.В какой момент рефакторинг становится не стоит?
В какой момент рефакторинг становится менее логичным, чем полная перестройка?
Джоэл написал хорошую статью об этой самой теме:
Things You Should Never Do, Part 1
Ключевой урок, который я получил от этого является то, что хотя старый код ужасно, болит ваши глаза и эстетическое чувство, есть довольно хороший шанс, что многие из этого кода исправляют недокументированные ошибки и проблемы. То есть, у него есть много знаний о домене, встроенных в него, и вам будет сложно или невозможно воспроизвести его. Вы будете постоянно борется с ошибками.
Книга, которую я нашел очень полезной, - Working Effectively With Legacy Code от Michael C. Feathers. Он предлагает стратегии и методы для приближения даже к действительно уродливому устаревшему коду.
Когда вы тратите больше времени на рефакторинг, чем на самом деле написание кода.
Одним из вариантов было бы написать модульные тесты для покрытия существующего приложения, а затем начать рефакторинг поэтапно, используя модульные тесты, чтобы убедиться, что все работает по-прежнему.
В идеальном мире вы бы уже есть модульные тесты для программы, но, учитывая ваши комментарии о качестве приложения Я предполагаю, что вы не ...
В точке, где программное обеспечение не делает того, что он должен делать. Рефакторинг (изменение кода без изменения функциональности) имеет смысл тогда и только тогда, когда функциональность «по назначению».
Ну, самый простой ответ: если рефакторинг займет больше времени, чем потребуется для восстановления, тогда вам нужно просто перестроить.
Если это персональный проект, вы можете его перестроить, так как вы, вероятно, узнаете больше о строительстве с нуля, чем от рефакторинга, и это одна из главных целей личных проектов.
Тем не менее, в профессиональной среде с ограниченным временем работы вы всегда должны пойти с любыми затратами компании на наименьшую сумму денег (для той же выплаты) в долгосрочной перспективе, что означает выбор времени, необходимого на меньшее.
Конечно, это может быть немного сложнее, чем это. Если другие люди могут работать над функциями при выполнении рефакторинга, то это может быть лучшим выбором, поскольку все ждут создания совершенно новой версии. В этом случае восстановление может занять меньше времени, чем , только рефакторинг был бы занят, но вам нужно взять весь проект и всех участников проекта в учетную запись.
Я работал с такими приложениями в прошлом. Лучший подход, который я нашел, является постепенным: когда вы работаете над кодом, находите вещи, которые выполняются несколько раз, группируйте их вместе в функции. Держите ноутбук (знаете, настоящий, с бумагой, карандашом или ручкой), чтобы вы могли отметить свой прогресс. Используйте это в сочетании с вашим VCS, а не вместо него. Ноутбук можно использовать, чтобы предоставить обзор новых функций, которые вы создали как часть рефакторинга, а VCS, конечно, заполняет пробелы для деталей.
Со временем вы укрепили бы много кода в более подходящие места. Копирование дублирования в течение этого периода времени будет практически невозможным, поэтому сделайте это как можно лучше, пока не достигнете точки, где вы можете действительно запустите процесс рефакторинга, проверив всю базу кода и работая над это в целом.
Если у вас недостаточно времени для этого процесса (это займет очень много времени), то переписывание с нуля с использованием первого подхода, вероятно, будет лучше.
Если вы можете позволить себе полностью перестроить приложение, не нужно постепенно увеличивать функциональность и не хотите сохранять какой-либо существующий код, тогда переписывание, безусловно, является жизнеспособной альтернативой. С другой стороны, вы можете использовать рефакторинг для инкрементного переписывания, медленно заменяя существующие функции эквивалентными функциями, которые лучше написаны и более эффективны.
Одним из преимуществ рефакторинга по перестройке является то, что если вы можете выполнять рефакторинг шаг за шагом, то есть с шагом, вы можете протестировать приращения в контексте всей системы, ускоряя разработку и отладку.
Старый и развернутый код, даже когда он уродливый и медленный, имеет преимущество в том, что он был тщательно протестирован, и это преимущество теряется, если вы начинаете с нуля.
Поэтапный метод рефакторинга также помогает гарантировать, что всегда имеется продукт, который можно отправить (и он постоянно совершенствуется).
В Интернете есть хорошая статья о how Netscape 6 was written from scratch and it was business-wise a bad idea.
Если приложение очень мало, вы можете переписать его с нуля. Если приложение велико, никогда не делайте этого. Перепишите его постепенно, шаг за шагом, проверяя, что вы ничего не сломали.
Приложение - это спецификация. Если вы переписываете это с нуля, скорее всего, вы столкнетесь с множеством коварных ошибок, потому что «никто не знал, что вызов этой функции должен был вернуть 3 в этом конкретном случае» (недокументированное поведение ...).
Всегда интересно переписывать с нуля, чтобы ваш мозг мог обмануть вас в мысли, что это правильный выбор. Будьте осторожны, скорее всего, нет.
Нет документа, нет оригинального автора, нет тестового примера и кучу оставшихся ошибок.
Uncle Bob weighs in со следующим:
Когда редизайн правильной стратегии?
Я рад, что вы задали этот вопрос. Вот ответ. Никогда.
Посмотрите, вы сделали беспорядок, теперь очистите его.
Мне не повезло с небольшими инкрементальными изменениями, когда код, который я наследую, действительно плох. Теоретически небольшой пошаговый подход звучит неплохо, но на практике все, что у него получается, - это лучшее, но все же плохо разработанное приложение, которое все думают, это ВАШ дизайн. Когда что-то ломается, люди больше не думают, что это из-за предыдущего кода, теперь он становится ВАШЕЙ ошибкой. Таким образом, я бы не использовал слово redesign, refactor или что-нибудь еще, что подразумевает менеджер типа, что вы меняете вещи на свой путь, если я не собираюсь делать это по-своему. В противном случае, несмотря на то, что у вас могут быть исправлены десятки проблем, все проблемы, которые все еще существуют (но не были обнаружены), теперь будут отнесены на вашу доработку. И будьте уверены, что если код плохой, ваши исправления откроют намного больше ошибок, которые были просто проигнорированы раньше, потому что код был настолько плохим для начала.
Если вы действительно знаете, как разработать программные системы, тогда я бы сделал редизайн всей системы. Если вы НЕ НАСТОЯТЕЛЬНО не знаете, как разработать ПО GOOD, тогда я бы сказал, что придерживаюсь небольших инкрементных изменений, поскольку в противном случае вы можете получить базу кода, которая так же плоха, как и оригинал.
Одна ошибка, которая часто возникает при перепроектировании, заключается в том, что люди игнорируют исходную базу кода. Однако, редизайн не должен означать полностью игнорировать старый код. Старый код по-прежнему должен был делать то, что должен сделать ваш новый код, поэтому во многих случаях требуемые шаги уже находятся в старом коде. Копирование и вставка затем настраивает чудеса при перепроектировании систем. Я обнаружил, что во многих случаях перепроектирование и переписывание приложения и кража фрагментов исходного кода намного быстрее и надежнее, чем небольшие инкрементные изменения.
Фред Брукс сказал, что «построить один, чтобы выбросить» - но он не использовал гибкие методы, и любая добавленная функциональность была задокументирована и понята, и поэтому можно было переписать без потерь. – 13ren
Не говоря уже о том, что ВСЕГДА больше информации, которую вам нужно реализовать, о которой вы не думали, когда вы набросали большой проект. –