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

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

К примеру, на предыдущей работе в компании, занимающейся заказной разработкой решений интеграции софта контакт-центров, я проработал меньше года. В новой команде, на амбициозном проекте. Что-то с нуля проектировали, какие-то передовые практики внедряли. Я сам какие-то решения принимал, видел, как другие люди работают и какие решения принимают, и как их аргументируют. Но одного года мало чтобы увидеть к чему все эти решения ведут. По факту система, которую мы делали, даже не успела дойти до продакшна за этот срок. У меня были какие-то гипотезы, к чему идет проект, куда идет компания, что будет если сделать так или эдак. И теперь, хотя я и не могу больше видеть всё это изнутри, но по внешним эффектам могу что-то понять: какие мои гипотезы оказались верны, а какие были ошибочны.

Сегодня я увидел один из внешних эффектов – презентацию “Legacy vs Agile Team”, где Алексей (докладчик) рассказал о страшностях, случающихся, когда приходится бороться с legacy кодом, и как это влияет на процесс разработки.

Презентация по форме неплохая – рассказ складный, слайды ненапряжные. Пожалуй, сильно лучше чем предыдущие презентации Алексея.

Что касается содержания… Мне показалось, что под словом “legacy” кроются две совершенно независимые проблемы, которые и решать надо независимо, разными способами.

Первая проблема – это технический долг. На самом деле, технический долг – это проблема, не обязательно относящаяся к legacy коду. Та система о которой Алексей рассказывает как о рае для разработчиков тоже страдала от технического долга буквально с первого месяца разработки. И это нормально. Невозможно работать в agile проекте, не сталкиваясь с проблемой технического долга. Требования постоянно меняются, и какие-то кусочки системы перестают отвечать новым требованиям, что приводит к возникновению технических работ, напрямую не связанных с продуктовыми требованиями.

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

Вторая проблема – это внезапные критические баги, которые требуется разрешать в кратчайшие сроки. И тут я могу уверенно сказать, что это не атрибут legacy системы. Потому что мой опыт работы с более крупной и более старой системой (более 10 лет, более 3 млн строк кода) показывает, что даже самый ужасный внутри код может отлично работать на продакшне, вызывая в год не более 2-3 дефекта которые надо решать немедленно.

Эта проблема скорее должна решаться лучшим тестированием кода. Покройте критичные бизнес-сценарии тестами (лучше автоматизированными, хотя и не обязательно). Прогоняйте тесты перед релизом. И проблема решена.

Пожалуй, доклад стоило бы назвать «Переходный период адаптации некачественного кода Agile командой”, потому что озвученные проблемы – это проблемы именно переходного периода.