Legacy. Путь здоровых изменений.

Как можно заметить, я немного заебался генерить картинки на одну и ту же тему, обещаю исправится в дальнейшем

Вот мы потихоньку и подошли к самому главному: что делать, если Вам досталось наиболее классическое legacy в виде эволюционирующей системы в Вашем стеке технологий?

Я вижу два развития событий:
1️⃣ У Вас до жопы времени и никто не торопит с внедрением новых фич
2️⃣ Новые фичи бизнес хочет каждый день. Ну или через день.

В первом случае Вам ничего не мешает оставить работающую систему как есть и строить рядом новую. Вперед. Отличный вариант.
Во втором Вам придется выполнять доработки на лету.

Но. Придерживайтесь следующих шагов
👉Выделите функциональность системы, которая напрямую связана с новой задачей. Вот прям напрямую. Не зависит, не является основанием. Упрощая: вам надо изменить цвет кнопки с зеленого на красный. Это влияет только на кнопку. Кнопка – это та область функциональности, которую мы хотим поменять. Ничего не должно измениться в работе системы ни до появления кнопки на пользовательском интерфейсе, ни после
👉Вы определяете все, что имеет отношение к данной функциональности: пользовательские интерфейсы, кодовую базу, структуру данных и вообще все, что приходит Вам в голову.
👉Для выделенной функциональности Вы начинаете заново создавать описание, начиная с бизнес-процесса. Вы выясняете все тонкости и нюансы.
👉К полученному описанию Вы относитесь как к обычной задаче: создаете план разработки, реализуете его настолько максимально, насколько это только возможно. Тут мы должны понимать, что не все изменения можно внести безопасно для всех. Если Вам кажется, что в таблицу БД необходимо добавить новые индексы, Вы должны учитывать, что их перестроение может занять прилично времени. Если у Вас есть какие-то коннекторы к изменяемой функциональности, озаботьтесь, чтобы публичные программные интерфейсы работали с теми же входящими параметрами и возвращали те же исходящие данные. Ну и так далее. Все более-менее очевидные вещи, о которых люди любят забывать в запале. И, разумеется, в рамках решения этой задачи Вы учитываете все те вещи, о которых мы говорили где-то ранее: документацию, правильные принципы проектирования и бла-бла-бла
👉Вы сравниваете все, что реализовывало эту функциональность ранее с тем, что у вас получилось. Удаляете то старое, что перекрывается новым. git merge, короче говоря. Все, только что вы избавились от целого куска legacy-кода.

Чем это лучше простого переписывания системы с нуля? Тем, что Вы фрагментируете работу над большой системой на логические куски в рамках ежедневных задач.
Чем это лучше простого допиливания новой фичи? Тем, что, если Вы создаете просто новую фичу посреди legacy-кода – скорее всего, вы просто создаете новый legacy-код.

Очевидно, что такой подход займет больше времени, чем просто «вставить костыль для новой фичи», но он не приведет к усложнению системы в дальнейшей поддержке, вы обрываете цепочку накопления legacy в отдельно взятой функциональности. И таким образом через некоторое время покроете нормальным кодом, документацией, тестами всю систему. И вот тут наступает дзен.

#медведьразмышляет #legacy