"A programozás csak egy eszköz"

HWSW: Ma este (megj: április 4-én) egy prezentációt tart az NNG fejlesztőinek – miről fog majd beszélni?

Scott Meyers: Az előadásom címe: Dolgok, amelyek igazán számítanak. A szoftveriparban fejlesztőként, felhasználóként, oktatóként vagy tanácsadóként eltöltött időm alatt arra jutottam, hogy ha a jelentéktelen részletektől el tudunk tekinteni, akkor vannak olyan tényezők, amelyek egész egyszerűen fontosabbak, mint a többi. Ma este négy ilyen tényezőről fogok beszélni, amelyek közül az egyik a hatékonyság és a sebesség, ami attól függetlenül fontos, hogy mit dolgozunk. Ennek jelentőségét manapság alábecsülik, ami szerintem hiba, a véleményemet pedig ki is fejtem majd.

Beszélni fogok a konzisztenciáról, ami tipikusan olyan tényező, amit mindenki szeretne, de valahogy mindig mellékvágányra csúszik a munka folyamán. Ha megnézzük a szoftverfejlesztés végeredményét, legyen az végfelhasználói szoftver vagy egy API amit fejlesztők fognak hívni, nyilván senki sem azzal a céllal vág neki, hogy „készítsünk egy inkonzisztens interfészt”. Ennek ellenére a végeredmény sajnos sokszor pontosan ez lesz. Mutatok majd néhány példát ilyen inkonzisztens felületekre, illetve elmondom majd, hogy ez szerintem hol és miért problematikus.

Az interfészek ugyanis szerintem a szoftverfejlesztés legeslegfontosabb eredményei, a legvégső cél pedig épp az lenne, hogy ezeket könnyű legyen helyesen, és nehéz legyen helytelenül használni. Ennek az megközelítésnek kellene érvényesülnie minden, az interfészekkel kapcsolatos döntésben. Ezzel persze elvben mindenki egyet is ért, a gyakorlat viszont azt mutatja, hogy csak nagyon kevesek tudják a gyakorlatba átültetni az elméletet.

Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.

Az utolsó dolog pedig az elkötelezettség. Ez szerintem pusztán annyit jelent, hogy azt tesszük, amit mondunk, amiben hiszünk. Mindenki hisz a hatékonyságban, mindenki hisz a konzisztenciában, mindenki hisz a jó interfészekben – de ha mindenki hisz mindezekben, akkor meg kell válaszolnunk a kérdést, hogy mégis miért van rengeteg szoftver, ami lassú, ami szörnyen inkonzisztens és pocsék interfészekkel rendelkezik. Vannak persze legitim okai, hogy ezek a dolgok miért nem teljesülnek 100 százalékban, de azt hiszem ennek ellenére sokkal jobb is lehetne a helyzet.

Ez szervezeti kérdés? Hogyan tudják a fejlesztőcsapatok implementálni és kikényszeríteni ezeket az elveket?

Azt hiszem a legfontosabb az elkötelezettség, tehát amikor eldöntjük, hogy konzisztensek leszünk. A gond az, hogy ez nem mindig egyszerű, ugyanis a csapatok rengeteg különböző kompromisszummal egyensúlyoznak folyamatosan. Tegyük fel, hogy ma leülünk és írunk egy tökéletesen konzisztens rendszert, az interfész nagyszerű, nincsen semmi probléma vele. Három év múlva szeretnénk hozzáadni új funkcionalitást – de közben változott a hardver, változott, hogy milyen eszközöket használnak az emberek, vagy csak egyszerűen eszünkbe jutott, hogy ezt másképp lenne érdemes csinálni. Tehát szeretnénk most valami jelentős változást implementálni az interfészben – de ezt szeretnénk konzisztens és visszafelé kompatibilis módon megoldani. Na ez a kihívás.

^{A legfontosabb irányelv: konzisztencia. Meyers egy korábbi előadása a helyes interfészekről.}

