Miért Válik a Legtöbb Egyedi Szoftver Karbantarthatatlanná 12 Hónap Után

A tizenkét hónapos szakadék

A legtöbb egyedi szoftver tökéletesen működik az induláskor. A funkciók megfelelnek a specifikációnak. Az ügyfél elégedett. Mindenki továbbáll.

Tizenkét hónappal később változtatni kell valamin. Új funkció. Egy integráció. Javítás egy munkafolyamatra, ami már nem felel meg a valóságnak. És hirtelen ami napokba kellene kerüljön, az hetekbe telik. Ami 500 EUR-ba kellene kerüljön, az 5 000 EUR-ba kerül. Az egyszerű változtatások összefüggéstelen funkciókat törnek el.

Ez nem balszerencse. Kiszámítható. És szinte mindig ugyanazok a minták okozzák.

1. minta: Nincs dokumentáció (A "minden a fejemben van" probléma)

A rendszert építő fejlesztő tökéletesen értette az egészet. Minden döntésnek volt értelme a kontextusában. Az architektúra elegáns volt az ő fejében.

Aztán átment egy másik projektre. Vagy otthagyta a céget. Vagy egyszerűen elfelejtette a részleteket, miután más dolgokon dolgozott.

Ami elvész:

• Miért születtek bizonyos architekturális döntések
• Mi mitől függ (a rejtett csatolások)
• Hogyan kell felállítani a fejlesztői környezetet
• Mit igényel valójában a telepítési folyamat
• Mely részek törékenyek és miért

Az eredmény: Minden változtatás régészetté válik. Az új fejlesztők órákat töltenek a megértéssel, mielőtt módosíthatnának. Olyan változtatásokat hajtanak végre, amelyek biztonságosnak tűnnek, de feltételezéseket törnek, amelyekről nem is tudtak.

A megoldás: A dokumentáció nem opcionális. Minimum: egy README, ami elmagyarázza a felállítást, egy architektúra-áttekintés és soron belüli megjegyzések a nem nyilvánvaló döntéseknél. Ez talán 10%-kal több időt vesz igénybe fejlesztés közben, de 500%-ot takarít meg karbantartás során.

2. minta: Funkciókúszás refaktorálás nélkül

Az 1. verziónak három funkciója volt. Az architektúra gyönyörűen támogatta a három funkciót.

Aztán az ügyfél kért egy negyedik funkciót. Nem illeszkedett teljesen az architektúrába, de a határidő szoros volt, úgyhogy ráhegesztették. Aztán jött az ötödik. Aztán a hatodik. Minden egyes bővítés komplexitást adott egy alaphoz, amelyet soha nem arra terveztek, hogy ezt kezelje.

Ami történik:

• A függvények 20 sorról 200 sorra nőnek
• A fájlok gyűjtőhelyekké válnak lazán összefüggő kódnak
• Az állapotkezelés szétszórttá és kiszámíthatatlanná válik
• Az "ideiglenes" megkerülések állandó berendezésekké válnak
• Az új funkciók 15 fájl módosítását igénylik 2 helyett

Az eredmény: A rendszer aknamezővé válik. A tapasztalt fejlesztők félnek hozzányúlni. Az új fejlesztők nem értik. Minden változtatás kockázatos.

A megoldás: Kalkulálj be költségvetést a refaktorálásra. Amikor egy funkció nem illeszkedik tisztán, vagy mondj nemet, vagy szánj időt az átstruktúrálásra. A "gyors hack most, javítás később" megközelítés sosem kap javítást később.

3. minta: Függőségek mint aknák

A modern szoftver több száz külső csomagtól függ. Minden csomagnak saját függőségei vannak. Minden függőségnek saját frissítési ciklusa.

Ami félremegy:

• Biztonsági sebezhetőségek sürgős frissítést igényelnek
• A frissítések kompatibilitási problémákat okoznak más függőségekkel
• Az elavult csomagok nem kapnak több biztonsági javítást
• Különböző csomagok megosztott függőségek ütköző verzióit igénylik
• A főverzió-frissítések kódmódosításokat igényelnek az egész alkalmazásban

Az időrend:

1. hónap: Minden működik, a függőségek aktuálisak. 6. hónap: Néhány csomag elavult, sürgős probléma nincs. 12. hónap: Több csomagnak ismert sebezhetőségei vannak, a frissítések kaszkádszerű változtatásokat igényelnek, egyes csomagok elavulttá váltak. 18. hónap: Bármit frissíteni többnapos projekt, kiszámíthatatlan kimenettel.

A megoldás: Rendszeres karbantartás. Frissítsd a függőségeket havonta, ne évente. Rögzítsd a verziókat gondosan. Kerüld a felesleges függőségeket. Válassz érett, jól karbantartott csomagokat a divatos újak helyett.

4. minta: Az adatbázis fogat növeszt

