Az interjú előző két részében a szoftverfejlesztés módszertanáról, alkalmazásáról, az üzleti elemző és a programfaragó közötti különbségekről esett szó. Eljött az idő, hogy egy kicsit technológiaközelibb témákat feszegessünk, lehetőleg úgy, hogy a nem (túl) képzett olvasók is értsék a lényeget.

K.Zs.: Azt állítottad, hogy a különböző programnyelvek közötti különbség többek között az olvashatóság támogatása miatt jött létre. Az adatbázis műveleteket támogató nyelvek, mint az SQL mutánsok és az üzleti funkcionalitást leíró nyelvek, mint pl. a JAVA közötti különbség kézenfekvő. Az adatbázis lekérdezések nagyon bonyolultak tudnak lenni, ennek olvashatóságát jól támogatja az SQL, mely a logikai relációkat nagyon tömören fogalmazza meg. Ezzel szemben az üzleti folyamatok leírására alkalmas objektum-orientált nyelvek (mint pl. a JAVA) lényegesen terjengősebbek, ugyanakkor a nagy kódmennyiség átláthatóságát teszi lehetővé a rugalmatlanságuk. Talán nem annyira triviális a szkriptnyelvek (pl. a PHP, JSP) és a fordítást ígénylő nyelvek közötti különbség (JAVA, C/C++, C#). Miben erős az előbbi, és miben az utóbbi?
M.I.: Egy kis helyesbítés: az objektum-orientált nyelvek véleményem szerint nem a legalkalmasabbak az üzleti folyamatok leírása. Teljesen általános programozási nyelvek, ezért mindent meg lehet bennük csinálni, ennek az a hátránya, hogy általában a problémák sokkal terjedelmesebben írhatóak le benne, mint egy speciális, az adott (üzleti) problémára megalkotott nyelvvel.

Az eredeti kérdésre visszatérve. Mind az interpretált szkriptnyelvek, mind a fordítást igénylő nyelvek alkalmasak arra, hogy ugyanazt a problémát megoldják. Sőt, ugyanahhoz a nyelvhez létezhet interpetált és fordító segítségével futtatott kód is. Az interpretált nyelvek sok szempontból rugalmasabbak, viszont lényegesen lassabbak is, mint a fordított nyelvek. Gyakran a kétféle módszert egyszerre is alkalmazzák: pl. Java forráskódot lefordítanak bytecode-ra, majd a VM interpretálva futtatja azt. .NET esetében egy közbülső nyelvre történik a fordítás (IL), majd ezt fordítják gépi kódra, de létezik VM .NET alá is.
Én úgy tudom, hogy pl. a Java, C# nyelvek esetében (ezek tipikusan fordított nyelvek) a fejlesztés közbeni IDE-támogatás erősebb (ld. refaktor, kódanalízis), mint pl. a PHP-esetében, viszont a szkriptnyelvekben sokkal rövidebb egy szerkesztési és futtatási ciklus (edit-run) ideje.

LAMP vs. .NET

K.Zs.: Egyre nagyobb népszerűségnek örvend a LAMP (Linux + Apache + MySQL + PHP) platform. Számos PHP fejlesztőtől hallottam már azt, hogy a PHP 5 óta olyan szintű objektumorientáltságot támogat a PHP, mely akár egyenértékűnek tekinthető a JAVA-val. Hogyan magyaráznád el egy PHP fejlesztőnek a .NET-re, vagy JAVA-ra épülő architektúrák által nyújtott előnyöket? Valóban szükséges az a bonyolultság, melyet ezek a platformok biztosítanak egy-egy üzleti funkció fejlesztésekor?
M.I.: A LAMP platform alkalmas a legtöbb probléma megoldására. Nagyon jó közösségek vannak, ahol az emberek ingyen segítenek egymásnak, és nagyon nagy a kódbázis is. A .NET platform alapvető előnye, hogy a microsoftos technológiákkal nagyon jól integrálódik (nyilván sokan ismerik a Microsoft Office programcsaládot, a SharePoint Servicest, Microsoft Exchange-t, MS SQL-t stb.) A .NET és JAVA platform együttes előnye maximális rugalmasságukban és hatékonyságukban rejlik: a legspeciálisabb feladatokat is meg lehet bennük oldani. (Na, jó, azért vannak kivételek:) Az objektumorientáltság csak egy rendezőelvet biztosít, vannak ezen kívül technológiai megfontolások, és az sem másodlagos, hogy bonyolultabb problémák megoldásához milyen eszközkészlet áll a rendelkezésünkre (ami a JAVA és .NET világban igencsak kifinomult).

Az olvasható kód

K.Zs.: Tudnád illusztrálni egy példával a kifejező és nem kifejező program közötti különbséget?
M.I.:Előszöris rögzítsük le, hogy nem programnyelvek, hanem egy programnyelven készült programok közötti különbséget próbálom szemlélteni. Pl. tegyük fel, hogy az a feladat, hogy vannak könyvek; szeretném megjeleníteni a programmal a legolcsóbb és a legdrágább árat. A következő két programot is megírhatom (JAVA-ban):

public class Algorithm {    public static void printPrices(List<Book> books) {         int min = books[0].getPrice();         int max = books[0].getPrice();         for(int i = 1; i < books.length; i++) {             if(max < books[i].getPrice()) max = books[i].getPrice();             if(min > books[i].getPrice()) min = books[i].getPrice();         }         System.out.println(min);         System.out.println(max);     } }
public class AlgorithmNice {    private static int calculateMinPrice(Collection<Book> books) {         int minPrice = Integer.MAX_INTEGER;         for(Book book : books) {             if(minPrice > book.getPrice()) {                 minPrice = book.getPrice();             }         }         return minPrice;     }    private static int calculateMaxPrice(Collection<Book> books) {         int maxPrice = -1;         for(Book book : books) {             if(maxPrice < book.getPrice()) {                 maxPrice = book.getPrice();             }         }         return maxPrice;     }     public static void printMinMaxPrice(Collection<Book> books) {         System.out.println(calculateMinPrice(books));         System.out.println(calculateMaxPrice(books));     } }

Kicsit csaltam, mert a második programban a kulcsszavak félkövérrel vannak szedve, ami tovább növeli az olvashatóságot. A példa nagyon egyszerű, és ha csak ennyi lenne a feladat, akkor tökéletes lehet az első megoldás (gyorsabb, sokkal rövidebb, mint a második). (Ki veszi észre a hibát benne?:))
Ami a második mellett szól (azon kívül, hogy semmi nem indokolja, hogy egy ilyen egyszerű feladatot így oldjunk meg), az az, hogy - szerintem legalábbis - könnyebben olvasható. Legnagyobb előnye, hogy felülről lefelé könnyen megérthető, mert elegendő a printMinMaxPrice-ra néznem (a metódus elnevezése is más, mint az első esetben!!), és egyből tudom, mit fog csinálni. Először kiírja a legkisebb értékű könyvet majd a legnagyobb értékűt. Az első programmal ellentétben nekem végig kell követnem a teljes metódust, hogy megértsem, hogy az egész egyszerre kiválasztja a minimumot és maximumot, majd a végén kiírja azokat. Számos apróságban is más a második megoldás, és ami különbség, az számomra egyértelműen jobb megoldás, mint az elsőben. (Kérem, tekintsen el a kedves olvasó attól, hogy mennyire egyszerű is a feladat, nagyobb méretekben még számottevőbb lenne a különbség.)
Megjegyzés: a bitvadászok kedvéért azért megemlítem, hogy vannak olyan helyzetek, amikor az első típusú megoldások a jobbak: beágyazott (pl. mobiltelefon) programoknál fontos a hatékonyság, és a hatékony program írása erőteljesen a programkód (emberi) értelmezhetőségének a rovására megy. Az esetek többségében azonban a második megközelítés a célszerűbb.

