“Always be closing.” Az eladási mantra a Ugyanabban a szellemben (de sokkal kevésbé esküvel), egy jó mérnöknek Íme a miért. Glengarry Glen Ross always be refactoring 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: Take a few minutes and fix it now, before inspiration fades. „Ne hagyd, hogy ez a lehetőség elhaladjon!” 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, , and extracting it into a separate method, : days 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 lehet és A módszerek a struktur helyett önálló. Hasonlóképpen, fontolja meg a merev kódolt érték helyettesítését Olyan leíró jellegű, mint . IsDormant DaysSinceLastLogin User 8 DormantDaysThreshold 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 from Martin Fowler’s book or the . refactoring catalog Refactoring Guru Katalógus újrahasznosítása A Guru újragondolása A 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: - Összeomlik a másolás és a beillesztett logika egyetlen funkcióba. 🧹 Remove Duplication 🧰 — Move common logic out of per-service implementations. Normalize integrations (e.g., all services use the same auth client). Extract Shared Utility or Library — Introduce observability (logging, tracing, metrics). Centralize error handling or retries. Add Common Infrastructure ️ Eltá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. Make Code More Testable - Flatten összetett feltételezések vagy beágyazott logika. reorganizálja a fájlokat vagy osztályokat, hogy illeszkedjenek az új feladatokhoz. Prepare for a Feature Change 🏗️ Bevezetés eseményvezérelt minták, függőség injekció, vagy aszinkciós feldolgozás. Support a New Architecture — Split giant files or classes into logical, focused units. Reduce Cognitive Load 🔐 Refactor bizonytalan minták (például kézi SQL-koncatenáció → paraméterezett lekérdezések). Improve Security or Compliance - Helyettesítse a naiv algoritmusokat optimalizált algoritmusokkal. - Csökkentse a memóriát vagy a felesleges számításokat a forró utakon. Improve Performance 👥 — Refactor code that only “Pat” understands into something team-readable. Introduce docs/comments/test coverage as part of structural cleanup. Ease Onboarding or Handoff 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 Ha 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. Egy csomó egyéb ok 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!
