Manók a programozásban — mik ezek, okai és mikor indokoltak

Mi az a „manó” a programozásban

Manó (crutch) — egy szoftvermegoldás, ami működik, de „gyorsan összedobva” készült: lezár egy konkrét problémát, de nem szünteti meg annak okát, nem követi a projekt architektúráját és a legkisebb környezeti változástól is elromolhat. A metafora találó — mint egy igazi manó, az ilyen kód segít „járni”, de nem gyógyítja meg a „lábat”.

A fejlesztők „manóval támasztják meg” a hibákat, verzió-inkompatibilitásokat, platformjellemzőket és sürgős ügyfélkéréseket. Egy tipikus manó — manó-feltétel: ha iOS 15, adj hozzá egy szóközt; ha Huawei — rejtsd el a gombot. Az ilyen ellenőrzések megsokszorozódnak és a kódot platform- és verzióágak „réteges tortájává” változtatják.

A manók különböző méretűek lehetnek: egyetlen sornyi manó-feltételtől egy teljes közvetítő modulig, ami „kijavítja” a könyvtár viselkedését. Fontos megérteni, hogy a manó nem mindig rossz: a megfelelő kezekben ez egy eszköz, ami lehetővé teszi a termék időben történő kiadását. A probléma akkor kezdődik, amikor a manó örökre a kódban marad.

Miért jelennek meg a manók: okok és kontextus

A fő ok a manók megjelenésére az ideális megoldás és a projekt valós korlátai közötti konfliktus. A fejlesztő tudja, hogyan kell helyesen csinálni, de az idő, a pénz vagy a technikai korlátozások ezt nem teszik lehetővé. Ennek eredményeként egy kompromisszumos megoldás jön létre, ami „csak működik”.

Vizsgáljuk meg négy fő okát annak, miért folyamodnak a fejlesztők tudatosan manókhoz. Ezen okok megértése segít abban, hogy a manókra ne hibaként, hanem pragmatikus, menedzsmentet igénylő eszközként tekintsünk.

Határidők

A leggyakoribb ok. A kiadás holnap van, a hiba csak egy adott modellen reprodukálódik, az architekturális javítás két hétig tart. A manó-feltétel egy órát vesz igénybe és lezárja a problémát. A kiadás után a csapat megígéri, hogy visszatér és helyesen átírja. „Nincs semmi állandóbb, mint az ideiglenes" — pontosan az ilyen manókról van szó.

Verzió-inkompatibilitás

Az A könyvtár Android 12-t igényel, de az alkalmazásod Android 10-et támogat. A megoldás — írj egy köztes réteget, ami ellenőrzi az OS verziót és kiválasztja a végrehajtási utat. Ez egy manó, mert a könyvtár frissítésekor a köztes réteget át kell írni. De az alternatíva — a könyvtár vagy a régi eszközök támogatásának feladása — rosszabb lehet.

// Manó az API 29 kompatibilitáshoz
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Külső függőségek hibákkal

A könyvtár, amitől a projekt függ, hibát tartalmaz, de a frissítése hetekig tarthat (PR, kódellenőrzés, publikáció szükséges). A várakozás helyett a csapat ír egy wrappert, ami menet közben javítja a könyvtár viselkedését. A javított könyvtárverzió megjelenése után a wrapper eltávolításra kerül. Ha nem távolítják el — ez már architekturális probléma.

A rendszer hiányos megértése

Egy új fejlesztő egy legacy projektben nem érti, miért működik a kód pontosan úgy, ahogy. Ahelyett, hogy utánajárna, hozzáad egy új feltételt a meglévő fölé. Ez a legveszélyesebb manó típus, mert a szerző nincs tudatában, hogy ez egy manó. Az egyetlen gyógymód — kódellenőrzés és páros programozás az új csapattagok számára.

Mikor indokolt a manó: pragmatikus megközelítés

Nem minden manó rossz. A valódi fejlesztésben a kód abszolút tisztasága elérhetetlen és gyakran nem célszerű. A pragmatikus megközelítés elismeri, hogy az ideiglenes megoldások a folyamat részét képezik, de tudatosságot, dokumentálást és az eltávolítás megtervezését követeli meg. A manó akkor indokolt, ha gyorsabban oldja meg az üzleti feladatot, mint a tiszta architekturális megoldás.

Az indokolt manó kritériumai: lezár egy konkrét problémát, van gazdája (aki felelős az eltávolításáért) és létezik refaktorálási terv. Ha a három feltétel közül legalább egy nem teljesül — a manó technikai adóssággá válik. Az olyan eszközök, mint a TODO-megjegyzések ticket-tel a trackerben — a dokumentálás minimális módja.

