Критерии выбора рефакторинга вместо полной перезаписи
Я работаю над проектом, кодовая база которого насчитывает около 3500 файлов, возможно, на несколько сотен меньше, чем на самом деле. Этот проект выполнен на PHP и является довольно запутанным, в данном случае это означает, что документация сложна для понимания, ООП и процедурное программирование смешаны, зависимости неясны, и те, кто создал систему, где работают начинающие программисты со всем, что это влечет за собой.
Честно говоря, то, что они сделали, впечатляет, это рабочий продукт и все такое. Но отладка и добавление новых функций - это настоящая рутина.
Теперь к моему вопросу, каковы некоторые хорошие критерии того, следует ли нам реорганизовать весь проект или полностью переписать. Я должен упомянуть, что переписывать части системы по ходу работы, вероятно, не получится из-за того, что все взаимосвязано.
3 answers
Основными критериями, вероятно, будут время (= деньги).
Оценка всегда трудна, когда что-то большое. Разделите его на мельчайшие кусочки.
Учитывайте точку зрения. Ваша оценка, вероятно, будет отличаться от оценки предыдущих программистов, так как она будет зависеть от стиля, который вы предпочитаете. Возможно, лучшим выбором было бы нанять предыдущих программистов для "исправления" кода.
В любом случае, вы должны четко указать минимальные требования для вызова приложения написанный и простой в обслуживании, обсудите это с боссом и командой, разделите на минимально возможные спринты и оцените время, необходимое для всех из них.
Если вы сможете убедить своего босса в том, что переписывание приведет к повышению рентабельности инвестиций в целом, сделайте переписывание. В противном случае изучите "новый стиль". Если у вас есть возможность прекратить бизнес на время переписывания или свободное время для этого, вам повезло. Вам еще больше повезет, если код поддается тестированию или у вас есть хотя бы какой-то модуль тесты. Если это невозможно, вам следует внедрить функциональные тесты, по крайней мере, чтобы помочь в обоих случаях (рефакторинг или перезапись).
Обратите внимание, что каждый из нас, вероятно, предпочтет переписать с нуля, чем рефакторинговать. Затем перепишите это переписанное...
Таким образом, рефакторинг всегда является хорошим выбором, если у вас уже есть тесты или вы можете легко их реализовать.
Если приложение большое, успешное и делает интересные вещи, попытка переписать его вручную, скорее всего, потерпит неудачу. У перезаписи никогда не будет достаточной массы, чтобы вытеснить оригинал, и вы не можете выбросить оригинал, пока это не произойдет, а это означает, что вам придется продолжать улучшать оригинал до тех пор, пока замена не будет готова. Вдвое больше работы, никакой дополнительной ценности. Вероятно, вам гораздо лучше сохранить приложение и очистить его.
Вы могли бы рассмотреть два идеи, которые помогут уменьшить размер базы кода:
Запустите тестовое покрытие кода. Обычно люди используют это для проверки функциональности приложения, но если вы запустите тестовое покрытие и просто запустите код приложения в течение длительного периода времени, он сообщит вам, какой код не обработан и, следовательно, скорее всего, мертв. Если в системе беспорядок, в ней, скорее всего, много мертвого кода, и это простой способ найти кандидатов. Существуют инструменты тестового покрытия, которые могут собирайте данные по всему вашему приложению с минимальными накладными расходами; вы можете использовать их в производственном коде.
Запустите детектор клонов. Это позволит найти дубликат кода. Прямое дублирование легко удалить. Хороший детектор клонов обнаружит не просто идентичные клоны, но параметрические клоны, то есть код, который был скопирован/вставлен/отредактирован, но таким образом, чтобы его можно было суммировать с параметрами. Параметрические клоны требуют большей тонкости для удаления, но их обнаружение говорит вам о вероятном пропущенном абстракции, и удаление их (путем замены объектами или методами) вставляет эти отсутствующие абстракции в ваш код, облегчая дальнейшее обслуживание, связанное с этой идеей. (Это не очень известный факт, но удаление клонов также повышает уровень покрытия тестами, если вы действительно используете покрытие тестами для проверки функциональности!)
Если приложение уже работает и нет серьезных сбоев, то я бы оставил большую его часть такой, какая она есть, поскольку переписывать все с нуля всегда дорого.
Возможно, вам следует рассмотреть возможность уменьшения количества файлов/строк везде, где вы видите дублированный код, создающий объекты/функции, чтобы максимально централизовать все. Это очень помогает в конечном обслуживании и не требует большого количества времени для выполнения. Особенно, если это было написано, как вы говорите, новички, вы легко найдете "неправильные подходы" для совершенствования.