2018 eleje óta a csapat vezető fejlesztőjeként, vagy ahogy szeretnéd nevezni, teljes felelősséggel tartozom egy modulért és az azon dolgozó fejlesztőkért. Ez a pozíció új perspektívát nyújt a fejlesztési folyamatról, mivel több projektben is részt veszek és aktívan részt veszek a döntéshozatalban. Nemrég, e két körülménynek köszönhetően, váratlanul ráébredtem, milyen nagy hatással bír a megértés mértéke a kódra és az alkalmazásra.
A gondolat, amit kifejezni szeretnék, az, hogy a kód minősége (és a végtermék) szoros kapcsolatban áll azzal, mennyire tudják az emberek, akik a tervezéssel és kódírással foglalkoznak, hogy mit is csinálnak.
Talán most azt gondolod: „Köszi, kapitány. Persze, nem ártana tudni, mit írsz. különben akár egy csapat majmot is fel lehetne venni, hogy csak verjenek a billentyűzeten, és kész.” És teljesen igazad van. Ennek megfelelően elismerem, hogy tudod, mennyire fontos egy általános elképzelés, hogy mit csinálsz. Ezt nullás megértési szintnek hívhatjuk, és ezt nem fogjuk részletezni. Részletesen fogunk beszélni arról, hogy mit kell pontosan érteni, és hogyan hat ez a napi döntéseidre. Ha tudtam volna ezeket a dolgokat előre, rengeteg időt és kétséges kódokat spórolhattam volna meg.
Bár lent egyetlen kódsort sem fogsz látni, mégis úgy gondolom, hogy minden, amit itt mondok, jelentőséggel bír a minőségi, kifejező kód írásában.
Az első megértési szint: Miért nem működik?
E szintre a fejlesztők általában karrierjük legkorábbi szakaszaiban jutnak el, néha még külső segítség nélkül is — legalábbis az én megfigyeléseim szerint. Képzeld el, hogy kapsz egy hibajelentést: egy funkció az alkalmazásban nem működik, meg kell javítani. Hogyan lépnél tovább?
A standard eljárás a következőképpen néz ki:
- Megkeresni a kód azon részét, amely a problémát okozza (hogyan történik ez, külön téma, erről a régi kódról szóló könyvemben írok)
- Módosítani ezt a kódrészletet
- Meggyőződni arról, hogy a hiba javítva lett és nem jelentkeztek visszajelzési hibák
Most fókuszáljunk a második pontra – a kódban végzett változtatásokra. Két megközelítés létezik erre a folyamatra. Az első: megérti, mi történik a jelenlegi kódban, azonosítja a hibát és kijavítja. A második: tapogatva halad – például adjon hozzá +1-et egy feltételes utasításhoz vagy ciklushoz, nézze meg, hogy működik-e a funkció a kívánt forgatókönyvben, majd próbáljon ki még valamit, és így tovább a végtelenségig.
A helyes megközelítés az első. Ahogy Steve McConnell magyarázza a Code Complete című könyvében (amelyet egyébként nagyon ajánlok), minden alkalommal, amikor változtatunk a kódon, képesnek kell lennünk magabiztosan előre látni, hogy ez hogyan fog hatni az alkalmazásra. Idézem a memóriámból, de ha a hibajavítás nem úgy működik, ahogy vártad, az nagyobb aggodalmat kell, hogy keltsen benned, és meg kell kérdőjelezned az egész cselekvési tervedet.
Összefoglalva, ahhoz, hogy megfelelő hibajavítást végezzünk, amely nem rontja a kód minőségét, meg kell érteni a kód egész szerkezetét és a konkrét probléma forrását.
A második szint megértése: Miért működik ez?
Ez a szint sokkal kevésbé intuitív módon érthető, mint az előző. Én, mint kezdő fejlesztő, a főnököm révén tanultam meg, és később többször is elmagyaráztam a lényegét újonnan belépőknek.
Most képzeljük el, hogy egyszerre két hibajelentés érkezik: az első A forgatókönyvről szól, a második pedig B forgatókönyvről. Mindkét forgatókönyvben valami nem stimmel. Ennek megfelelően először az első hibát nézed át. Az első szint megértésére vonatkozó elveinket követve alaposan belemerülsz a problémához kapcsolódó kódba, kideríted, miért viselkedik az alkalmazás így A forgatókönyvben, és ésszerű korrekciókat végzel, amelyek pontosan azt az eredményt adják, amit vártál. Minden jól megy.
Ezután átváltasz a B forgatókönyvre. Megismétled a forgatókönyvet, hogy megpróbáld kiváltani a hibát, de – meglepetés! – most minden rendben működik. Az elgondolásod megerősítéséhez visszavonod az A hiba javítása során végzett módosításokat, és a B hiba újra megjelenik. A hibajavításod mindkét problémát megoldotta. Szerencséd van!
Ezt egyáltalán nem vártad. Kitaláltál egy módot, hogy kijavítsd az A forgatókönyv hibáját, és fogalmad sincs, miért működött ez a B forgatókönyv esetében. Ezen a ponton nagy a kísértés, hogy azt hidd, mindkét feladat sikeresen teljesült. Ez teljesen logikus: a cél az volt, hogy eltüntessük a hibákat, nem? De a munka még nem ért véget: még ki kell derítened, hogy miért javította meg a tetteid a B forgatókönyv hibáját. Miért? Mert lehet, hogy téves alapelveken működik, és akkor más megoldás után kell nézned. Íme néhány ilyen eset példa:
- mivel a megoldás nem lett célzottan kiválasztva a B hibához az összes tényező figyelembevételével, lehet, hogy akaratlanul is megrázkódtattad a C funkciót.
- nem zárható ki, hogy valahol még egy harmadik hiba is megbúvik, amely szintén ugyanolyan funkcióval kapcsolatos, és a hibajavításod a B forgatókönyv helyes működését rá köti. Jelenleg minden jól néz ki, de egy szép napon ezt a harmadik hibát észrevesszük és kijavítjuk. Akkor a B forgatókönyvben ismét hiba lép fel, és jobb, ha csak ott.
Mindez kaotikus elemeket visz a kódba, és egyszer csak a fejedre fog zuhani — valószínűleg a legrosszabb pillanatban. Össze kell szedned az akaratodat, hogy rá tudj szánni időt arra, hogy megértsd, miért működik minden látszólagosan, de megéri.
A megértés harmadik szintje: Miért működik ez?
A legutóbbi felismerésem éppen ezzel a szinttel kapcsolatos, és valószínűleg ez a gondolat hozná a legtöbb előnyt, ha hamarabb eljutottam volna ide.
Hogy érthetőbb legyen, nézzük meg példával: a modulodat kompatibilissé kell tenni az X funkcióval. Nem vagy különösebben közeli viszonyban az X funkcióval, de azt mondták, hogy ahhoz, hogy kompatibilis lehess vele, az F keretrendszert kell használnod. Más modulok, amelyek integrálódnak az X-szel, éppen ezt használják.
A kódod az első napjától kezdve egyáltalán nem érintkezett az F keretrendszerrel, ezért a bevezetése nem lesz könnyű. Ez komoly következményekkel járhat a modul egyes összetevőire nézve. Ennek ellenére teljesen belemerülsz a fejlesztésbe: hetekig írod a kódot, teszteled, kiadod az első verziókat, visszajelzést kapsz, javítod a regressziós hibákat, váratlan bonyodalmakat fedezel fel, nem tartod be az előzetesen megadott határidőket, írsz még egy adag kódot, teszteled, visszajelzést kapsz, javítod a regressziós hibákat — mindezt az F keretrendszer bevezetése érdekében.
És egy ponton hirtelen ráébredsz — vagy talán valakitől hallod — hogy lehet, hogy az F keretrendszer egyáltalán nem biztosít kompatibilitást az X funkcióval. Lehet, hogy az összes idő és energia, amit belefektettél, teljesen hiábavaló volt.
Valami hasonló történt egyszer egy projekt során, amelyért felelősséget vállaltam. Miért történt ez? Mert nem értettem jól az X funkció lényegét és azt, hogy az hogyan kapcsolódik az F keretrendszerhez. Mit kellett volna tennem? Megkérni azt, aki a fejlesztési feladatot adja, hogy világosan magyarázza el, hogyan vezet a tervezett cselekvési terv a kívánt kimenetelhez, ahelyett, hogy egyszerűen csak megismételném, amit más modulok számára tettek, vagy elhinném, hogy ez szükséges az X funkció működéséhez.
Ez a projekt tapasztalata megtanított arra, hogy ne kezdjem meg a fejlesztési folyamatot, amíg nincs világos megértésem arról, hogy miért kérnek bizonyos cselekvéseket tőlünk. Ezt nyíltan el kell utasítani. Amikor megkapod a feladatot, az első impulzusod az, hogy azonnal nekikezdj, hogy ne pazarolj időt. De az a politika, hogy „felfagyasztjuk a projektet, amíg meg nem ismerjük az összes részletet”, jelentősen csökkentheti a pazarolt időt.
Még ha nyomás alatt is állsz, hogy kezdj el dolgozni, miközben nem érted, mi indokolja ezt — ellenállj. Először is tisztázd, milyen céllal állították eléd ezt a feladatot, és dönts el, hogy ez megfelelő út-e a cél eléréséhez. Nekem mindezt keserű tapasztalatból kellett megtanulnom — remélem, hogy a példám segít azoknak, akik ezt olvassák.
Negyedik szintű megértés: ???
A programozásban mindig van mit tanulni, és úgy érzem, hogy csak a téma megértésének legfelső rétegeit érintettem. Milyen további megértési szinteket fedeztél fel a kódolás évei alatt? Milyen döntéseket hoztál, amelyek jót tett a kód és az alkalmazás minőségének? Milyen döntések bizonyultak hibásnak, és mit tanítottak neked? Oszd meg tapasztalataidat a hozzászólásokban.
Forrás: habr.com