Példa indokolt manóra

Kritikus hiba a kiadási ágban, amit a holnapi telepítésig le kell zárni. A tiszta megoldás architektúra refaktorálást igényel és két hétig tart. Manó — adj hozzá egy nil ellenőrzést és küldd el a javítást hotfix-ként. Az indokoltság feltételei: a trackerben létrehoztak egy ticketet a refaktoráláshoz, kijelöltek egy felelős személyt, a manót megjegyzéssel jelölték. Két hét múlva a csapat visszatér a feladathoz.

// TODO: IT-1234 — távolítsd el ezt a manót az AuthService refaktorálása után
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Hogyan különböztessük meg az ideiglenes manót az architekturális problémától

A határ a tudatos manó és az architekturális probléma (technikai adósság) között két paraméter mentén húzódik: a döntés tudatossága és az eltávolítási terv megléte. A manó mindig ideiglenes megoldás ismert élettartammal. A technikai adósság — számos elhanyagolt manó következménye.

Mikor válik a manó problémává

A helyzet akkor romlik meg, amikor a manók száma meghaladja a kritikus tömeget. Minden új manó növeli a rendszer „törékenységét”: egy változtatás az egyik helyen elront valami mást. Ennek eredményeként a fejlesztés lelassul, a hibák megsokszorozódnak, és egy új fejlesztő nem érti meg a kódot a szerző segítsége nélkül. Ebben a pillanatban a manók megszűnnek ideiglenes megoldások lenni és architekturális problémává válnak.

A manóválság jelei

Ha a kódban öt egymásba ágyazott ellenőrzés van az OS verzióra, az eszköz gyártójára és egy adott könyvtár jelenlétére — ez nem manó, ez architekturális probléma. Ha egy javítás hozzáadása három regressziót okoz a szomszédos modulokban — a manók megszűntek lokálisak lenni. Ha a kódellenőrzést rendszeresen elutasítják „még egy manó” miatt — ideje megtervezni a refaktorálást.

• Ugyanaz a manó ismétlődik három vagy több helyen — ideje egy egységes megoldásnak
• Egy manó tovább él három sprintnél eltávolítási terv nélkül — ez már technikai adósság
• Egy új fejlesztő nem érti, miért működik a kód pontosan így — a manó nincs dokumentálva
• A manó eltávolítása láncreakciót vált ki hibákból — a manótól való függés architekturálissá vált

Manók refaktorálása: stratégia és gyakorlat

Manók refaktorálása — az ideiglenes megoldások architekturálisan helyesekkel való helyettesítésének folyamata. Ez időt igényel, ezért szükség van egy priorizálási stratégiára: nem kell az összes manót azonnal eltávolítani. Egy jó stratégia — minden manót két paraméter alapján értékelni: a változtatások gyakorisága a kód adott területén és a felhasználókra gyakorolt hatás.

Priorizálási stratégia

Magas prioritás — manók a gyakran változó modulokban (üzleti logika, általános célú UI), amelyek lassítják a fejlesztést és regressziókat okoznak. Közepes prioritás — manók a ritkán változó modulokban, de potenciális felhasználói hatással (fizetésfeldolgozás, hitelesítés). Alacsony prioritás — manók a legacy kódban, ami stabilan működik és nem tervezett módosításra.

Lépésről lépésre történő eltávolítás

1. lépés: leltár — találd meg az összes manóhoz kapcsolódó TODO-t és FIXME-t. 2. lépés: értékelés — állapítsd meg, melyek még aktuálisak. 3. lépés: tervezés — ütemezd be a manók refaktorálását egy sprintbe, a magas prioritásúaktól kezdve. 4. lépés: helyettesítés — implementáld a tiszta megoldást, távolítsd el a manót és a TODO-megjegyzést. 5. lépés: ellenőrzés — győződj meg róla, hogy a tesztek mennek és nincsenek regressziók.

# Keresd meg az összes TODO-manót a projektben
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Új manók megelőzése

A legjobb módja a manók elleni küzdelemnek — ne hozz létre őket szükségtelenül. Mielőtt megírsz egy manót, tégy fel magadnak három kérdést: meg lehet-e csinálni tiszta megoldással ésszerű időn belül? Van-e alternatíva, ami nem manó? Lesz-e ideje a csapatnak visszatérni és ezt átírni? Ha legalább egy kérdésre „nem” a válasz — gondold meg még egyszer, mielőtt „megtámasztod” a kódot.