Személyes vonatkozások

K.Zs.: A rövid kódrészlet után következzen egy kis szakmai reflekció! Miért választottad ezt a szakmát? Mit jelent számodra az informatika?
M.I.: Számomra ez nem egy tudatos választás volt. Kiskoromban a szüleim vettek egy Commodore gépet, amin elkezdtem a biteket gyúrni :) Erre tanáraim is felfigyeltek, és nagyon sok számítástechnika és matematika versenyen is részt vettem. Ezek az alapok már adták magukat ahhoz, hogy a középiskola után a Budapesti Műszaki Egyetemen is informatikával foglalkozzam, és ezen a területen dolgozzam.
K.Zs.: Milyen kihívásokkal szembesülsz munkavégzésed során?
M.I.: Maguk a projektek is változatosak (eddigi szektorok, amikben szoftvert fejlesztettem: elektronikus oktatás, ipari termelés modellezés, villamos engeriaipar, banki szektor, iratkezelés). A problémák egy adott projekten belül is eléggé változatosak, de lehet, hogy ezt nem mindenki látja így:)
Nagy kihívást jelent az adott üzleti terület megértése, a bennük résztvevő szereplők gondolkozásának megismerése, az üzleti domain kialakítása, a jó felhasználói felület megtervezése, az önkifejező kódolás, automatizált tesztelés, az ügyféllel való kommunikáció, a csapaton belüli munkaszervezés, szóval minden :)
K.Zs.: Milyen tanácsokkal látnád el a 10 évvel fiatalabb Marhefka Istvánt? Melyik volt a legjobb/legrosszabb szakmai döntés, melyet meghozott ezalatt az idő alatt?
M.I.: Én úgy gondolom, hogy nem számít, ki milyen döntést hozott korábban. A lényeg az, hogy élvezze, amit csinál: művelje és értékelje! Én soha nem bánom meg korábbi döntésemet, azon pedig nem szoktam gondolkozni, hogy a legjobb döntést hoztam-e meg, mert nem tudom (és nem is akarom) lefuttatni a végtelen sok többi lehetőséget.
K.Zs.: Milyen volt az első munkavállalói interjúd?
M.I.: Másodéves egyetemista voltam. Egy kis céghez jelentkeztem, az interjú pusztán szakmai volt. Nem emlékszem, mik voltak a kérdések, de egy részük a C++-hoz kapcsolódott. Arra emlékszem, hogy tudtam egy olyan kérdésre a választ, amire az interjúztató - saját állítása szerint - még nem hallotta a helyes választ senkitől, akitől kérdezte. Így aztán szimpatikussá váltam, és felvettek a munkára:) Ez jól esett:)