Az okostelefonos felhasználói felületek példája nagyon jó: ezek téglalap alakú kijelzők, álló helyzetben több pixel áll rendelkezésre függőlegesen, mint vízszintesen. De ha fektetett módban használjuk, akkor értelemszerűen változik a helyzet, vízszintesen lesz nagyobb a felület. Olyan felületet tervezni, ami mindkét orientáció mellett konzisztens marad, nagyon nehéz, minden esetben más és más megoldást kell alkalmazni, ahogy a keretek változnak. És ami nagyon zavar, hogy sokszor azt mondják, „az emberek (felhasználók, fejlesztők) majd kitalálják” – én ezt a fajta gondolkodást nem szeretem.

Tehát az inkonzisztencia terhét átteszik a felhasználóra?

Pontosan, a feladattal dolgozzon meg az interfész használója – aki lehet felhasználó, de API esetében lehet fejlesztő is. Ez utóbbi is komoly teher, az inkonzisztens API mellett a fejlesztő is sokkal több hibát vét. Úgy vélem kell egy elkötelezettség, a legfelső szinten kell kijelenteni, hogy „ez tényleg prioritás számunkra”. Nem egyszerű döntés persze a konzisztens interfész kitalálása, a helyes használat megkönnyítése időigényes feladat, de hosszú távon abszolút megéri.

A szervezeteknek hogyan kellene ezt a megközelítést alkalmazni? Van erre valamilyen séma vagy algoritmus? Vagy inkább esetről esetre, rugalmasan érdemes átgondolni?

Alapjaiban ez csak egy vezérelv, a feladatomnak csak azt tekintem, hogy emeljük együtt ennek prioritását a sok más elv és elvárás között. Ha projektmenedzser vagy, rengeteg szempontot kell egyensúlyoznod, a műszaki megfontolások, az implementáció időigénye, nehézsége, a tesztelés, a költségek, a hardveres kompatibilitás mellett. Természetesen ezek szuper magas prioritással futnak, mivel ezekben nem lehet igazából kompromisszumot kötni. Ennek eredménye, hogy azok a területek, ahol viszont lehet kompromisszumot kötni, szenvedni fognak: kell egy új API, ami nem túl konzisztens a már meglévő interfészekkel, de nem gond, a fejlesztők majd megoldják, a lényeg, hogy működjön. Én csak azt szeretném elérni, hogy ezek az általános elvek amelyekről beszélek, kapjanak kicsit több figyelmet az asztalnál, amikor a döntések születnek.

Hogyan lehet tehát ezt a megközelítést beépíteni a fejlesztőcsapatok gondolkodásmódjába?

Adok egy egyszerűbb példát. Alapvetően minden oktatásban, de különösen műszaki területeken a cél meggyőzni a hallgatót arról, hogy változtasson a gyakorlaton, viselkedésén, vegyen fel valamilyen új szokást. Amikor eljönnek az emberek a képzésre, akkor már van egy kialakult gyakorlatuk, tehát arról kellene őket meggyőzni, hogy ezen változtassanak. Ehhez pedig kell egy nagyon jó, meggyőző érvet találni, amire azt mondja „Ah, értem, ezt elfogadom. Másképpen fogom csinálni a jövőben”.

Tehát „megfizetem a költségét, mert látom, hogyan térül meg”?

Igen. És a különböző embereknek különböző koncepciójuk van a költség és a megtérülés mibenlétéről. Programozókkal, különösen C++ programozókkal (ez egy speciális alpopuláció) szemben a hatékonyságot, sebességet szoktam bevetni, mint meggyőző érvelést. Függetlenül attól, hogy én miért gondolom az egyik megoldást jobbnak, a fejlesztőnek azzal kell eladnom, ami számára súlyt hordoz, nem azzal, ami nekem értékes. Ha azt mondom, hogy „jobb minőségű szoftver és 10 százalékkal gyorsabban is fut”, és a hallgatóban csak az marad meg, hogy „10 százalékkal gyorsabb”, már nyert ügyem van. Tehát nem elegendő, hogy a hallgatók elé friss érveket, új információkat vigyünk, azt is el kell mondani, hogy neki miért lesz érdemes változtatnia.

