Легаси-монстр. Как побеждаете?

Всем привет.

Есть очень большой проект на PHP, который писался разными командами и в разное время.
Проект начали писать, когда был еще PHP 5.1, многие хвосты тянутся оттуда.
По всему проекту встречаются SQL инъекции. Все лежит в разных файлах, автозагрузчика как такового нет, проект composer даже не нюхал. На сотни файлов ни одной строчки теста.

Я даже полностью понимая структуру проекта, хожу по нему как по минному полю. В этого монстра требуется внедрять фичи, которые хочет бизнес, но времени и ресурсов (людских) на переписывание этого кода нет, потому что переписывание это минимум 6 месяцев работы по 8 часов.

Что хочется: внедрить тестирование, избавится от SQL инъекций и причесать код.
Как вы это делаете?

Какой план у меня:
  • избавиться от SQL инъекций и перевести проект на PDO
  • избавиться от наследия PHP < 5.2
  • избавиться от echo в функциях, сделать чтобы функции возвращали результат одного типа
  • начать на эти функции писать выборочно тесты и после каждой фичи их прогонять.


Если это осилить, то можно переходить на компоненты (SF), но как сделать переход плавным?
И еще проблема: море мертвого кода, есть ли инструменты, которые помогут этот код найти?

В общем, у меня какой-то опыт есть, но я уверен, что здесь найду ответы более опытных разработчиков.
  • Вопрос задан
  • 4267 просмотров
Решения вопроса 1
@RidgeA
Немного банальностей:
1. Бизнес не даст ресурсов на переписывание проекта с 0: время и большие риски
2. Бизнесу как правило все-равно какое говно там крутится, лишь бы деньги приносило.
3. Если более-менее адекватное руководство - нужно донести идею постепенного рефакторинга кода по мере необходимости в процессе фикса багов и разработки новых фич и тем самым аргументировать что на разработку новых фич/фикс багов нужно больше времени.

Как я бы делал:
1. Тесты на существующие функции (если возможно, видел методы в контроллерах с мешаниной вызовов методов моделей, созданием DTO и сохранением их через репозиторий, прямых http-запросов и запросов в бд на 1000+ строк, покрыть такое тестами - невозможно)
2. Составить план рефакторинга, где отметить что и где надо сделать, коротко, в основном для команды разработчиков.
3. Постепенно рефакторить старый код по мере взаимодействия с ним.
4. Новый код - писать сразу правильно, для взаимодействия со старым кодом где нет возможности/времени его переделать - делать какие-то адаптеры, что бы не распространять токсичный код.
5. Как оперативная мера защиты от SQL иньекций можно поставить что-то вроде этого https://github.com/nbs-system/naxsi
6. Мониторинг кода, который не используется - pinba.org , по мере обнаружения такого кода - удалять безвозвратно (в крайнем случае есть VCS, я надеюсь). Начать с более высокоуровнего кода - контроллеры, напримерю. Плюс IDE в этом могут помочь и grep.
7. Как вариант - новые фичи можно пилить в отдельном проекте (v2), крутить оба и постепенно переходить на новый, со временем старый (v1) выкинуть (и начать делать новый - v3 :-) )
Ответ написан
Пригласить эксперта
Ответы на вопрос 12
saboteur_kiev
@saboteur_kiev
software engineer
Нынче удобный способ с вебсервисами.
Ищете функционал, который можно выделить в отдельный компонент, пишете компонент, в старом коде меняете API и перенаправляете на новый компонент.

Повторить до тех пор, пока от старого кода ничего не останется.

Но я соглашусь с RidgeA - бизнес не будет выделять на это деньги просто так.
Сперва нужно поработать над этим, убедить бизнес, что технический долг это не пустые слова и вы все ближе к блокеру, когда из-за сложности проекта все больше и больше вещей завязывается не на знания технологий, а на ключевых людей, которые просто знают нюансы проекта. Увольнение любого такого человека приводят к огромным рискам для проекта в целом. Предложить варианты, как это потихоньку будет убираться и потихоньку к этому идти.
Ответ написан
Комментировать
@MasterMike
Из вопроса не очень понятно, что именно составляет ваш интерес отрефакторить этот проект.

Если вы чисто по доброте душевной хотите помочь бизнесу, то не надо этого делать, иначе вы на своем личном опыте осознаете фразу "инициатива наказуема" )

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

