make bad code good

Question

Я прочитал статью о том, как изменить существующий плохой код на хороший. Для справки, это ссылка на статью http://www.javaworld.com/jw-03-2001/jw-0323-badcode.html?page=1

Он широко говорил о следующих

• Добавить комментарии

• Re-Факторинг Код

  • Перерыв большие классы в меньшие классы
  • Перерыв больших функций в небольшие Функции эр
  • Изменить код, который трудно понять
• Использование многоуровневой архитектуры

Кажется хорошо. Любые дополнения к этому списку, которые вы все могли встретить?

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

Here is the catalog of refactorings from the book.

Answer 6

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

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

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

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

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

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

Answer 7

Задать вопрос, почему вы переформатируете код. Необходимо ли коснуться кода? Легко сломать хрупкий код, улучшив его.

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

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

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