A kezdeti adatbázis séma értelmes volt a kezdeti követelményekhez. A táblák tisztán leképezték a fogalmakat. A lekérdezések egyszerűek voltak.

Aztán a követelmények változtak. Új mezők kerültek be. A régi mezőket nem lehetett eltávolítani (valami függhet tőlük). A világosnak tűnő kapcsolatok kétértelművé váltak.

Gyakori tünetek:

• Táblák 50+ oszloppal, amelyek többségét ritkán használják
• uj_statusz és tenyleges_statusz nevű mezők, mert az eredeti módosítása túl kockázatos volt
• Lekérdezések, amelyek 8 táblát joinolnak egyszerű kérdések megválaszolásához
• Inkonzisztens adatok, mert a validációs szabályok változtak, de a régi adatok maradtak
• Rejtélyes nullable mezők, amelyek céljára senki nem emlékszik

Az eredmény: Az adatbázis-lekérdezések teljesítmény-szűk keresztmetszetté válnak. Az adatintegritási problémák halmozódnak. Az egyszerű riportok komplex aggregációkat igényelnek.

A megoldás: Kezeld az adatbázis-változtatásokat ugyanolyan gondosan, mint a kódváltoztatásokat. Írj migrációkat, amelyek ténylegesen migrálják az adatokat, nemcsak oszlopokat adnak hozzá. Archiváld vagy takarítsd ki az elavult adatokat. Dokumentáld a sémát.

5. minta: Tesztelés, ami nem tesztel

A rendszernek vannak tesztjei. A tesztek átmennek. A rendszer mégis elromlik.

Ami valójában történik:

• A tesztek ellenőrzik, hogy a kód lefut, nem azt, hogy helyes eredményt produkál
• A tesztek ideális forgatókönyvekre íródtak, szélsőséges esetekre soha
• Az integrációs tesztek annyit mockolnak, hogy nem tesztelik az integrációt
• A tesztek minden kódváltoztatásnál eltörnek, így a fejlesztők abbahagyják a futtatásukat
• A lefedettségi mutatókat kijátsszák (100% lefedettség értelmetlen assertionökkel)

Az eredmény: Hamis biztonságérzet. A változtatások kikerülnek, mert a tesztek átmennek. A felhasználók fedezik fel a hibákat. A tesztcsomag iránti bizalom elpárolog.

A megoldás: Viselkedést tesztelj, ne implementációt. Írj teszteket, amelyek elkapnák a valós hibákat, amelyekkel találkoztál. Tartsd karban a teszteket, mint az éles kódot. Töröld azokat a teszteket, amelyek nem kapnak el valódi problémákat.

6. minta: Környezeti eltérés

A fejlesztés működik. A staging működik. Az éles környezet elromlik.

Miért történik ez:

• A fejlesztés más operációs rendszer-verziót futtat
• A staging kevesebb memóriával/CPU-val rendelkezik, mint az éles
• A környezeti változók apró módokon különböznek
• Az élesben olyan adatminták vannak, amelyek a teszt-környezetekben nem léteznek
• A gyorsítótárazás másképp viselkedik valós terhelés alatt

Az eredmény: A "nálam működik" mém azért válik mémé, mert folyamatosan igaz. Az éles problémák debugolása olyan környezetek reprodukálását igényli, amelyeket senki nem ért teljesen.

A megoldás: Konténerizálj. Használd ugyanazokat a Docker image-eket minden környezetben. Automatizáld a környezet felállítását. Tesztelj éles méretű adatvolumennel.

7. minta: A hiányzó buszfaktor

Egyetlen személy érti mélyen a rendszert. Mindenki más felszínes ismeretekkel rendelkezik.

A kockázat:

• Az illető minden döntésnél szűk keresztmetszetté válik
• Amikor nem elérhető, a haladás megáll
• Amikor távozik, az intézményi tudás vele megy
• "Dokumentálatlan döntéseket" halmoz fel, amelyek aknákká válnak

Az eredmény: A rendszer jövője egyetlen meghibásodási ponttól függ. És az illető előbb-utóbb továbblép -- mindenki megteszi.

A megoldás: Páros programozás. Kódellenőrzések, amelyek ténylegesen átadják a tudást. Dokumentációs követelmények. Keresztképzés. Nincs egyszemélyes tulajdonjog kritikus rendszerek felett.

Hogyan néz ki valójában a "karbantartható"

A karbantartható szoftver nem tökéletes szoftver. Olyan szoftver, ahol:

1. Egy új fejlesztő napok alatt megérti, nem hetek alatt. A struktúra nyilvánvaló. A konvenciók következetesek. A dokumentáció létezik.

2. A változtatások lokálisak. Az X funkció módosítása nem töri el az Y és Z funkciókat. A komponensek közötti határok egyértelműek.

3. A függőségek kezelhetőek. A frissítések nem kaszkádolnak kiszámíthatatlanul. Van egy világos folyamat a naprakészen tartáshoz.

