Nem fejleszteni, együtt fejleszteni kihívás

1999 óta hivatalosan is vigyáznak a programozókra az égiek, ebben az évben nyilvánította ugyanis II. János Pál Pápa az internet, tudomány és technika iránt érdeklődők, illetve a területen dolgozók védőszentjévé Sevillai Szent Izidort. Szent Izidornak pedig évről évre több dolga van, az IT iparágak ugyanis rohamtempóban növekednek, ami itthon is érezhető, a szegmens szivacsként szívja magába a fejlesztőket és egyéb szakembereket, legyenek azok pályamódosítók, frissen végzettek - vagy akár még az egyetemi padokat koptató hallgatók.

Bár a pálya az elmúlt időszakban egyre nagyobb tömegek számára vált vonzóvá, olyannyira hogy hazánkban is komplett iparágat húztak fel az eredeti szakmájukat inkább fejlesztői életútra váltók átképzésére (elég a Greenfoxra vagy CodeCoolra gondolni), ez nem jelenti, hogy a szegmensben már akár veteránnak számító, tapasztalt fejlesztőknek ne lenne hová fejlődni.

A programozói pályáról, illetve annak jellemző kihívásairól Kevlin Henney-vel beszélgettünk, akit az NNG hívott meg, saját Szent Izidor napi rendezvényére. A hazai vállalat idén harmadik alkalommal ünnepli meg április 4-én a védőszent napját, workshopokkal, előadásokkal és közösségi rendezvényekkel - ahol az ismert tanácsadó-véleményvezérnek is jutott hely a színpadon. Henney neve nem csak az IEEE szoftver tanácsadói testületéből, illetve egy sor, a szoftveres mintázatokat kiveséző írásról lehet ismerős, de a nevéhez fűződik a Twitterről ismert virális "Kevlin Henney screen" mém is.

Kezdve a BASIC-kel - mindjárt az egész családdal

Az NNG székházában nekünk is alkalmunk vált szót váltani Henney-vel, akit egyebek mellett saját pályája kezdetéről és jelenéről, illetve általában a szakma helyzetéről faggattunk. Ahogy sok veterán programozó, Henney is a BASIC nyelvcsaládon nőtt fel, amelynek különböző dialektusait a BBC Micro érát megelőzően használt, Sinclair ZX80, illetve aztán a MOS Technology 6502 mikroprocesszorára építő gépeken sajátította el, majd az Assembly nyelvcsaláddal is közelebbi ismeretséget kötött. A terület fiatalkori felfedezése ugyanakkor nem vezetett egyenes úton a programozói pályára, Henney fizika szakon végzett az egyetemen, ezután kanyarodott vissza a szoftverfejlesztéshez.

Nem meglepő módon a szakember ezt a pontot jelölte meg az első fontos mérföldkőként a területtel szemezők számára - persze vehetjük nulladiknak, hogy az embert egyáltalán érdekelje a programozás. Az első igazán kézzel fogható komoly mérföldkő mindenesetre az első állás a területen, ahonnan aztán élesben is kamatoztathatók a szerzett ismeretek, illetve természetesen a személyes, professzionális fejlődés is folytatható.

Nem volt ez máshogy Henney esetében sem, aki a szakmában eltöltött évek során számos programnyelvet megszeretett, illetve ahogy fogalmazott, magukkal ragadták a programozási paradigmák, a különböző rendszerek megtervezésének, rendszerezésének folyamatai. Gyorsan rájött, hogy mindig van egy újabb, érdekes programnyelv, amellyel új módon, adott esetben hatékonyabban oldhatók meg a problémák. Felfedezte az objektumorientált programozást, amely aztán olyan nyelvekhez vezette el, mint a C++ - ez utóbbinak hála pedig később egészen nagy méretű kódbázisokkal is dolgozhatott.

Megoldani, és megmutatni a megoldást

Henney számára ekkor már világossá vált, hogy a problémamegoldás, és a megoldások magyarázata volt ami igazán lázba hozta, így immár független szakértőként elkezdett írni, prezentálni, tanácsadással foglalkozni - vagy ahogy fogalmaz, kilépni a szobából és beszélgetni az emberekkel, közelről is megnézni, mások mivel foglalkoznak.

Elég embert és projektet végignézve pedig fontos következtetéshez jutott el: valójában "nincsenek új ötletek". Valamilyen formában-módon már szinte minden koncepció megjelent egyes rendszerekben – erre ugyanakkor nem valamiféle problémaként kell tekinteni, sokkal inkább előnyként, hiszen meg tudjuk vizsgálni, mit tudunk már az adott megoldásról és hogyan tudjuk azt tovább fejleszteni, jobbá tenni. Ebből a fajta ismétlődésből jött Henney szoftverminták iránti szenvedélye is - a tudás, a kód újrafelhasználási lehetőségeinek vizsgálatából.

Együtt a mellékvágány is gyorsabban épül

Persze ahogy a szakértő is rámutat, manapság a szoftverfejlesztésben legtöbbször valójában nem elsősorban a kódban kell keresni a problémákat, sokkal inkább magában a szervezetben, illetve azon belül a fejlesztők együttműködésében, kommunikációjában. A szoftverfejlesztő csapatokban komoly intelligencia koncentrálódik - ez azonban alapjáraton csak egyéni, individuális szinten aknázódik ki, magyarán mindenki érti és csinálja is a saját dolgát, ez azonban kevés hozzá, hogy a csapat közösen tudjon összehozni egy szoftvert, kész, jól használható terméket. Nagyon is valós annak a veszélye, hogy a tagok a megfelelő kommunikácó és kooperáció hiányában túlbonyolítanak egy-egy feladatot, és a végén egy jóval összetettebb problémát kreálnak, mint amelyet eredetileg meg akartak oldani.

Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.

