“Always be closing.”
Az eladási mantra aGlengarry Glen RossUgyanabban a szellemben (de sokkal kevésbé esküvel), egy jó mérnöknekalways be refactoringÍme a miért.
Tisztítani vagy nem tisztítani
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.
A common objection to refactoring is that there isn’t time to actually do it. Teams see it as a luxury. The relentless drive for new features simply doesn’t allow for refactoring, especially because refactoring changes nothing from an external point of view. That can be a hard sell to your product owner.
A tiszta kód megkönnyíti az életet.A tiszta kód önmagáért fizet, és lelassítja a technikai adósság felhalmozódását.
So sneak it in.
Ez helyes. Ajánlom egy kis alátámasztást. Még egy kis félreértés. Miért ne tisztítson meg néhány dolgot minden húzási kérésben?
Be Vigilant
Egy jó mérnöknek van egy elképzelése arról, hogy hová kell mennie a kódbázisnak. Időbe telhet, hogy odaérjen, de ismeri a zűrzavarokat, a hátrányokat, az útitervet, a technikai adósságot, a biztonsági lyukakat és a dokumentációs hiányosságokat.
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.
Amikor észreveszi a kód szagát vagy valamit, ami kissé le van kapcsolva az aktuális fókusz közelében, a riasztóknak ki kell kapcsolniuk:„Ne hagyd, hogy ez a lehetőség elhaladjon!” 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.
Egy egyszerű példa
A refactoring nem feltétlenül azt jelenti, hogy több ezer sor kódot kell megváltoztatni. Ez csak egy kis darab kód lehet itt és ott. Ezek a kis mikro-refactoringok idővel felhalmozódnak.
A mikro-refaktorozás illusztrálása érdekében nézzük meg a Golang „kivonási módszerét”.
Let’s say you are tackling a feature that requires knowing how many days it has been since a user last logged in. You notice an existing method that determines if a user is dormant by using that same information:
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)
}
This allows the last login logic to be tested and reused. If you write a unit test, you’ll spot an edge case that should be handled (a potential panic if a user has never logged in).
Ez megkönnyíti a jövőbeni fejlesztéseket is. Például érdemes lehetIsDormantésDaysSinceLastLoginA módszerek aUserstruktur helyett önálló. Hasonlóképpen, fontolja meg a merev kódolt érték helyettesítését8Olyan leíró jellegű, mintDormantDaysThreshold.
This is a simple example, just a few lines of code. But that’s the beauty. It shows a small refactoring can add value by revealing a potential bug and pointing towards future improvements.
To learn more about the craft of refactoring and see all the small ways to improve your code, check out online resources such as the refactoring catalog from Martin Fowler’s book or the Refactoring Guru.
Katalógus újrahasznosításaA Guru újragondolásaA Refactoring Mindset
Having a vision for your codebase is easy. Knowing how to get it there is harder. Spotting refactoring opportunities takes practice. One way to get started is to consider which categories of refactoring are necessary to transform your code.
Here are some common refactoring themes to think about:
🧹 Remove Duplication- Összeomlik a másolás és a beillesztett logika egyetlen funkcióba.
🧰 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 TestableEltávolítsa a szorosan összekapcsolt logikát. Kiterjessze az interfészeket, hogy a függőségeket nevetségessé tegyék vagy megbotránkoztassák.
Prepare for a Feature Change- Flatten összetett feltételezések vagy beágyazott logika. reorganizálja a fájlokat vagy osztályokat, hogy illeszkedjenek az új feladatokhoz.
🏗️ Support a New ArchitectureBevezetés eseményvezérelt minták, függőség injekció, vagy aszinkciós feldolgozás.
Reduce Cognitive Load — Split giant files or classes into logical, focused units.
🔐 Improve Security or ComplianceRefactor bizonytalan minták (például kézi SQL-koncatenáció → paraméterezett lekérdezések).
Improve Performance- Helyettesítse a naiv algoritmusokat optimalizált algoritmusokkal. - Csökkentse a memóriát vagy a felesleges számításokat a forró utakon.
👥 Ease Onboarding or Handoff — Refactor code that only “Pat” understands into something team-readable. Introduce docs/comments/test coverage as part of structural cleanup.
The 20%
Some might object that surely not all refactorings can be snuck in. I’ll grant you that. Let’s apply the 80–20 rule and stipulate that 20% of refactorings need to be done on the up-and-up.
Ezeknek azonban könnyebbnek kell lenniük, mert amikor eljutsz ahhoz a ponthoz, ahol szükséged van egy teljes, becsületes, jóindulatú refaktorra, akkor minden bizonnyal egy nagyobb cél szolgálatában lesz.
For example, before working on a performance improvement ticket, you first need to add tracing and metrics so you can develop a finer picture of current performance and identify hotspots.
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 Egy csomó egyéb okHa a projekt nem rendelkezik erős teszteléssel, először adjon hozzá néhány tesztet a jövőbeli újrafogalmazások feloldásához.
Code Review Considerations
A cikkben szereplő tanácsom ellentétes a standard irányelvvel, hogy ne keverjük össze a refaktorozási munkát a rendszeres funkciófejlesztéssel. A kifogás az, hogy nehezebbé teszi a csapat számára a kód felülvizsgálatát, ha a nem kapcsolódó változtatások szerepelnek.
A good rule of thumb for any pull request is to limit it to 500 lines of code changes. A second rule of thumb is that ancillary refactoring changes should be no more than 20% of the PR.
Ha van egy dedikált refactoring PR, tartsa a fókuszban, és körülbelül ez a méret. Néha egy PR kell nagyobb, mint 500 sor kódot, különösen, ha dolgozik egy repo-széles refactor. Ezekben az esetekben, jól koordinálni a kollégákkal, hogy felkészüljenek a változásra, és hogy minimalizálja az összefonódás konfliktusok.
Make Every Commit Count
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.
Ha látsz valamit, javíts valamit.
Mindig legyen újratelepítve!
