Работа с legacy-кодом - остановка в развитии или рост профессионализма?

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

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

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

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

Казалось бы, выхода нет. Однако можно посмотреть на это проблему под другим углом. Проекты и фреймворки меняются, но принципы работы с большими программами остаются неизменны. Это разбиение кода на мелкие модули, разделение кода на уровни согласно взаимодействию с внешней средой, а так же управление связями между отдельными элементами системы.

Я не рассматриваю сейчас простые работы со старой программой, заключающиеся в простом устранении багов или мелкие переделки верстки. Я рассматриваю задачи, когда программист должен работать над многолетним проектом, поддерживая и дорабатывая его, без возможности написать всё по новой в силу большого объёма функционала и огромного количества кода, переписать который невозможно в приемлемые сроки.

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

Программирование в этом случает перестаёт быть скучным. Работа по каждому из старых модулей превращается в искусство, где стоящие задачи могут решаться по лучшим методикам, предлагаемым такими известными программистами как Мартин Фаулер и Роберт Мартин в его книгах "Чистый код" и "Чистая архитектура".