A csapatdinamika tehát kulcsfontosságú, rengeteg múlik tagok közötti megfelelő kommunikáción - és ezáltal annak felismerésén, ha egy probléma valójában nem is technikai nehézség, hanem egy összetettebb, a fejlesztőcsapat által lefektetett mellékvágány.

Hogy az iparágban a fejlesztés szociális oldala és dinamikái mennyire fontosak, Henney szerint magukban a programnyelvekben is megmutatkozik: noha a szakértő nem foglalt állást egy kedvenc nyelv mellett, nagyon jó kapcsolatot ápol a C++-szal (amellyel a kapcsolata már olyan hosszú távra nyúlik vissza mint a feleségével), illetve a Pythonnal is. Ahogy fogalmaz, a különböző nyelveket nehéz elválasztani azok köré épülő közösségtől, illetve ökoszisztémától, amelyek érthető módon nagyban meghatározzák azok használatát. Henney például bátran felvállalja, hogy sok esetben jobban szereti a C#-ot mint a Javát, ugyanakkor az utóbbi köré épülő közösséget figyelembe véve már a Java felé billen a mérce.

Ne feledkezzünk meg a többiekről – és a későbbiekről

A fentiek után nem jelent nagy meglepetést, hogy Henney a leggyakoribb és az egyik legkomolyabb programozói hibaként a programozás szociális természetének figyelmen kívül hagyását említette - a szoftverfejlesztés során az ember nem csak egy műszaki, de kommunikációs problémákat is megold, új jelentésrendszert hoz létre. Mikor például az architektúrákról beszélünk, erről hajlamosak vagyunk megfeledkezni: ahogy az épületek szerkezete sem csak azért van, hogy az egy helyben álljon, hanem hogy emberek éljenek és dolgozzanak bennük, úgy a szoftverarchitektúrák sem csak a technikai döntések halmazai, hanem emberek együttműködésének színhelyei.

Egy másik nagy és jellemző hiba, hogy a fejlesztők nem gondolják át, a kód milyen hosszú életet is élhet: egy-egy sebtében megírt, "ideiglenes" javítás rengetegszer felejtődik el, és válik a kód végleges vagy legalábbis hosszú távú részévé, amely fölött aztán a kódot átfutó következő fejlesztő csak a fejét vakarja majd. Ez nem jelenti, hogy az adott javítás rossz ötlet lett volna, de az ideiglenesnek szánt megvalósítás érthető módon nem igazán ideális a végleges rendszerbe, nem is feltétlenül a működés, inkább az érthetőség miatt – amit pedig ideiglenesnek szánunk, a vártnál jóval gyakrabban lesz végleges komponens.

Ha pedig a kód érthetőségénél járunk érdemes röviden a kommentek kérdéskörére is kitérni: Henney szerint a végső cél, hogy a kód magától értetődő legyen - persze könnyen lehet, hogy a legtöbben ezt a célt soha nem érjük el, azonban törekedni kell rá. Ahogy fogalmaz, amennyi információt csak lehet magával a kóddal kell átadni, kommentelni csak azt érdemes, amit maga a kód nem tud elmondani. Ahogy a szakember fogalmaz, a túlzott kommenteléssel a kommentek értéke is elvész.

Kevlin Henney – és a KevlinHenney-k

Ha a kód nem is mindig beszédes, annak eredménye annál inkább - erre kitűnő példák a köztereken is időről időre felbukkanó KevlinHenney-k. Itt nem a szakember különböző instance-eiről van szó, Henney neve ugyanis az idők során egy új jelentést is felvett, és saját UrbanDictionary szócikket is kapott. Eszerint a KevlinHenney egy közterületen bekövetkező szoftverhiba, jellemző példái a repülőtéri információs kijelzőkön megjelenő hibaüzenetek, vagy épp a összeomló ATM szoftverek. A jelenséget Kevlin Henney Screenként is emlegetik, annak gyökerei pedig egészen 2005-ig nyúlnak vissza, mikor Henney elkezdte lefényképezni, és előadásaiban felhasználni vadonban felbukkanó hibaüzeneteket, BSOD-ket. Nem kellett sok idő hozzá, hogy a hallgatóság is elkezdje emailben elküldeni Henney számára saját fotóit. Majd jött a Twitter, és a jelenség valósággal felrobbant. 2016-ban jött a nagy pillanat, mikor egy bejegyzésben valaki megjelölte a szakértőt, mondván, látott egy KevlinHenney-t - Henney először nem igazán tudta hova tenni a dolgot, hiszen ahogy fogalmazott "egész héten otthon volt".

A Kevlin Henney Screenek posztolása a közösségi médiában ugyanakkor nem csak szórakoztató, de hasznos is, hiszen több esetben az érintett vállalatok épp a hasonló felületeken keresztül értesültek a problémákról, amelyet aztán rövid úton javítani is tudtak. A szoftverfejlesztés szociális oldala itt is megmutatkozik - még ha már jócskán tovább is gyűrűzött az adott termék fejlesztőcsapatán.