Реорганизовать беспорядочный код легко, если следовать нескольким простым рекомендациям.

Я начну с того, что дам вам именно то, за чем вы пришли: эмпирические правила.

Вам интересно, почему эти эвристики полезны? Затем прочтите дополнительную информацию после списка.

12 эвристик для начинающих, чтобы стать экспертами по рефакторингу

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

  1. Список параметров вашего класса становится слишком большим? Тогда он, вероятно, слишком много делает. Его обязанности неясны и, возможно, болезненно тестировать и отлаживать. Это главный кандидат на рефакторинг.
  2. У вас есть методы внутри классов, которые используют только одну из зависимостей классов? Вам лучше поместить этот метод в отдельный класс - даже если этот класс будет состоять только из одного метода.
  3. Ваш метод делает две разные вещи в зависимости от значения логического параметра? Почему бы просто не создать два разных метода с четкими обязанностями?
  4. Ваш метод разветвляется по значению? Скажем, например, вы проверяете тип объекта и выполняете различные операции в зависимости от его типа. Это прекрасное время, чтобы превратить свой if-else или switch в словарь или карту.
  5. Вы широко используете if-else или switches в своем коде? Попробуйте вместо этого использовать полиморфизм и применить проверенные в боях шаблоны проектирования, такие как стратегия, посредник и т. Д.
  6. Принимает ли ваш конструктор или метод класса «магическое» число или строку? Это произвольное значение, представляющее некоторую внутреннюю ценность для бизнеса. Замени магию перечислениями.
  7. У вас есть жестко запрограммированные значения (числа или строки)? Вместо этого возьмите значения в качестве параметров и позвольте им настраиваться. Становится проще повторно использовать или развертывать ваше приложение в новых средах или изменять настройки.
  8. Не используйте имена переменных, например i, j, k, m, n, x. Просто перестань.
  9. Вы обнаруживаете, что реализуете одну и ту же логику в нескольких местах? Переместите логику в собственный класс или метод.
  10. У вас есть Service или Manager классы? Они похожи на швейцарские армейские ножи. Много обязанностей, низкая сплоченность. Найдите минутку, чтобы подумать, какие службы они предоставляют, а затем переместите каждую отдельную службу в отдельный класс.
  11. Сложно ли вам протестировать один метод, потому что класс, в котором он живет, требует множества аргументов конструктора? Вырвите метод из класса.
  12. Вам нужно добавить новый else-if или switch кейс, чтобы реализовать новое требование или функцию? Попробуйте использовать интерфейсы и отражение для автоматического обнаружения типов.

Почему стоит потратить время на изучение рефакторинга

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

Важно знать, когда проводить рефакторинг. Слишком рано? Это просто преждевременная оптимизация. Слишком поздно? Ваша кодовая база - это боль.

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

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

Что такое рефакторинг?

Давайте займемся той же страницей.

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

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

Как рефакторинг улучшает качество внутреннего программного обеспечения?

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

  1. Ремонтопригодность - повысьте, насколько легко вы можете вносить изменения в свое программное обеспечение. Ремонтопригодность включает добавление новых функций, настройку производительности, простоту исправления ошибок.
  2. Гибкость - степень, в которой вы можете модифицировать свое программное обеспечение для других целей. Подумайте, насколько легко вы можете изменить программное обеспечение.
  3. Переносимость - насколько легко вы можете заставить программное обеспечение работать в другой среде. Подумайте о локальной разработке и о запуске на сервере в производственной среде.
  4. Возможность повторного использования - насколько легко вы можете использовать части своего программного обеспечения в других системах.
  5. Читаемость - насколько легко вы можете читать и понимать исходный код. Не только на уровне интерфейса, но и в мельчайших деталях реализации.
  6. Возможность тестирования - насколько легко писать модульные тесты, интеграционные тесты и т. Д.
  7. Понятность - насколько легко понять ваше программное обеспечение на общем уровне. Содержательно ли структурирована ваша кодовая база?

Некоторые из этих характеристик позволяют достичь противоречивых целей. Это жизнь.

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

Помня об этих характеристиках, проверьте свои знания и посмотрите, сможете ли вы сопоставить их со списком эвристик.

Какая эвристика улучшает какие качественные характеристики?

Ресурсы

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

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

Новый канал на YouTube (@Nicklas Millard)

Подключиться к LinkedIn