Разумные причины выполнения рефакторинга

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

• Код повторяется

• Метод слишком велик

• Цикл слишком велик или слишком глубоко вложен в другие циклы

• Класс имеет плохую связность

• Метод использует больше элементов другого класса, чем своего собственного

• Класс имеет слишком ограниченную функциональность

• По цепи методов передаются бродячие данные (данные, передаваемые в метод лишь затем, чтобы он передал их другому методу)

• Один класс слишком много знает о другом классе

• Сложный код объясняется при помощи комментариев. В важности комментариев трудно усомниться, но их не следует использовать для объяснения плохого кода. Старая мудрость гласит: «Не документируйте плохой код — перепишите его».

Когда не следует выполнять рефакторинг

• Не рассматривайте рефакторинг как оправдание написания плохого кода с намерением исправить его позднее

• Не рассматривайте рефакторинг как способ, позволяющий избежать переписывания кода

• Иногда имеющийся код настолько запутан, что подвергнуть его рефакторингу, конечно, можно, но проще начат все с самого начала

• Ещё один случай, когда следует воздержаться от рефакторинга, это близость даты завершения.

«Крупномасштабный рефакторинг - путь к катастрофе» (Кент Бек)

Безопасный рефакторинг

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

• Сохраняйте первоначальный код и часто создавайте контрольные точки

• Стремитесь ограничить объем отдельных видов рефакторинга

• Выполняйте все виды рефакторинга по одному за раз, компилируя и тестируя программу перед следующим видом рефакторинга.

• Выполняйте регрессивное тестирование и создавайте дополнительные тесты

• Изменяйте подход в зависимости от рискованности рефакторинга

• Выполняйте обзоры изменений.

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

Документирование

Хорошая документация — свидетельство профессиональной гордости, выражаемой программистом в программе. Документация имеет много вариантов.

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

Внешняя документация

• Папка разработки блоков (unit-development folder, UDF), или папка разработки ПО (software-development folder, SDF), — это неформальный документ, содержащий записи, используемые разработчиком во время конструирования. В первую очередь UDF служит для регистрации решений проектирования, которые нигде больше не документируются. Во многих проектах устанавливаются стандарты, определяющие минимальное содержание UDF.

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