A második fontos dolog, hogy a menedzsmentnek is be kell állnia a felvállalt elvek mögé és el kell várnia azok betartását. Az üzenetnek több irányba is működnie kell: az elvek betartásának segítenie kell a fejlesztő karrierjét, fordított irányban pedig azok megkerülését úgy kell kezelni, mint ami ártalmas a szervezetnek. Ez persze minden esetben igaz, amikor a vezetés váltást szeretne ösztönözni: először nekik kell hinniük benne, enélkül nem megy.

Mondok egy személyes példát. Egy cég kért meg arra, hogy nézzem át egy fejlesztés előtt álló termék műszaki specifikációját – 70 oldal hosszú dokumentáció, nagyon alapos, rengeteg képernyőképpel. Végigolvastam. A probléma: rengeteg kérdést megválaszolatlanul hagy. Ha nekem fejlesztőként ennek alapján kellene dolgoznom, nem lenne benne elég információ ahhoz, hogy elvégezzem a munkám, ezt meg is írtam a véleményezésben. A válasz: semmi gond, csak szükségünk van mindenki láttamozására, mielőtt leülünk és elkezdjük a tulajdonképpeni fejlesztést. Tehát volt egy belső folyamat, amely igényelte a dokumentációt és igényelte a vezetés hivatalos beleegyezését, ezt azonban egyáltalán nem vették komolyan. Az előírt lépéseket teljesítették, készítettek dokumentációt, véleményeztették, megszerezték a jóváhagyásokat, de a munka már nem ennek megfelelően zajlott – egész egyszerűen azért, mert (legalábbis ennek a csapatnak a vezetése) egyáltalán nem hitt a folyamat hasznosságában.

Ezért kvázi mindegy, hogy mit szeretnénk elérni, konzisztenciát, jó interfészeket, jó teljesítményt – nem elegendő az, hogy behívunk néhány trénert, akik elmondják, mit kellene másképp csinálni, hinni is kell benne. És e hit miatt fontos ráérezni, hogy mivel lehet az adott (fejlesztő)csapatot meggyőzni arról, hogy változtasson a meglévő gyakorlaton és bevetni azt a meggyőzéshez.

Ön a terület igazi veteránja – ’72 óta dolgozik oktatóként. Hogy látja, mi változott az elmúlt bő négy évtizedben a számítástechnikában?

Ha arra gondolok, hogy a professzionális fejlesztők hogyan alkotnak programokat ma és hogyan alkottak 30-40 évvel ezelőtt, akkor sokkolóan hasonló a folyamat. Egy szövegszerkesztő előtt ülnek, szöveget visznek be, meghívják a fordítót, betöltik az alkalmazást és futtatják - és ha nem működik jól, debugolják. Ha belegondolok, hihetetlen, hogy még mindig értem, hogyan írják a programokat manapság. Az eszközkészlet persze sokat fejlődött és vannak új metodológiák, automatikus unit tesztelés, ami sokat javított a folyamatokon, de az alapvető tevékenység nem változott. Ez pedig igazán meglepő, ha figyelembe vesszük, hogy ezen a területen amúgy mekkora fejlődés zajlott le.

És ezzel együtt nem változott az sem, ahogy a programozást tanítjuk. Először jön az egyszálú végrehajtás, majd szépen utána a haladóknak a multithreading – ez lehet jó ötlet, lehet rossz ötlet, de évtizedek óta nem változik. Vannak persze programozási nyelvek, ahol más megközelítést használnak – de ezek még ma is pici résterületeket jelentenek. Egész a közelmúltig a szabad szoftveres projektekben a legszélesebb körben használt nyelv a C volt. Ez pedig egy, a ’70-es években kitalált nyelv. Tehát ahelyett, hogy azt mondanám, mi minden változott, inkább az lep meg, hogy mennyi mennyire kevés.

Jó ez? Rossz ez?

Azt hiszem ez rossz. Vagy nem is ez a legjobb szó. Azt hiszem ez egy gyanús dolog. Ez a terület hihetetlenül sokat fejlődött, ha a végtermékeket nézzük. Ma az IT mindenhol ott van, az emberek telefonnak hívott szuperszámítógépeket hordanak a zsebükben. Valaki kiszámolta, hogy ma egy laptop bootoláskor több utasítást hajt végre, mint amennyi ahhoz kellett, hogy embert küldjünk a Holdra és vissza is hozzuk. Tehát itt vannak ezek az egészen elképesztően erős eszközök, de még mindig feltűnően hasonlóan készítjük a szoftvereket, mint korábban. Persze nem minden nyelv működik így.

