Перед началом рефакторинга

(В оригинале - Before You Refactor)

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

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

• Избегайте намерения переписать все. Лучше стараться повторно использовать как можно больше уже написанного кода. Неважно, каким бы ужасным он не был, он уже оттестирован, просмотрен и прочее. Выбросить старый код, особенно если система уже «в поле», означает выбросить месяцы или даже годы, потраченные на оттестированный и прошедший проверку «в поле» код, имеющий при этом какие-то исправления, о которых вы не знаете. Без информации об этих «подводных камнях» может получиться так, что ваш переписанный код будет содержать те же «мистические» ошибки, которые уже были исправлены в старом коде. Это приведет к серьезным потерям времени, усилий и знаний, собираемых долгое время до этого.

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

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

• Личные предпочтения и эго не должны быть ведущим фактором. Если что-то работает, зачем это исправлять? То, что стиль или структура не соответствует вашим персональным предпочтениям, недостаточно для начала реструктуризации. Мысль о том, что вы можете написать лучше, чем ваш предшественник, тоже не является достаточной причиной.

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

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

Автор оригинала - Rajith Attapattu