Curriculum

K.Zs.: A Synergonnál betöltött vezető fejlesztői pozíciód mellett középiskolások országos és nemzetközi informatikai olimpiára való felkészítésében is részt vállalsz. Milyen jellegű kihívásoknak kell eleget tenniük ezeknek a fiataloknak?
M.I.: Magam is részt vettem ezeken a versenyeken középiskolás koromban, ezért jól ismerem a tematikát. Ezek a versenyek az algoritmikus problémákról szólnak (tehát semmi közük nincs az iparban előforduló legtöbb feladathoz). Nagyon gyors problémamegoldó, logikai és matematikai képességet igényelnek, és ráadásul jó kódernek is kell lenni:)
Akiket érdekelnek a problémák, szemezgethet a következő oldalról: http://sagv.gyakg.u-szeged.hu/verseny/szamtech/nemes/olimpia.htm
K.Zs.: Mit ajánlasz a pályakezdő informatikusoknak? Milyen célokat érdemes kitűzni?
M.I.: Légy bátor, ne félj a kihívásoktól és a nagyoktól! Ugorj bele a közepébe, a többi meg úgyis jönni fog! :)
K.Zs.: Egy átlagos képességű fejlesztőnek mennyi időre van szüksége ahhoz, hogy magasszintű programozói tudásra tegyen szert?
M.I.: Szerintem jó környezetben (megfelelő projektekkel és kollégákkal) 4-5 év alatt elsajátítható a dolog. Ehhez persze szükséges egy megfelelő alap (pl. egy felsőfokú diploma, de nem ez szükséges feltétlenül).
K.Zs.: Hogyan lehet tanulni a programozást?
M.I.: Szerintem alapvetően a tanulás most is (mint 10-20 évvel ezelőtt is) autodidakta módon történik (most leginkább az Internet segítségével). A magyarországi oktatási rendszer (sem a középfokú, sem az egyetemi) nincs felkészülve erre az őrült rohanásra, ami az iparban lezajlik.
K.Zs.: Milyen szakmai olvasmányokat ajánlasz?
M.I.: 
Eric Evans: Domain Driven Design - hogyan fejlesszünk szoftvert úgy, hogy a központban az üzleti problématér van.
Martin Fowler: Refactoring - ez volt számomra az első korszakalkotó könyv, ami az agilis szoftverfejlesztés irányába vitt el. A ma már viszonylag jól ismert refaktorálás alapjait mutatja be, sokat lehet belőle tanulni, ha az ember pusztán csak egy _jó_ programozó szeretne lenni.
Martin Fowler: Patterns of Enterprise Application Architecture - a vállalati alkalmazásokban előforduló leggyakoribb mintákat mutatja be. Nagyon jó elméleti áttekintés.
Nem technológiai jellegű könyveket szedtem össze (azok viszonylag "múlandóak"), hanem olyanokat, amelyek gondolkozásmódjuknál fogva elősegítik a minőségi szoftverfejlesztést.