De az általános nyelvek igen.

Igen, a mainstream nyelvek igen. És persze elfogult vagyok, de azt hiszem a rendszernyelvek a legfontosabbak. Minden ezeken fut. A böngészőink, az operációs rendszereink, telefonjaink rendszernyelvekben (systems language) íródnak. A legalsó szinten mindig a rendszernyelv van, erre tud ráépülni a többi szoftver. És ha belegondolunk, tényleg nem változott a szoftverfejlesztés technológiája az elmúlt néhány évtizedben. Úgy vélem ez gyanús: nem kellett volna itt nagyobb fejlődésnek lennie?

Visszatérve az oktatásra és a tréningre: Ön a probléma frontvonalán volt hosszú ideig. Hogyan kellene képeznünk a következő programozógenerációt?

Az a helyzet, hogy a programozást alapvető készségként kellene tanítani az iskolákban. De lépjünk vissza egyet: a programozás egy eszköz. A programozás lehetővé teszi, hogy alkalmazásokat és rendszereket implementáljunk, de alapvetően egy eszköz, amivel más, fontosabb feladatokat oldunk meg: szimuláljuk, hogyan viselkednek az épületek földrengés esetén, vagy épp üzenetet küldünk valakinek a Föld túloldalára. A programozás eszköz arra, hogy ezt megtegyünk, ebben az értelemben nagyon hasonlít a matematikára.

A legtöbb embernek matematikát kell tanulnia, de alapvetően a matek is csak egy eszköz, amivel más dolgokat teszünk lehetővé – önmagában szerény értéke van a legtöbbünk számára. És ugyanúgy, ahogy a matematika nagyon hasznos szinte mindenki számára, a programozást is úgy kell felfognunk, mint eszközt, amivel más szakmai célokat tudunk elérni. Ha megnézzük, hogy a tudományos életben milyen munka zajlik jelenleg, a mérnököktől a biológusokig és társadalomkutatókig, mind programoznak. Mert programozniuk kell.

Tehát ez egy elengedhetetlen eszköz, de valahogyan hozzáférhetőbbé és kevésbé félelmetessé kellene tennünk. Az ideális ismerkedési eszköz egy olyan rendszer lenne, ahol 5 perc alatt már lehetne saját programocskát futtatni – és okostelefonon kellene futnia. Valami, amit a gyerekek is azonnal tudnának értékelni. Nyilván nagyon egyszerűnek kellene lennie, első körben felesleges fordítóról, memóriakezelésről és hasonló mélységekről beszélni.

És itt érünk vissza oda, hogy a fejlesztői eszközök nem igazán fejlődtek.

A fordítók manapság sokkal jobbak, mint évtizedekkel ezelőtt. Rengeteg új képességgel ruháztuk fel őket. De ez nem változtat a tényen, hogy továbbra is forráskóddal szenvedünk, ami a compileren keresztül készít futtatható gépi kódot. Erre mind szükség van, de el kell rejtenünk valamilyen szoftverréteg mögött.

Tehát egy absztrakciós réteg mögé kell tenni a komplexitást azoknak, akik nem akarnak elmélyedni a programozásban?

Igen, azt gondolom ezzel kellene kezdeni. Azoknak, akik komolyan akarnak programozni, tehát tényleg professzionális programozók akarnak lenni, nyilván hozzáférhetővé kell tenni a teljes eszköztárat. És ez szerintem szövegalapú lesz az előrelátható jövőben. De azoknak, akik csak kezdik a programozást és még csak most ismerkednek a gondolattal, hogy vezérelni tudják a számítógép viselkedését, sokat segítene egy absztrakciós réteg. Hogy érezzék, nem kell géniusznak lenni a programozáshoz, a sikerélmény legyen könnyebben megszerezhető.