@dasauser
Пишу на PHP

Рефакторить или рерайтить?

Есть Легаси код а точнее просто куча кода, оставленная предыдущим разработчиком (неайти компания), в которой мне нужно разобраться и изменить некоторую логику.
Написана она без использования каких либо паттернов, или принципов проектирования (скрипты в одном файле, рекваеры, инклуды, использование переменные из другого файла, подключенных через инклуд-рекваер и т.п.).
Я, развращенный подобием ООП в PHP, тяжело понимаю эту текущую логику, и мне было бы проще все переписать, но бизнес требует.
И у меня возник такой вопрос: рефакторить или рерайтить?
С одной стороны рефакторинг даст мне опыт работы с таким кодом, и в будущем я смогу его изменять и поддерживать, не тратя на это столько же времени, сколько я потратил бы на рефакторинг.
С другой стороны, рерайтинг выглядит более простым решением, ведь проще строить дом с нуля, чем на кривом фундаменте (ну или как там в строительстве), но, возможно, ценой большего количества затраченного времени (ведь мне придется адаптировать и логику также), да и опыта работы с Легаси кодом у меня не прибавится.
Так как же быть?
  • Вопрос задан
  • 183 просмотра
Решения вопроса 2
gbg
@gbg
Любые ответы на любые вопросы
У вас будет проблема с тем, что на имеющийся быдлокод у вас нет ТЗ и описания того, как это чудо должно работать - вам придется восстанавливать это из кода.

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

Со стороны трудно оценить объем вносимых изменений - если это разовая работа, проще добавить в эту свалку костылей еще один и забыть как страшный сон.

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

Полный рерайт - это, возможно, остановка каких-то процессов на время рерайта. Маловероятно, что это допустимо.
Ответ написан
Комментировать
tumbler
@tumbler
бекенд-разработчик на python
Был подобный опыт, правда с собственным кодом.

Первая история:

Была поставлена задача в Красивую И Стройную Архитектуру пилить одну новую фичу. Фича в архитектуру не вписывалась. Варианты были или уродовать текущий код и сделать его ужасом, летящим на крыльях ночи, или аккуратно вырезать пол-проекта и заменить другой Красивой и Стройной. С товарищами посовещались и решили, что лучше ужас, чем десятикратное превышение по срокам. Ужас до сих пор живет )

Вторая история:

Другая Красивая и Стройная архитектура давным давно постарела и разжирела. Раз в неделю приходил очередной фичебред, который старательно нашлепывался сверху. В результате через 3 года проект был написан с нуля, на другом языке, другом фреймворке, с другими требованиями. До перезапуска проекта прошло полгода. И потом еще наверно года два аккуратного развития до состояния "как было".

Вот и думайте, есть ли у вашего начальства деньги на "переписать с нуля", или только на "потерю времени при работе с легаси".
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
dmitriylanets
@dmitriylanets
веб-разработчик
работает не трогай
Ответ написан
Есть ли у бизнеса время на переписывание проекта?
Насколько частые обновления предполагаются?

Будете ли вы делать текущие задачи по проекту во время переписывания?

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

При этому можно попытаться продать идею переписывания проекта.
Если поддержка будет дешевле и внедрение новых фич быстрее.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы