Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 10
Закреплённые комментарии
Кратко
Идеи:
Зафиксировать контракты, которые нельзя менять изначально, затем добавлять контракты для разделения системы на слабо связанные части.
Переписать с нуля проще чем множеством итераций менять старый код, потому что тогда нужно понимать код, а это дорого.
Менять старый код дорого: цена близка к цене написания с нуля плюс суммарная стоимость сопровождения как накопления опыта и понимания edge cases. В случае реинжиниринга "от кода" это ещё и стоимость раскопок. Зато можно не добавлять стоимость владения и адаптации бизнеса.
Легаси переписать дорого не потому что он плохо написан, а потому что знания о системе неявные, размазаны по коду и спрятаны в "так исторически сложилось".
Если контракты зафиксированы, а знания извлечены, то переписывание выигрывает.
Речь про экономику и стратегию реинжиниринга. Сознаюсь, тут не так много рецептов как именно делать. Речь о том, стоит ли это делать вообще, выбрать ли
поверхностный рефакторинг
реинжиниринг "от кода" с тщательным следованием старой логике
реинжиниринг "от поведения" с идеальным ядром, адаптируя грязный легаси и посматривая на golden tests
отказаться от затеи по экономическим причинам
Встречал соотношение стоимости изменений 5:1 в разных проектах.
Число 500 (прописью: "пятьсот") с ошибкой написано.
P.S.: Ладно-ладно, такую дичь я всего лишь дважды вживую наблюдал. Один раз - в SCADA-системе, под управлением которой работали заводы в Германии, Канаде и Китае; вроде загнулась по итогу. Второй - крупный международный финтех, живущий и поныне; там ещё были классы в 65000 строк, методы в 2500 и строки, которые целиком помещались на 23"-экране только при масштабе 3%.
Очень классная статья. Затрагивает целый спектр проблем, связанных с легасм-кодом.
Как понять, что дешевле и удобнее сделать реинжениринг? Или проще написать проект с нуля на свежем техническом стейке, изредка просматривая в старый код и в старые постановки задач?
Ещё вопрос - как часто следует делать реинжениринг?
И как с помощью реинжениринга отследить ветки кода, которые уже больше не используются? В легаси проекте условно может быть до 30% кода, который вообще уже устарел и никогда не используется при обработке данных, так как что-то поменялось.
что дешевле и удобнее сделать реинжениринг? Или проще написать проект с нуля на свежем техническом стейке, изредка просматривая в старый код и в старые постановки задач?
И то и другое дорого. Стоимость примерно равна стоимости создания старой плюс стоимость её сопровождения и доработок за все годы.
Плюс рефакторинга
делается механически
старый конь борозды не испортит, но и глубоко не вспашет ©
Плюс реинжиниринга:
можно переписать только часть
можно смотреть на старый код и тестами проверять что поведение новой части в точности совпадает с поведением старой, даже если оно кажется странным, это не сломает контракты, интеграцию, пользовательский опыт
Плюс переписывания:
можно не тащить совместимость поведения, но пользователей переобучать, интеграцию проверять
требований меньше, код проще, иногда в разы
И как с помощью реинжениринга отследить ветки кода, которые уже больше не используются?
В общем случае никак. Если код не использовался нет гарантий что он не будет использоваться потом. Но если код отключили это видно: нет входящей цепочки вызовов.
Должен ли реинжинирингом заниматься другой специалист, а не тот программист/архитектор, который изначально делал проект? Реижиниринг требует особой квалификации, подготовки и опыта. Кроме того, привлечение другого программиста, который не писал этот проект позволит сделать взгляд со стороны на проект. Потому что обычно через какое-то время у программистов замыливаются глаза и они уже не видят очевидных проблем в проекте и думают, что и так сойдёт.
Во-вторых, чтобы заниматься реинжинирингом требуется наличие всесторонних компетенций - и архитектора, и девопса, и программиста, и аналитика. Так?
В-третьих, правильно ли я понимаю, что на время реинжиниринга вся разработка новых фичей полностью парализуется? Потому что нужно сначала переписать часть проекта, а уже потом писать новый функционал?
на время реинжиниринга вся разработка новых фичей полностью парализуется? Потому что нужно сначала переписать часть проекта, а уже потом писать новый функционал?
Нет.
Используйте паттерн фикус душитель
При подходе реинжиниринга потребуется также актуализировать и документацию на код? Это приведёт к удорожанию реинжиниринга.
Как решается вопрос с тем, что при реинжиниринге код всего проекта становится лоскутным - написанным с разным синтаксисом, разными людьми, с разными компетенциями и с разными требованиями к качеству кода?
Документация как обычно пишется по минимуму, только то что нельзя понять быстро из кода.
Я бы фиксировал прямо в коде переделанного модуля:
Требования / контракты
Принятые решения и их причины (ADR)
Общее описание (скорее всего, для изоляции от легаси придётся использовать гексагональную архитектуру, вот её и опишите: какой красивый домен и от какого страшного легаси снаружи защищают адаптеры)
Если для понимания кода пришлось вести тяжёлые раскопки, которые из кода сразу не были видны, это полезно документировать прямо по ходу раскопок. Чтобы снова на это усилия не тратить.
лоскутным
По принципу наименьшего удивления (minimum WTF/second) ревьювер вправе ожидать хороший и стабильный стиль от критичного (переделанного) кода, а некритичное выдавливается на периферию модуля и внимания.
Кратко
Идеи:
Зафиксировать контракты, которые нельзя менять изначально, затем добавлять контракты для разделения системы на слабо связанные части.
Переписать с нуля проще чем множеством итераций менять старый код, потому что тогда нужно понимать код, а это дорого.
Менять старый код дорого: цена близка к цене написания с нуля плюс суммарная стоимость сопровождения как накопления опыта и понимания edge cases. В случае реинжиниринга "от кода" это ещё и стоимость раскопок. Зато можно не добавлять стоимость владения и адаптации бизнеса.
Легаси переписать дорого не потому что он плохо написан, а потому что знания о системе неявные, размазаны по коду и спрятаны в "так исторически сложилось".
Если контракты зафиксированы, а знания извлечены, то переписывание выигрывает.
Речь про экономику и стратегию реинжиниринга. Сознаюсь, тут не так много рецептов как именно делать. Речь о том, стоит ли это делать вообще, выбрать ли
поверхностный рефакторинг
реинжиниринг "от кода" с тщательным следованием старой логике
реинжиниринг "от поведения" с идеальным ядром, адаптируя грязный легаси и посматривая на golden tests
отказаться от затеи по экономическим причинам
К переезду на другой фреймворк или стек тоже относится: мы должны не изменить поведение старой системы, не сломать внешние контракты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рефакторинг и реинжиниринг легаси