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