Переписать или починить?

Question

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

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

Answer 1

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

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

Такие инструменты, как javadoc или doxygen, если они еще не используются, также могут помочь улучшить документирование и понятность кода.

Аргументы против полного переписывания довольно сильны. Те тонны «маленьких ошибок» и поведения, которые были закодированы в течение времени исходного проекта, снова проникнут обратно.

Answer 2

Это действительно зависит от того, насколько это плохо.

Если это небольшая система, и вы ее полностью понимаете, то переписывание не сумасшедшее.

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

Очки для рассмотрения:

• Если это выглядит хорошо для пользователя, они не волнует, что за спагетти беспорядок это для вас. С другой рука, если это плохо для них тоже, то легче договориться (и терпения).
• Если вы переписываете, попробуйте сделать это один часть за один раз. Грязный, неорганизованная кодовая база может сделать это сложно (т.е. заменить только один часть требует переписать большой айсберги кода зависимости), но если возможно, это делает это намного проще постепенно переписать и получить обратная связь с пользователями по пути.

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

Answer 3

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

Смотри также: Большой комок грязи

Answer 4

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

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

Answer 5

Ремонт, а главное, рефакторинг. И потому, что Джоэл сказал так , а также потому, что, если это ваш код, вы, вероятно, узнали намного больше вещей, так как последний раз касались этого кода. Если вы написали его в .NET 1.1, вы можете обновить его до 3.5 SP1. Вы можете войти и очистить весь старый закомментированный код. Вы в 100 раз лучше как разработчик, чем когда вы впервые написали этот код.

Единственное исключение, которое я думаю, это когда в коде используются действительно устаревшие технологии - в этом случае вам лучше будет написать новую версию. Если вы смотрите на какое-то приложение VB6 с 10 000 строк кода с бэкэндом базы данных Access, явно созданным кем-то, кто мало знал о том, как работают базы данных (что вполне могло бы быть вами восемь лет назад), то вы, вероятно, можете потянуть быстрее, на C # / SQL решение за долю времени и кода.

Answer 6

Выпускается новая книга, Разработка приложений Brownfield в .NET от Baley и Belcham. Первая глава является бесплатной, и в ней рассматриваются эти вопросы с точки зрения, в основном, независимой от платформы.

Answer 7

Одной из причин переписывания на одной из моих предыдущих работ была неспособность найти разработчиков с достаточным опытом для работы с исходной базой кода.

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

Я еще не слышал, как это получилось:)

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

Мы можем восстановить с нуля!

Мы все сделаем правильно на этот раз !

и т.д.

Answer 8

Рефакторинг, если это действительно очень плохо.

Джоэл может многое сказать по этому поводу ...

Как минимум, переписать код со старым кодом перед вами, а не просто начинать заново. Старый код может быть ужасным, но так оно и есть по причине, и если вы проигнорируете его, вы в конечном итоге увидите те же ошибки, которые, возможно, были исправлены много лет назад в старом коде.

Answer 9

Я настоятельно рекомендую прочитать "Эффективная работа с устаревшим кодом" Майкла Фезерса. Это тренерский совет о том, как реорганизовать ваш код, чтобы он мог тестироваться модулем.

Answer 10

В зависимости от вашей ситуации, у вас может быть другой вариант: сторонний код, указанный в лицензии.

Я консультировался в нескольких компаниях, где это было бы разумным выбором, хотя, казалось бы, «выбрасывание ИС» может стать большим барьером для управления. В моей нынешней компании мы серьезно рассмотрели возможность использования стороннего кода для замены нашей базовой инфраструктуры, но в конечном итоге эта идея была отвергнута не по техническим причинам, а по техническим причинам.

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