Spiritualitás & mit hoz a jövő

K.Zs.: A legtöbb informatikus barátom szkeptikusan tekint a spirituális és vallási témákra. Az informatikusok a misztikusságra való hajlamukat többnyire tudományos-fantasztikus filmek és könyvek segítségével élik meg. Mindemellett meglepetten tapasztalom, hogy az erős kritikai érzék mellett sok kollégámban jelen van a spiritualitásra való érzékenység. Úgy gondolom, hogy az erős kritikai érzék lehetővé teszi, hogy az efféle érdeklődés stabil, józan talajon bontakozhasson ki. Kedvelem az efféle pragmatikus alapokra épülő spirituális vonzalmat, mert nem esik áldozatául a naivitásnak.
M.I.: Én úgy gondolom, hogy bárminek a megéléshez, megtapasztalásához egyaránt jelenthet gátat a naivitás és a kritikus szemlélet is. Amikor valaki valamit elhisz, akkor nem adja meg a lehetőséget arra, hogy azt a bizonyos dolgot saját maga is megtapasztalja, mert már ő azt gondolja, hogy az úgy van, ahogy mások mondják. Ha valaki kritikus, akkor pedig alapvetően megtagadja magától a megtapasztalást, mert "csípőből" kizárja annak a bizonyos dolognak a megismerését.
Egy kedves ismerősöm szavaival élve: "ne higgy el semmit!" :)
...és ez nem azt jelenti, hogy légy szkeptikus!
K.Zs.: Tehát a recept a pragmatikus hozzáállás nyakonöntve egy adag józan paraszti ésszel?
M.I.:Nincs recept.
K.Zs.: Az informatika gyorsan változó világában elsöprő fölényt élveznek a fiatalok az idősebbekkel szemben. Alig látni negyven évnél idősebb programozót szoftverfejlesztéssel foglalkozni. Látod magad ötven évesen, amint gyúrod a kódot?  
M.I.: Úgy gondolom, a gyakorlati dolgokban nem lehet a fiatalokkal felvenni a versenyt, ebből fakadóan nehezemre esik azt hinni, hogy versenyképes lehetek majd effektív kódolásban az akkori fiatalokkal szemben. Mindegyis: nem tudom még, mit hoz a jövő (túlságosan nem is izgat) - lehet, hogy akkor már nem is informatikával fogok foglalkozni:)
K.Zs.: Szerencsés fejlődési ívnek tartom a kódolástól az üzleti tanácsadásig való elmozdulást. 
M.I.: Ha egy vízszintes skála egyik szélén a kódolás van, a másik végén az üzleti szemlélet/gondolkodásmód, akkor valahol a kettő között középen érzem magam. (Mindkét munkában otthonosan érzem magam.) Affinitásban már az utóbbi talán jobban izgat. Valakit viszont egy jó kis buborékrendezés hoz lázba. Szerintem nem baj egyik sem, az a fontos, hogy azzal foglalkozhassunk, amit szeretünk is csinálni.

V É G E

A képen Marhefka István. A fotó 2007 nyarán készült Szaranszkban (Oroszország), az ott megrendezésre került finnugor találkozón.

Illusztrációk

• http://www.photosight.ru