Когда переписать кодовую базу с нуля

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

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

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

Через некоторое время вы перенесете около 60% базы кода в использовать новые серверные части, не относясь к официальным проектам, а просто к обслуживанию, так что вы будете в лучшем положении, чтобы спорить о времени разработки, чтобы сделать остальные 40%, и как только это будет сделано, существующие классы интерфейса будут значительно уменьшены в размере и сложности.

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

По крайней мере, начинайте писать тесты немедленно.

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

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

Я не знаю, использовался ли когда-либо переработанный код - я ушел из компании до того, как у него появилась возможность полностью интегрироваться - но я сомневаюсь в этом. Зачем использовать двадцать строк кода, если полторы тысячи операторов if и трехстрочных регулярных выражений могут выполнять ту же работу?

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

• Windows NT (Отказ от старой кодовой базы DOS. На этой основе были построены Win2k, WinXP и будущая Win7. Да, тоже Vista. Последней версией Windows на старой базе была печально известная WinME)
• Mac OS X (перестроила свой флагманский продукт на FreeBSD)
• Много случаев, когда конкурент вытесняет стандарт де-факто. (например, Excel против Lotus 123)

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

На ум приходит только одна квазизаконная причина: политика.

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

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

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

Политика может быть огромной болью.

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

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

Политика может быть огромной болью.

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

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

Политика может быть огромной болью.

Политика может быть огромной болью.

Политика может быть огромной болью.

У меня было такое приложение, и переписывание было очень полезным. Однако вы должны попытаться избежать ловушки "улучшения".

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

Убедитесь, что вы заранее решили, что именно будет изменено, а что только переписано - .

В статье Джоэла действительно все сказано.

Практически никогда.

Как отмечает Джоэл: вы просто потеряете слишком много, делая это с нуля. Вероятно, это займет больше времени, чем вы думаете, и каков конечный результат? То, что в основном делает то же самое. Так в чем же экономическое обоснование для этого?

Это важный момент: написание чего-либо с нуля стоит денег. Как вы вернете эти деньги? Многие программисты игнорируют этот момент просто потому, что им не нравится код - иногда с оправданием, иногда нет.

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

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

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

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

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

Мой ответ: переписывайте с нуля как можно чаще .

Я провел большую часть своей карьеры, наследуя дымящиеся груды навоза, которые мы вежливо называем «программами» , написанные молодыми, неопытными программистами, которых менеджеры считали «рок-звездами». Эти вещи, как правило, невозможно исправить, и вы в конечном итоге тратите в 10 раз больше усилий, чтобы они хромали, чем вы бы потратили, просто переписывая их с нуля.

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

При этом не все перезаписи - хорошая идея. Например, Windows Vista.

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

Я был частью небольшой специальной группы, которая переписывала код с нуля, включая бизнес-правила обратного проектирования предыдущего кода. Первоначальное приложение было веб-службой, написанной на C ++ (с регулярными сбоями и серьезными утечками памяти), и веб-приложением ASP.Net 1.0, а заменой была веб-служба на основе asmx C # 2.0 и веб-приложение ASP.Net 2.0 с Ajax. Тем не менее, некоторые из вещей, которые команда сделала и объяснила руководству

1. Мы поддерживали существующую кодовую базу в производстве, пока не был готов новый код.
2. Руководство согласилось, что переписывание (первый выпуск) не будет вводить никаких новых функций, но просто реализуйте существующие функции. В конце мы добавили только 1-2 новых функции.
3. Небольшая команда состояла из очень опытных разработчиков, прекрасно понимающих и способных сотрудничать.
4. Было труднее найти специалистов по C ++ в организации, и C # рассматривался как лучшая альтернатива для будущего обслуживания.
5. Мы согласились на жесткие временные рамки, но в то же время были уверены и очень мотивированы работать с C # 2.0, ASP.Net 2.0 и т. Д.
6. У нас был руководитель группы, который оградил нас от высшего руководства, и мы следовали процессу схватки.

Проект был очень успешным. Это было очень стабильно и намного лучше. Позже было проще добавлять новые функции.

Проект оказался весьма успешным. Это было очень стабильно и намного лучше. Позже было проще добавлять новые функции.

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