Сделай плохой код хорошим

Прежде чем выполнять какой-либо рефакторинг, убедитесь, что у вас есть набор регрессионных тестов, которые вы можете запустить для кода. Не будет хорошего рефакторинга вашей кодовой базы, если вы затем введете тысячи регрессионных ошибок из-за упущения небольшого нюанса в том, что на самом деле делал исходный «плохой» код (и упущения его при рефакторинге).

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

Что касается комментариев, рекомендуется использовать JavaDocs. Когда вы пишете код, это похоже на сборку документации.

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

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

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

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

Мартин Фаулер написал отличную книгу по рефакторингу.

Вот каталог рефакторингов из книги.

Убедитесь, что у вас есть полный набор регрессионных тестов!

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

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

Всегда стоит обращать внимание на такого рода инструменты, они очень помогут вам, если вы научитесь интерпретировать то, что они вам говорят.

Также обратите внимание на предупреждения вашей IDE, они есть не зря.

• Я не связан ни с одним из этих поставщиков инструментов (хотя они и бесплатны), однако я часто их использую и очень впечатлен ими!

Спросите себя, почему вы проводите рефакторинг кода. Код нужно трогать? Хрупкий код легко сломать, улучшив его.

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

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

Если вы проводите рефакторинг кода по соображениям производительности, следите за улучшениями алгоритма. Если вы можете изменить алгоритм O (n ^ 2) на O (n log (n)) в разделе кода горячей, это может сделать для вашего кода намного больше, чем любое количество других небольших изменений.