“Always be closing.”
Тяжело носящаяся мантра продаж отГленгарри Глен РоссВ том же духе (но с гораздо меньшим присягой), хороший инженер долженВсегда реконструируйте. Here’s why.
Чистить или не чистить
It’s generally agreed that clean code is easier to understand, cheaper to maintain, and much more extensible. At its core, refactoring is cleaning up existing code without altering its perceived functionality.
Обычное возражение против рефакторирования заключается в том, что нет времени на то, чтобы на самом деле сделать это. Команды рассматривают это как роскошь. Неустанный позыв к новым функциям просто не позволяет рефакторировать, особенно потому, что рефакторирование ничего не меняет с внешней точки зрения.
Чистый код облегчает вашу жизнь.Чистый код оплачивает себя и замедляет накопление технического долга.
Так что встряхните его.
That’s right. I’m suggesting a slight bit of subterfuge. A little misdirection even. Why not clean up a few things in every pull request?
Будьте бдительны
A good engineer has a vision of where the codebase should be heading. It might take a while to get there, but you know the messy parts, the backlog, the roadmap, the technical debt, the security holes, and the documentation gaps.
As you go about your regular feature development, be on the lookout for refactorings that can advance your larger agenda. Like one of those hyper-observant TV show detectives surveying a crime scene, pay close attention to all the code you stumble across.
Когда вы заметите запах кода или что-то слегка отключенное вблизи вашего текущего фокуса, звонки тревоги должны выключиться:“Don’t let this opportunity pass!” Take a few minutes and fix it now, before inspiration fades.
Don’t say it’s not your problem. Don’t pretend you can unsee it. Just roll up your sleeves and get it done.
A Simple Example
Рефакторирование не обязательно означает изменение тысяч строк кода. Это может быть всего лишь небольшой кусок кода здесь и там. Эти маленькие микро-рефакторы добавляются с течением времени.
Чтобы иллюстрировать микро-рефакторирование, давайте рассмотрим пример «метода извлечения» Голанга.
Предположим, что вы имеете дело с функцией, которая требует знать, сколько дней прошло с тех пор, как пользователь в последний раз вошел в систему.
func IsDormant(user User, asOf time.Time) bool {
days := int(asOf.Sub(user.LastLogin).Hours() / 24)
return days >= 8
}
You want to re-use the last login calculation instead of copying and pasting it, so you take the internal variable, days, and extracting it into a separate method, DaysSinceLastLogin:
func IsDormant(user User, asOf time.Time) bool {
return DaysSinceLastLogin(user, asOf) >= 8
}
func DaysSinceLastLogin(user User, asOf time.Time) int {
return int(asOf.Sub(user.LastLogin).Hours() / 24)
}
Это позволяет проверить и повторно использовать последнюю логику входа.Если вы напишете тест на единицу, вы обнаружите крайний случай, который должен быть обработан (потенциальная паника, если пользователь никогда не входил).
Это также облегчает будущие усовершенствования. Например, может иметь смыслIsDormantиDaysSinceLastLogin methods on the User struct instead of being standalone. Likewise, consider replacing the hard-coded value 8 with something more descriptive like DormantDaysThreshold.
Это простой пример, всего несколько строк кода. Но это красота. Он показывает, что небольшое переоборудование может добавить ценность, раскрыв потенциальный недостаток и указывая на будущие улучшения.
Чтобы узнать больше о рефакторировании и увидеть все малые способы улучшения вашего кода, ознакомьтесь с онлайн-ресурсами, такими как каталог рефакторирования из книги Мартина Фаулера или Refactoring Guru.
Реконструкция каталогаРефлексия гуруA Refactoring Mindset
Иметь видение для вашей кодовой базы легко. Зная, как добраться туда, сложнее. Наличие возможностей рефакторирования требует практики. Один из способов начать — рассмотреть, какие категории рефакторирования необходимы для трансформации вашего кода.
Here are some common refactoring themes to think about:
🧹 Remove Duplication — Collapse copy and pasted logic into a single function.
🧰 Extract Shared Utility or Library — Move common logic out of per-service implementations. Normalize integrations (e.g., all services use the same auth client).
Add Common Infrastructure — Introduce observability (logging, tracing, metrics). Centralize error handling or retries.
️Make Code More Testable — Break apart tightly coupled logic. Extract interfaces so dependencies can be mocked or stubbed.
Prepare for a Feature Change — Flatten complex conditionals or nested logic. Reorganize files or classes to fit new responsibilities.
️Support a New Architecture — Break apart a monolith. Introduce event-driven patterns, dependency injection, or async processing.
Reduce Cognitive LoadРазделите гигантские файлы или классы на логические, фокусированные единицы.
Improve Security or Compliance — Centralize access control logic. Refactor insecure patterns (e.g., manual SQL concatenation → parameterized queries).
Improve Performance — Replace naive algorithms with optimized ones. Reduce memory churn or unnecessary computation in hot paths.
👥 Ease Onboarding or Handoff — Refactor code that only “Pat” understands into something team-readable. Introduce docs/comments/test coverage as part of structural cleanup.
В 20 %
Некоторые могут возражать против того, что, безусловно, не все рефакторирования могут быть втянуты.Я вам это гарантирую.Давайте применим правило 80-20 и предусмотрим, что 20% рефакторирования нужно делать на вершине.
These should be an easier sell, however, because when you get to the point where you need a full, honest-to-goodness refactor, it is most definitely going to be in service of some larger goal.
Например, прежде чем работать над билетом на улучшение производительности, сначала нужно добавить отслеживание и показатели, чтобы вы могли разработать более тонкую картину текущей производительности и выявить горячие точки.
Refactoring Starts with Testing
It is probably self-evident, but I must point out that refactoring is much easier (and less nerve-racking) if your codebase has an accompanying suite of tests that pass before and after the refactoring. Having tests is also valuable for a bunch of other reasonsЕсли у вашего проекта нет сильных тестов, сначала добавьте некоторые тесты, чтобы разблокировать будущие перепроверки.
Code Review Considerations
Мой совет в этой статье противоречит стандартному руководству о том, чтобы не смешивать работу по переработке и регулярную разработку функций. возражение заключается в том, что это затрудняет команде выполнение обзоров кода, если включены несвязанные изменения.
Хорошим правилом для любого запроса на вывод является ограничение его до 500 строк изменений кода.Второе правило является то, что вспомогательные изменения рефакторирования должны составлять не более 20% от PR.
When you do have dedicated refactoring PRs, keep it focused and around this size. Sometimes a PR has to be greater than 500 lines of code, especially when working on a repo-wide refactor. In those cases, coordinate well with your colleagues to prepare them for the change and to minimize merge conflicts.
Сделайте каждый компромисс
Every time you touch the codebase, you have a choice: leave it a little better, or leave it a little worse. Refactoring doesn’t have to be a grand event. Small improvements (extracting methods, renaming confusing variables, breaking apart long methods, etc.) add up over time. They prevent technical debt from piling up and make future changes easier and safer.
Если вы что-то видите, то исправьте что-то.
Всегда будьте реконструирующими!
