Часто разработчики говорят об унаследованном коде. Кажется, что у каждого есть свои собственные определения того, что он считает наследием. Если вы спросите людей, поддерживающих методологию TDD, вы, вероятно, получите ответ, что унаследованный код — это любой код, в котором отсутствуют автоматизированные тесты.

Другие определяют его как код, который не имеет поддержки с точки зрения документации, что затрудняет его поддержку.

Очень расплывчатое определение — это то, которое гласит, что устаревший код — это любой код, написанный кем-то, кроме вас.

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

1. Коду не хватает поддержки

Отсутствие поддержки может означать одну из следующих вещей:

а) В коде отсутствует поддержка автоматизированных тестов. Говоря об автоматизированных тестах, вы обычно имеете в виду одно из трех: модульные тесты, интеграционные тесты и сквозные тесты.

б) Коду не хватает письменной документации.

c) Коду не хватает поддержки с точки зрения устной документации.

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

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

2. Средний разработчик боится вносить изменения в код

Это несколько связано с первым знаком. Дело в том, что если существует тесная зависимость между кодом и автором, то высока вероятность того, что никто другой даже не попытается прикоснуться к нему, если его не заставят.

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

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

3. Платформа и инструменты, с помощью которых был написан код, больше не поддерживаются его создателями.

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

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

Три способа работы с унаследованным кодом

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

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

Вот три вещи, о которых следует помнить при работе с унаследованным кодом в старой системе:

1. Делайте все возможное, чтобы не сломать существующие части программного обеспечения.

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

2. Попробуйте улучшить код таким образом, чтобы это не повлияло на код в другом месте.

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

3. Увеличьте тестовое покрытие кода, протестировав его

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

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

Заключительные слова

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