Я уверен, что вы все были там, вы берете проект, где есть скрипучая старая кодовая база, которая едва ли подходит для цели, и вы должны принять решение либо переписать ее с нуля, либо восстановить то, что уже существует.
Традиционная мудрость, как правило, предполагает, что вы никогда не должны пытаться переписывать с нуля, поскольку риск неудачи очень высок. Итак, что вы сделали, столкнувшись с этой проблемой, как вы приняли решение и как это получилось?
Это действительно зависит от того, насколько это плохо.
Если это небольшая система, и вы ее полностью понимаете, переписывание не является безумным.
С другой стороны, если это гигантский унаследованный монстр с десятимиллионными линиями недокументированного тайного кода, то вам действительно нелегко будет с полной перезаписью.
Вопросы для рассмотрения:
Я бы очень стеснялся взять гигантский проект перезаписи для большой системы, не имея возможности выпускать новую редакцию по одной части за раз.
Просто очищайте код немного каждый раз, когда вы работаете с ним. Если его еще нет, настройте единый модуль тестирования. Весь новый код должен получить тесты. Любой старый код, который вы исправляете в результате ошибок, также пытайтесь сместить в тестах.
Как прогресс очистки, вы сможете сместить все больше и больше неприятного кода в инкапсулированные ячейки. Тогда вы можете выбрать их один за другим в будущем.
Инструмент, подобный javadoc или doxygen, если он еще не используется, также может помочь улучшить документацию и понятность кода.
Аргументы против полной перезаписи довольно сильные. Те тонны "маленьких ошибок" и поведения, которые были закодированы в течение временных рамок оригинального проекта, снова проскользнут обратно.
См. эссе Джоэла Спольского Вещи, которые вы никогда не должны делать. Итак, когда вы переписываете, вы теряете все уроки, которые вы научили, чтобы ваш текущий код работал так, как он должен работать.
Смотрите также: Большой шар грязи
Одной из причин перезаписи на одном из моих предыдущих заданий была невозможность найти разработчиков с достаточным опытом для работы с исходной базой кода.
Было принято решение сначала очистить базовую структуру базы данных, а затем переписать то, что облегчит поиск штатных сотрудников и/или подрядчиков.
Я еще не слышал, как это получилось:)
Я думаю, что люди склонны идти на переписывания, потому что это кажется более забавным на поверхности.
Мы восстанавливаем с нуля!
Мы сделаем это правильно на этот раз!
и др.
Редко можно переписать что-нибудь сложное для успеха. Это заманчивая, но низкая процентная стратегия.
Получить устаревший код в модульных тестах и реорганизовать его и/или полностью заменить небольшие его части по мере необходимости.
Появилась новая книга, Разработка приложений Brownfield в .NET от Baley и Belcham. Первая глава является бесплатной и говорит об этих проблемах в основном с точки зрения агностики платформы.
Рефакторинг, если это действительно очень плохо.
У Джоэля есть что сказать по этому поводу...
По крайней мере, перепишите код со старым кодом перед вами и не просто начинайте с нуля. Старый код может быть ужасным, но так оно и есть по какой-то причине, и если вы проигнорируете его, вы увидите те же ошибки, которые, вероятно, были исправлены несколько лет назад в старом коде.
В зависимости от вашей ситуации у вас может быть другой вариант: сторонний код в лицензии.
Я консультировался в нескольких компаниях, где это был бы разумный выбор, хотя, казалось бы, "отбрасывание IP" может стать большим препятствием для управления. В моей нынешней компании мы серьезно рассмотрели жизнеспособный вариант использования стороннего кода для замены нашей основной структуры, но эта идея в конечном счете была отклонена больше по причинам бизнеса, чем по техническим причинам.
Чтобы ответить на ваш вопрос, мы, наконец, решили переписать устаревшую структуру - решение, которое мы не приняли легкомысленно! 14 месяцев, мы не сожалеем об этом выборе вообще. Рассматривая время, затрачиваемое на исправление ошибок, наша новая структура почти заплатила за себя. С отрицательной стороны это не совсем полно, но мы находимся в незавидном положении, поддерживая параллельные параллельные структуры, пока мы не сможем перенести последние из наших "интерфейсных" приложений.
Восстановить или, что более важно, рефакторинг. И потому, что Джоэл сказал так, а также потому, что, если это ваш код, вы, вероятно, узнали тонну больше материала, так как вы коснулись этого кода последним. Если вы написали его в .NET 1.1, вы можете обновить его до 3.5 SP1. Вы заходите и очищаете весь старый прокомментированный код. Теперь вы на 100% лучше, чем разработчик, чем когда вы впервые написали этот код.
Единственное исключение, о котором я думаю, - это когда код использует действительно устаревшие технологии - в этом случае вам может быть лучше подано написание новой версии. Если вы посмотрите на какое-то приложение VB6 с 10 000 строк кода с бэкэндом базы данных Access, который, очевидно, настроен кем-то, кто мало знал о том, как работают базы данных (что вполне может быть вам восемь лет назад), тогда вы, вероятно, сможете от более быстрого решения на основе С#/SQL за долю времени и кода.
Это не так черно-белое... это действительно зависит от множества факторов (чем важнее то, что человек, который платит вам, хочет, чтобы вы это делали)
В тех случаях, когда я работаю, мы повторно создали структуру разработки, а с другой стороны, мы продолжаем модифицировать некоторые старые системы, которые нельзя перенести (из-за технологии клиента и ограничений по времени). В этом случае мы стараемся использовать стиль кодирования, и иногда вам приходится выполнять много обходных решений из-за того, как он был построен
Я настоятельно рекомендую прочитать "Эффективно работая с устаревшим кодом" Майкла Перса. Это тренерский совет о том, как реорганизовать ваш код, чтобы он мог тестироваться.