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

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

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

* *Лучше всего реструктуризацию начать с подробной ревизии существующего кода и тестовых сценариев для этого кода*. Это поможет вам выявить сильные и слабые стороны существующего решения, чтобы потом оставить удачные моменты и избежать проблемных мест. Все мы часто думаем, что сможем написать лучше, чем уже написано... до тех пор пока не получаем в итоге что-то, гораздо худшее, чем предыдущая реализация, потому что мы ничему не научились на опыте и ошибках существующей системы.
* *Избегайте намерения переписать все*. Лучше стараться повторно использовать как можно больше уже написанного кода. Неважно, каким бы ужасным он не был, он уже оттестирован, просмотрен и прочее. Выбросить старый код, особенно если система уже «в поле», означает выбросить месяцы или даже годы, потраченные на оттестированный и прошедший проверку «в поле» код, имеющий при этом какие-то исправления, о которых вы не знаете. Без информации об этих «подводных камнях» может получиться так, что ваш переписанный код будет содержать те же «мистические» ошибки, которые уже были исправлены в старом коде. Это приведет к серьезным потерям времени, усилий и знаний, собираемых долгое время до этого.
* *Несколько последовательных изменений лучше, чем одно большое*. Небольшие изменения позволяют легче отслеживать воздействие на систему, например, при помощи тестов. Ничего приятного в том, чтобы после исправления обнаружить сотню провалившихся тестов. Это может вызвать раздражение и как следствие, принятие не самого лучшего решения. Тогда как пара-тройка провалившихся тестов легко укажет на источник проблемы.
* *После каждой итерации важно убедиться, что все существующие тесты все еще проходят*. Добавьте новые тесты, если существующие недостаточно покрывают изменяемый вами кода. Не выбрасывайте старые тесты без основательного анализа. На первый взгляд тесты могут казаться незначительными и неважными для вас, но может оказаться полезным копнуть глубже, чтобы понять, зачем же они были добавлены.
* *Личные предпочтения и эго не должны быть ведущим фактором*. Если что-то работает, зачем это исправлять? То, что стиль или структура не соответствует вашим персональным предпочтениям, недостаточно для начала реструктуризации. Мысль о том, что вы можете написать лучше, чем ваш предшественник, тоже не является достаточной причиной.
* *Новая технология также недостаточна для рефакторинга*. Одна из худших причин переписать код – это то, что существующий код находится «в стороне» от сегодняшних «прикольных» технологий, и мы уверены, что новый язык или фреймворк могут сделать то же самое гораздо более элегантно. Если только анализ не покажет, что новый язык или платформа действительно не приведут к значительному улучшению функциональности, сопровождаемости или производительности, обеспечив при этом финансовый выигрыш, то лучше рефакторинг не начинать.
* *Помните, что люди ошибаются*. Реструктуризация не гарантирует, что новый код получится лучше (или хотя бы таким же), чем предыдущая версия. Я участвовал в нескольких неудачных попытках реструктуризации. Это не было приятно, но это было по-человечески.

Автор оригинала - [Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu)