TeamLead
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Рефакторинг

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

Чистый код

Чистый код проходит все тесты. Если программа проходит только 95% тестов, значит где-то у вас завелся грязный код. Если у вас вообще нет тестов, вы не проходите этот пункт автоматически.

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

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

Чистый код содержит минимум классов и других движущихся частей. Чем меньше кода, тем меньше его нужно держать в голове. Чем меньше кода, тем меньше вероятность его сломать.

Чистый код легче и дешевле поддерживать.

Когда рефакторить

Правило трёх

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

Когда делаете новую фичу

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

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

Когда исправляете баги

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

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

Во время код-ревью

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

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

Как рефакторить

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

Чек-лист правильно проведённого рефакторинга

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

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

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

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

Все существующие тесты должны успешно проходить.
Есть два случая, когда после рефакторинга ломаются тесты:

  • Вы допустили ошибку при изменении кода. Тут всё просто — идите и исправьте ошибку.
  • Ваши тесты были слишком низкоуровневыми. Чаще всего это случается из-за того, что ваши тесты проверяют работу приватных методов классов.

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