4. A tesztek valódi problémákat kapnak el. Amikor a tesztek átmennek, a csapatnak tényleges bizalma van. Amikor a tesztek elbuknak, a hiba valódi problémára mutat.

5. A környezetek reprodukálhatóak. A fejlesztői környezet felállítása szkriptelt. A staging megegyezik az élessel. A telepítések kiszámíthatóak.

6. A tudás eloszlik. Több ember tud változtatásokat végrehajtani. A dokumentáció rögzíti a döntéseket.

Miért ismétlődik ez újra és újra

A minta azért ismétlődik, mert az ösztönzők nincsenek összhangban:

Fejlesztés közben:

• A gyorsaságot jutalmazzák
• A működő funkciók láthatóak
• A dokumentáció láthatatlan
• A technikai adósság láthatatlan
• A büdzsé rögzített

Karbantartás közben:

• A gyorsaság a kódminőségtől függ
• Minden gyorstalpaló megoldás láthatóvá válik
• A hiányzó dokumentáció blokkolja a haladást
• A technikai adósság megköveteli a fizetést
• A "takarítás" büdzséjét nehéz indokolni

A rendszert építő fejlesztők gyakran nem azonosak a karbantartó fejlesztőkkel. A funkciókat most fizető vállalkozás nem érzi a későbbi karbantartás fájdalmát. Mindenki racionálisan cselekszik a saját korlátain belül -- és a rendszer kiszámíthatóan degradálódik.

Hogyan építünk a QPC8-nál

A QPC8-nál a karbantarthatóság nem opcionális. Minden rendszer, amit leszállítunk, ugyanazokat az elveket követi:

A dokumentáció a szállítás része. Nem tekintünk befejezettnek egy projektet, amíg a README el nem magyarázza a felállítást, az architektúra nincs dokumentálva és a telepítés nincs szkriptelve.

Menet közben refaktorálunk. Amikor a követelmények változnak a projekt közepén (és mindig változnak), átstruktúrálunk, nem ráhegesztünk. Ez rövid távon többbe kerül. A rendszer élettartama alatt drámaian kevesebbe.

A függőségek konzervatívak. Érett, jól karbantartott csomagokat választunk. Kerüljük a divatos könyvtárakat, amelyeket jövőre esetleg elhagynak. A függőségek számát alacsonyan tartjuk.

A tesztelés valódi hibákat kap el. A tesztjeink az igazán lényeges viselkedésre fókuszálnak. Nem a lefedettségi mutatókat hajtjuk -- a magabiztosságot hajtjuk.

Nincs egyszemélyes tudás. A rendszereink elég jól dokumentáltak ahhoz, hogy bármelyik mérnök karbantartsa őket. Ez nem megalkuvás kérdése.

Az eredmény: rendszerek, amelyek egészségesek maradnak az idő múlásával. Ügyfelek, akik változtatásokat hajthatnak végre aknák felfedezése nélkül. Szoftver, ami vagyon marad, nem válik teherré.

A helyes megközelítés ára

A karbantartható szoftver építése előre többe kerül. Talán 20-30%-kal több, mint a lehető leggyorsabb szállítás.

De:

• A 2. évi karbantartás 50%-kal olcsóbb
• A 3. évi módosítások 70%-kal olcsóbbak
• A rendszer fejlődhet ahelyett, hogy lecserélésre szorulna
• A belső csapatok külső segítség nélkül is hozzájárulhatnak
• Szállítót válthatsz anélkül, hogy nulláról kellene kezdened

Azok a vállalkozások, amelyek a lehető legolcsóbb v1-et építtetik, gyakran háromszor fizetnek: egyszer a kezdeti építésért, egyszer a sürgősségi javításokért és egyszer a végleges cseréért.

Azok a vállalkozások, amelyek előre befektetnek a minőségbe, egyszer fizetnek és iterálnak.

Kérdések, amelyeket fel kell tenned a fejlesztőidnek

Ha szoftverfejlesztést értékelsz (vagy meglévő szoftvert tartasz karban), kérdezd meg:

1. Hogyan állítok fel fejlesztői környezetet? Ha a válasz több mint 10 percig tart elmagyarázni, probléma van.

2. Mutasd meg a dokumentációt. Ha nincs, törzsi tudástól vagy függő.

3. Mikor frissítettétek utoljára a függőségeket? Ha a válasz "az induláskor", ketyegő időzített bomba van a kezedben.

4. Mi történik, ha elüt egy busz? Ha senki más nem tudja karbantartani a rendszert, egyetlen meghibásodási pontod van.

5. Hogyan telepítek egy változtatást? Ha a folyamat nincs dokumentálva és automatizálva, minden telepítés kockázatos.

A válaszok elárulják, hogy a szoftvered vagyon-e vagy teher.

---

A QPC8 éles rendszereket épít, amelyeket hosszú távú karbantarthatóságra tervezünk. Nézd meg a leszállított rendszereinket vagy konfiguráld a projektedet.