1) Есть старый сервис, написанный еще на костылях с кучей всякого шлака. Он обрабатывает основную часть логики, его допиливают, дополняют и прочее.
2) Есть апи сервис на современном стеке, который постепенно забирает функционал от старого монстра.
3) Все новые задачи в приоритете ставятся на новый стек..

Так постепенно старое уходит, новое приходит. Но опять же, пока мы делаем апи на современном стеке, этот стек устаревает, и через какое-то время придется переписывать уже его.

Так можно поступать, если это it-компания.

Если это просто какая-то компания, которая не хочет инвестировать в софт, то альтруизмом лучше не заниматься, дополняйте старый стек и все. А потом все решит рынок, когда переписать проект будет проще, чем нанять спецов на его поддержку.
Ответ написан
Комментировать
@ijoy14
https://www.google.com/url?sa=t&source=web&rct=j&u...
Презентация реальной истории
Ответ написан
Комментировать
KevlarBeaver
@KevlarBeaver
Разработчик
Ваша работа, за которую вы получаете деньи, заключается в реализации необходимых бизнесу механизмов.

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

С другой стороны, - пытаться развивать паршивый код, - задача тоже не из приятных. А перепиливать его во внеурочное время - значит отнимать время и деньги у себя. Тратить на это часы, в которые начальство будет думать, что вы работаете над новым функционалом, - значит отнимать время и деньги у компании.

Иными словами, у вас два выхода. Либо позитивные моменты (зарплата там и прочее) перевешивают негатив - и вы просто живёте с той кодовой базой, которая есть. Либо перевешивают негативные моменты - и вы увольняетесь и идёте в ту компанию, где нет проектов с таким плохом кодом. Не нужно строить из себя робингуда и супермена в одном флаконе - в лучшем случае этого просто никто не оценит.
Ответ написан
@Levhav
Возьмусь за разработку проектов любой сложности.
  • Напишите интеграционные тесты эмулируя браузер в selenium или phantomjs
  • Возьмите инструмент для определения покрытия кода тестами.


И тогда получится отследить мёртый код. А ещё при правках живого кода вы будете знать что скорее всего хуже не стало.
Ответ написан
Комментировать
@nvdfxx
Senior Pomidor developer
Ну на устранение sql инъекций бизнес-то ресурсы должен выделить, как никак безопасность проекта, а там можно и потихоньку переписать для начала модули, которые за эти инъекции ответственны, затем рассказать тру стори про тех. долг и допереписать остальное. А про комментарии о микросервисной архитектуре - это, конечно, стильно, модно и молодежно, но никто не делает микросервисы на модулях из легаси кода. Вообще безотказная система для этого должна быть
Ответ написан
Комментировать
dmitriylanets
@dmitriylanets
веб-разработчик
1. создание прототипа системы с архитектурой решающей текущие проблемы
2. переезд на новую архитектуру с использованием адаптеров, паттернов позволяющих адаптировать старый функционал под новый.
3. Написание нового функционала в новом стиле, старого функционала переработка через рефакторинг,(выкидываем внутрянку без изменения внешнего поведения)
Ответ написан
Комментировать
@JohnnyMnemonik
Как правило построить новый проект с нуля легче чем пытаться исправить то что есть.

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

PS: SQL инъекция это непосредственно запрос извне. А в вашем случае это SQL уязвимость или недостаточная фильтрация переменных
Ответ написан
Комментировать
iCoderXXI
@iCoderXXI
React.JS/FrontEnd engineer
С нуля переписывать не дудат, т.к. люди которые принимают решения даже близко не подозревают, какой навоз тлеет там в коде в этих авгиевых конюшнях. Для них все просто - работает, значит норм.

Лично я использовал в php проектах чудесную библиотеку котерова DBSimple, вопрос инъекций решает на корню, при этом используются практически те же самые запросы.

Совсем не переписывать, скорее всего, не получится. Нужно настаивать, что часть кода все же требуется рефачить в обязательном порядке, иначе реализация фич просто невозможна совсем, либо отвалится много где и много чего в процессе.
Ответ написан
Комментировать
customtema
@customtema
arint.ru
Для начала документируйте бизнес-логику. Качественно, подробно так, с чувством.

Потом возвращайтесь к оценкам. Что-то мне подсказывает, что "с нуля" при современном инструментарии уложится в месяц работы, включая тестирование и симпатичный дизайн.
Ответ написан
Комментировать
gaparchi
@gaparchi
У Александра Бындю не плохая статья на эту тему https://blog.byndyu.ru/2014/01/blog-post_8.html
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы