Amit tudnod kell fejlesztőként, I. rész: Az eszközeid

Ezzel a bejegyzéssel egy sorozatot szeretnénk elindítani azokról a dolgokról, amit valószínűleg minden fejlesztőnek tudnia kellene, mégis sokunk szürkeállományából hiányzik. Reméljük némileg hiánypótló is lesz ez a széria, és sikerül vele minél több szaktársat a folyamatos tanulásra, fejlődésre ösztönözni. Az első rész a tágabb értelemben vett fejlesztői eszközökre koncentrál.

A tapasztalat azt mutatja, ritkák az olyan szakemberek, akik az általuk nap mint nap használt eszközöket mélyen ismerik. Rengeteg programozó használja a Java/C#/VB.NET/PHP/bármi környezeteket úgy, hogy közben nincs igazán beható tudása azok belső működéséről, alapvető koncepcióiról, az API-król, könyvtárakról.

Sokszor hallani azt az érvet, hogy ez a szintű a tudás egy "átlagos" programozó számára felesleges, elboldogul nélküle is. Ez két problémát is felvet. Azon kívül, hogy átlagos programozónak lenni nem különösebben nemes cél, mi történik vajon, ha egy ilyen "átlagos" fejlesztő találkozik egy olyan ember kódjával, aki viszont komoly tudással rendelkezik a használt ökoszisztémát illetően? A válasz nem meglepő: nem sok jó. A tapasztalt, az eszközöket mélyen ismerő fejlesztők olyan modelleket és megoldásokat alkalmaznak, amelyet egész egyszerűen az adott tudás hiányában az átlagos fejlesztő képtelen lesz megérteni, azonban rengeteg időt felemészthet, amíg ezt megkísérli. (Variációk a témára: "úgyis ki lehet guglizni" — persze, ki lehet, de így viszont a tanulás egy nagyon lassú elakadok-megnézem iterációvá válhat.)

Az átlagos fejlesztő ilyenkor aztán legtöbbször feladja, ilyenkor két dolog történhet. A jobbik esetben megkérdezi a tapasztalt kollégát, hogy mégis miről van szó, és megpróbálja ez alapján betölteni a tudásában a lyukakat. A rosszabb forgatókönyv (sajnos ez a gyakoribb) szerint viszont elkezdi bulldózerrel megtámadni a kifinomult kódot, és addig erőszakolni, amíg el nem éri a kívánt hatást — számos bugot és logikátlanságot hozva a szoftverbe.

De még ennél is van rosszabb. Mi van, ha a csapatból senki nem rendelkezik ilyesfajta mélyebb szintű tudással? Ilyenkor elmondhatjuk, hogy valójában nem is használják az általuk választott eszközt, csak alapvető programozási konstrukciókat (if-eket és for-okat bármilyen nyelven lehet írni — na jó, majdnem), és nem élvezik a plusz szolgáltatások által nyújtott előnyöket, amik általában a gyorsabb implementáció, karbantarthatóság, egyszerűség tengelyén mozognak. Ehelyett van hackelés, mindennek a felesleges újra-feltalálása (persze sokkal rosszabbul, mint a létező implementációk), magyarul a hosszabb, nehezebb út.

De vajon miért van az, hogy sokan megelégszenek az effajta részleges tudással? Ehhez érdemes megvizsgálni a fejlesztők különböző csoportjait:

• A fejlesztő, akit nem nagyon érdekel az egész. Ők nem igazán szeretik a munkájukat, és emiatt nem is éreznek motivációt semmi olyasmire, amiről beszélünk. A minimumra törekszenek az állásuk megtartásához, és nincs is remény, hogy ez megváltozzon.
• A kompetens jómunkásember. Ők általában jó, akár kiváló programozók, ennek ellenére mégsem mondhatók különlegesnek. Ők a karrierjük során folyamatosan új nyelveket, paradigmákat tanultak meg, ahogy azt az adott feladat megkövetelte. Amikor látnak valami új dolgot, utánaolvasnak, megtanulják, és beépítek a repertorájukba. Úgy találják, hogy ez a megközelítés az évek során nagyon jól működött, és általában nem is ismerik fel, hogy lenne értelme ennél is továbbmenni. Ők valószínűleg teljesen elégedettek ezzel a státusszal, és nem kívánják különválasztani a fejlesztési és a tanulás folyamatát.
• A lelkes, de tanulatlan fejlesztő. A felszínen ők is úgy "működnek", mint az előző kategória: ha egy módszert, kódrészletet nem értenek, fellövik a Google-t, és ezzel az iteratív módszerrel folyamatosan új dolgokat tanulnak meg. De ha jobban megnézzük, ők lelkesebbek ennél — saját hobbiprojektjeik vannak, imádják a munkájukat, azonban még mindig nincsenek a kezdetekben említett mély tudás birtokában. Rengeteg ilyen programozó van: imádnak kódolni, de nem tudják azokat a dolgokat, amiket tudniuk kéne. Miért nem vezetett egyenes út a lelkesedéstől a mély szakértelemig? Jó kérdés. Talán nem tudják, hogy mit, hogyan és hol kéne megtanulniuk (kis kitérő: itt szerintem óriási szerepe van az egyetemnek, ugyanis sok mindent elfelejt az ember, amit ott tanul, de a szemléletmódot semmiképp), vagy nem elég tapasztaltak ahhoz, hogy tudják, hogy egy fejlesztőnek nem az az egyetlen feladata, hogy kódot írjon.

Leginkább az utolsó kategóriával érdemes foglalkozni, mert jelen állás szerint bennük nagy potenciál rejlik, de jelenleg némileg elpazarolják a tehetségüket. Ha ők a szisztematikus tanulás felé irányítjuk az energiáikat, bekerülhetnek a legerősebb kategóriába, ami a lelkes, nagy szakértelemmel rendelkező, tanult fejlesztő.

De milyen út vezet idáig, mit kell tennünk ahhoz, hogy ilyenné válhassunk? A SuperCoders nevű ausztrál blog összeszedett néhány pontot, amelynek mentén elindulhatunk a megvilágosodás irányába:

• Különíts el egy kis időt minden nap/héten, amit kizárólag a tanulásra fordítasz.
• Készíts egy listát azokról a dolgokról, amikről már hallottál, de nem tudod pontosan, miről szólnak.
• Böngészd át a saját eszközeid funkciólistáit, és írd össze azokat a dolgokat, amiket nem ismersz.
• Ha találkozol egy új fogalommal vagy módszertannal, tanuld meg. Ne úgy, hogy elolvasol róla pár sort! Forgass fel minden követ, és dolgozz addig, amíg minden részletét pontosan meg nem érted!
• Tanuld meg újra (alaposabban) azokat a dolgokat, amikről úgy gondolod, jelenleg is jól ismered őket.
• Gyakorolj — csinálj példakódokat az újonnan megtanult dolgok alapján.

Joggal elvárható-e, hogy egy fejlesztő a lehető legnagyobb alapossággal ismerje az általa használt eszközöket? Szerintem kétségkívül igen. Ha egy sebésztől elvárjuk, hogy a műtőszoba minden egyes eszközét ismerje az utolsó csipeszig, magunkkal szemben se legyünk kevésbé igényesek. Alapvető feladatunk tehát ezeknek a dolgoknak az elsajátítása, mert egyébként nem csak a munkáltatónkat és a csapattársainkat hagyjuk cserben, hanem valójában saját magunkat is.