2018 eleje óta töltöm be a vezető/főnök/vezető fejlesztő pozíciót a csapatban – nevezd ahogy akarod, de a lényeg, hogy teljes mértékben én vagyok a felelős az egyik modulért és az összes dolgozó fejlesztőért. Rajta. Ez a pozíció új perspektívát ad a fejlesztési folyamathoz, mivel több projektben veszek részt, és aktívabban veszek részt a döntéshozatalban. Nemrég ennek a két dolognak köszönhetően hirtelen rájöttem, hogy a megértés mértéke mennyire befolyásolja a kódot és az alkalmazást.
Arra szeretnék rávilágítani, hogy a kód (és a végtermék) minősége szorosan összefügg azzal, hogy a kódot tervező és író emberek mennyire tisztában vannak azzal, amit csinálnak.
Lehet, hogy most azt gondolja: „Köszönöm, Cap. Persze jó lenne általánosságban megérteni, amit írsz. Ellenkező esetben akár felbérelhet egy csoport majmot, hogy tetszőleges billentyűket üthessen le, és hagyja a dolgot. És teljesen igazad van. Ennek megfelelően természetesnek tartom, hogy felismered, hogy általános elképzelésed van arról, amit csinálsz. Ezt nevezhetjük a megértés nulla szintjének, és nem elemezzük részletesen. Részletesen megvizsgáljuk, hogy pontosan mit kell értenie, és ez hogyan befolyásolja a mindennapi döntéseit. Ha ezeket előre tudtam volna, sok elvesztegetett időtől és megkérdőjelezhető kódtól kíméltem volna meg.
Bár az alábbiakban egyetlen kódsort sem fog látni, mégis úgy gondolom, hogy az itt elmondottaknak nagy jelentősége van a jó minőségű, kifejező kód megírásához.
Megértés első szintje: Miért nem működik?
A fejlesztők általában nagyon korán elérik ezt a szintet, néha mások segítsége nélkül is – legalábbis az én tapasztalataim szerint. Képzelje el, hogy hibajelentést kapott: az alkalmazás néhány funkciója nem működik, javítani kell. Hogyan tovább?
A szabványos séma így néz ki:
- Keresse meg a problémát okozó kódrészletet (ennek módja egy külön téma, a régi kódról szóló könyvemben foglalkozom vele)
- Módosítsa ezt a kódrészletet
- Győződjön meg arról, hogy a hiba javítva van, és nem történt regressziós hiba
Most koncentráljunk a második pontra – a kód módosítására. Ennek a folyamatnak két megközelítése van. Az első az, hogy elmélyüljön, mi történik pontosan az aktuális kódban, azonosítsa a hibát és javítsa ki. Másodszor: mozgás érzés szerint – adjon hozzá, mondjuk, +1-et egy feltételes utasításhoz vagy ciklushoz, nézze meg, működik-e a függvény a kívánt forgatókönyvben, majd próbálkozzon valami mással, és így tovább a végtelenségig.
Az első megközelítés helyes. Ahogy Steve McConnell a Code Complete című könyvében kifejti (melyet egyébként nagyon ajánlok), minden alkalommal, amikor valamit megváltoztatunk a kódban, magabiztosan meg kell tudnunk jósolni, hogy az milyen hatással lesz az alkalmazásra. Emlékezetből idézek, de ha egy hibajavítás nem úgy működik, ahogy vártad, akkor nagyon meg kell ijedni, és meg kell kérdőjelezni az egész akciótervét.
Összefoglalva az elmondottakat, egy jó hibajavítás végrehajtásához, amely nem rontja a kód minőségét, meg kell értenie a kód teljes szerkezetét és a konkrét probléma forrását.
A megértés második szintje: Miért működik?
Ez a szint sokkal kevésbé intuitív módon érthető meg, mint az előző. Én még kezdő fejlesztőként a főnökömnek köszönhetően megtanultam, és ezt követően többször is elmagyaráztam az újoncoknak a dolog lényegét.
Ezúttal képzeljük el, hogy egyszerre két hibajelentést kapott: az első az A forgatókönyvről, a második a B forgatókönyvről szól. Mindkét forgatókönyvben valami hiba történik. Ennek megfelelően először az első hibát kezelje. Az XNUMX. szintű megértéshez általunk kidolgozott alapelvek segítségével mélyen beleáshat a probléma szempontjából releváns kódba, kitalálja, miért teszi az alkalmazást úgy, ahogyan az A forgatókönyvben, és ésszerű módosításokat hajt végre, amelyek a kívánt eredményt eredményezik. . Minden remekül megy.
Ezután továbblép a B forgatókönyvre. Megismétli a forgatókönyvet, hogy hibát idézzen elő, de – meglepetés! - most minden úgy működik, ahogy kell. A feltételezés megerősítéséhez visszavonja az A hibán végzett munka során végzett változtatásokat, és a B hiba visszatér. A hibajavításod mindkét problémát megoldotta. Szerencsés!
Ezzel egyáltalán nem számoltál. Ön kitalálta a módját, hogyan javítsa ki a hibát az A forgatókönyvben, és fogalma sincs, miért működött ez a B forgatókönyv esetében. Ebben a szakaszban nagyon csábító azt gondolni, hogy mindkét feladatot sikeresen elvégezték. Ez teljesen logikus: a lényeg a hibák kiküszöbölése volt, nem? De a munka még nem fejeződött be: még mindig rá kell jönnie, hogy a tettei miért javították ki a hibát a B forgatókönyvben. Miért? Mert lehet, hogy rossz elveken dolgozik, és akkor más kiutat kell keresnie. Íme néhány példa az ilyen esetekre:
- Mivel a megoldást nem a B hibára szabták, az összes tényezőt figyelembe véve előfordulhat, hogy tudtán kívül megsértette a C funkciót.
- Lehetséges, hogy valahol egy harmadik hiba is lappang ugyanahhoz a funkcióhoz, és ettől függ a hibajavításod a rendszer megfelelő működéséhez a B forgatókönyvben. Most minden rendben van, de egy napon ezt a harmadik hibát is észreveszik és kijavítják. Aztán a B forgatókönyvben a hiba újra előjön, és jó, ha csak ott.
Mindez káoszt hoz a kódba, és egy nap a fejére fog esni – valószínűleg a legalkalmatlanabb pillanatban. Össze kell szednie az akaraterőt, hogy időt szánjon arra, hogy megértse, miért tűnik úgy, hogy minden működik, de megéri.
A megértés harmadik szintje: Miért működik?
Legutóbbi meglátásom pontosan erre a szintre vonatkozik, és valószínűleg ez az, amiből a legtöbb hasznom lett volna, ha korábban jutottam volna ehhez az ötlethez.
Hogy világosabb legyen, nézzünk egy példát: a modulodat kompatibilissé kell tenni az X funkcióval. Nem ismered különösebben az X függvényt, de azt mondták, hogy ahhoz, hogy kompatibilis legyen vele, az F keretrendszert kell használni. az X-szel integrált modulok pontosan működnek vele.
A kódod élete első napja óta egyáltalán nem érintkezett az F keretrendszerrel, így a megvalósítása nem lesz olyan egyszerű. Ennek súlyos következményei lesznek a modul egyes részeire nézve. Ön azonban beleveti magát a fejlesztésbe: heteket tölt kódírással, teszteléssel, pilotverziók kidolgozásával, visszajelzések beszerzésével, regressziós hibák kijavításával, előre nem látható bonyodalmak felfedezésével, az eredetileg megbeszélt határidők be nem tartásával, további kódírással, teszteléssel, visszajelzési kommunikációval, regressziós hibák javítása – mindezt az F keretrendszer megvalósítása érdekében.
És egy ponton hirtelen ráébredsz – vagy esetleg hallasz valakitől –, hogy talán az F keretrendszer egyáltalán nem ad kompatibilitást az X funkcióval.
Valami hasonló történt egyszer, amikor egy projekten dolgoztam, amiért én voltam a felelős. Miért történt ez? Mivel nem nagyon értettem, hogy mi az X függvény, és hogyan kapcsolódik az F keretrendszerhez. Mit kellett volna tennem? Kérje meg a fejlesztési feladatot kijelölő személyt, hogy világosan magyarázza el, hogyan vezet a tervezett cselekvés a kívánt eredményhez, ahelyett, hogy egyszerűen megismételné, amit más moduloknál tettek, vagy szót fogadjanak arról, hogy X funkciónak ezt kell tennie.
A projekt tapasztalatai megtanítottak arra, hogy megtagadjam a fejlesztési folyamat megkezdését mindaddig, amíg nem értjük világosan, miért kérnek minket bizonyos dolgok megtételére. Határozottan utasítsa el. Amikor kap egy feladatot, az első impulzus az, hogy azonnal vállalja, hogy ne veszítse el az időt. De a „befagyasztjuk a projektet, amíg minden részletre nem térünk” politika nagyságrendekkel csökkentheti az elvesztegetett időt.
Még ha megpróbálnak nyomást gyakorolni rád, rákényszeríteni a munkakezdésre, bár nem érted ennek az okát, állj ellen. Először is gondold át, miért kapsz ilyen feladatot, és döntsd el, hogy ez a helyes út-e a célhoz. Mindezt kemény úton kellett megtanulnom – remélem, a példám megkönnyíti azoknak az életét, akik ezt olvassák.
Megértés negyedik szintje: ???
A programozásban mindig van mit tanulni, és úgy gondolom, hogy a megértés témájának csak a felszínét kapargattam. Milyen más szinteket fedezett fel a kóddal való munka során? Milyen döntéseket hozott, amelyek pozitív hatással voltak a kód és az alkalmazás minőségére? Milyen döntések bizonyultak hibásnak, és milyen értékes leckét adtak neked? Ossza meg tapasztalatait a megjegyzésekben.
Forrás: will.com