A szoftverfejlesztés művészete - 1. rész

Programot írni sokféleképpen lehet. Az elsődleges olvasat szerint a fejlesztő lényegében egy droid, aki a felmért üzleti igények alapján programot farag. Ezen interpretáció szerint az ideális szoftverfejlesztő alacsonytermetű, szemüveges, dadogó, zsíroshajú, szociofób szájbermániás. Ez a sztereotípia a mai napig jelen van, jóllehet manapság már csak ritkán látni efféle bitekből összeállt humanoidot.

A ma szájberfenegyereke az Űrodusszeán és Asimovon szocializálódott; mivel azt csinálja, amit szeret, többnyire lelkesen teszi azt. Ha az informatika megfertőzi az embert, az énjének egy része örökre a kibertér fogságába kerül.
Meglátásom szerint a szoftverfejlesztés egy bizonyos szinten túl elsősorban kommunikációs készségre épül. A monoton racionalitás helyett kreatív nyelvhasználat szükséges ahhoz, hogy az üzleti igényből használható szoftver váljék. Adott a számítógép, és adott a fejlesztő, ki utasításai révén munkavégző eszközzé hangolja azt. Hogyan történik mindez? Erről faggatom Marhefka István kollégámat, a Synergon Informatika Nyrt. vezető fejlesztőjét.

A kétféle programozó

K.Zs.: Mivel foglalkozik egy programozó?
M.I.: Előszöris hadd fűzzek néhány gondolatot a bevezetőhöz. Az informatikának számos területe van. Amiről itt alapvetően szó esik, az a (nagy)vállalati, egyedi szoftverfejlesztés, amelyet kis létszámú (3-6 ember), de ütőképes csapat projektszerűen űz. Tehát pl. más-más képességek kellenek egy egyetemi kutatási projekt informatikai rendszerének elkészítéséhez (legyen az pl. nagy prímszámok keresése, elosztott algoritmusok tesztelése/készítése, távközlő hálózatok szimulációs programja), egy grafikus tervezőprogram implementálásához vagy egy ügyviteli szoftver megírásához. Ha nagyon le akarom egyszerűsíteni, akkor alapvetően két táborba oszthatóak a fejlesztők.

  • Az első csoportba azok tartoznak, akiket a programozás technológiai része nyűgöz le, és legszívesebben az új technológiák kipróbálásával, összeintegrálásával szeretnek foglalkozni, és kevéssé izgatja őket egy adott üzleti probléma.
  • A másik tábort - az előzővel ellentétben - érdekli maga az üzleti probléma (is), szereti megérteni, hogy a fejlesztendő rendszert használóknak (a Megrendelőnek) mik az elvárásai a rendszerrel szemben.

A két tábor nem élhet egymás nélkül, ha közösen kell egy projektet teljesíteni, vagy fordítva: mindkét táborból kellenek emberek egy adott projekt sikeréhez. Azért azt is szeretném leszögezni, hogy nem feltétlenül éles a határ a két tábor között, tehát egy emberben meglehet az érdeklődés mindkét terület felé. Azért az a jellemző, hogy egy projekten belül is fel kell valamennyire osztani a szerepeket: valakinek nagyon jól kell ismerni az üzleti folyamatokat (business analyst/üzleti elemző, lead developer/vezető fejlesztő), és neki nem lesz arra ideje, hogy a fejlesztés során felmerülő technológiai problémákba bele ássa magát, és fordítva. Ideális esetben pedig van olyan ember (architect), aki ismeri az alkalmazott technológiáknak a csínját-bínját.

Billentyűk

K.Zs.: Úgy tűnik, hogy elég jól definiálható ez a két féle programozási kompetenciakör. Magam is tapasztaltam, hogy az a fejlesztői csapat, melyben az általad megnevezett üzleti szemléletű fejlesztő és a technológiailag képzett architektus egyaránt jelen van, lényegesen hatékonyabb, mint a hagyományos homogén kódercsoport. A gyakorlatban többnyire a technológiai-guruk vannak túlsúlyban, csak ritkán találni olyan vezető fejlesztőt, aki az üzleti problémákra is fogékony. Talán ez annak tudható be, hogy aki programozónak tanul, az többnyire a technológia-közeli informatikai problémákkal foglalkozik, és csak ritkán terjed ki a figyelme/érdeklődése más területekre. A szoftverfejlesztésben járatos üzleti elemző tulajdonképpen interdiszciplináris területen mozog: mélyrehatóan ismernie kell az adott üzleti területet, ugyanakkor a zsigereiben van a programozás.
Világosan körvonalaztad a két tábort, mely mentén a programozókat különválaszthatjuk. A kérdés az, hogy milyen kézségekre van szükség ahhoz, hogy valakiből jó programozó lehessen?
M.I.: Ha össze kellene írnom pár olyan tulajdonságot, amiknek bizonyos fokú megléte biztosítja azt, hogy valaki jó fejlesztő, akkor a következőket írnám:

 

  • jó kommunikáció (mint szóban, mint írásban, mint kódban!!),
  • üzleti gondolkozás,
  • problémamegoldó készség,
  • absztrakció,
  • algoritmikus készség,
  • technológiai ismeret,
  • programozási ismeret/kódolási stílus.

A fent említett két tábor tagjai között más-más súlyozással venném a fenti tulajdonságok fontosságát, ill. bizonyos tulajdonságok erőteljesen projektfüggőek is (pl. általában nem kell kiváló algoritmikus képességgel rendelkezni a legtöbb probléma megoldásához, viszont bizonyos esetekben nagyon sokat jelent ez a képesség).

Digitális szem

K.Zs.: Valóban "csak" egy ilyen készséglistán múlik mindez? Ha interjúztatás alapján ki kellene választanod a tökéletes üzleti elemző/programozót, mire összpontosítanál? Mi lenne az a "szikra", ami alapján rátalálhatsz az ilyen habitusú vezető fejlesztőre?
M.I.: Mindenképpen azt kell éreznem, hogy az illető, akivel beszélgetek, szenvedéllyel beszél eddigi projekteiről, tapasztalatairól. Az a szikra, amit én keresek, az a "gondolkozásra való készség" fűszerezve egy kis kreativitással, egyéni fantáziával. Nem lehet leírni, valójában mit is jelent ez, de úgy gondolom, hogy ha az illető meg tud győzni arról, hogy ő különleges(!), akkor valószínűleg sikerrel fog járni.
Meggyőződésem, hogy az ember kifejezőkészsége (nyelvi választékossága, stílusa) sok mindent elárul.
A szakmai kvalitáson túl természetesen az egyik legfontosabb dolog, hogy az interjún résztvevő megbízhatónak tűnjön. Ez a minimum mindenképp szükséges az eredményes munkavégzéshez. Ehhez természetesen a munkaadónak is kellőképpen kell tudnia motiválnia az illetőt.
K.Zs.: Azt vettem észre, hogy többnyire azokból a fejlesztőkből lesznek üzleti elemző/programozók, akiket nem elégítenek ki a technológiai kihívások. Ezek a személyek rendszerint a humán területekkel is jó viszonyban vannak, jó nyelvérzékkel és kommunikációs készséggel rendelkeznek. Fontos felismerni, hogy az alkalmazásfejlesztés sikerességét a legtöbbször néhány ilyen kulcsfigura jelenléte határozza meg, és nem a projekttagok számossága. Sokkal hatékonyabb alkalmazni néhány magasan képzett üzleti elemző/programozót és néhány droidmunkást, mint sok középszintű fejlesztőt.

 

Droid

M.I.: Várj egy kicsit! A droidmunkás szó alatt nem tudom pontosan, mit értesz, de ha ugyanarra gondolunk, akkor én őket egyáltalán nem alkalmaznám. Egy ilyen droidmunkással történő foglalkozás rengeteg időt emészt fel (felügyelni és javítani a munkáját, állandó kommunikáció vele), ráadásul  - meggyőződésem szerint - az ilyen emberekkel szembeni meggyőződés erőteljesen alacsony, ami rontja a munkamorált, akár a teljes csapaton belül. Az ideális elképzelésem a projektteamről kicsit az XP-re hajaz, ahol a kis, de ütőképes csapatot csupa senior fejlesztő alkotja. Ez persze vagy így van egy adott szituációban, vagy nem.
K.Zs.: Nehéz igazán jó senior fejlesztőket fogni manapság. Éppen ezért a vállalatok gyakran kevés tapasztalattal rendelkező, ám ígéretesnek tűnő fiatalokat alkalmaznak, abban bízva, hogy néhány év alatt senior fejlesztővé növik ki magukat. Ezekszerint fontos kérdés lehet, hogy miként lehet megérezni egy junior fejlesztőn, hogy van-e kellő potencialitás benne, melyek kibontakoztatása révén idővel igazán értékes fejlesztővé válhat. Három szempontot említettél, melyet érdemes figyelembe venni az interjú során: szakmai tudás, kifejezőkészség, megbízhatóság. Miből látszik egy junior fejlesztőn, hogy kellő szakmai tudás birtokában van?
M.I.: Egy junior fejlesztő csak kevés szakmai tudás birtokában van. Alapvetően az érdeklődés és a logikus gondolkodás számít, és a már említett szenvedélyesség.

Bezárva

K.Zs.: Talán kevesek gondolják úgy, hogy a kifejezőkészség ilyen fontos szerepet játszik a programírásban! A sztereotíp programozó zárkózott, szűkszavú, irodalmilag alulképzett, összefüggéstelenül dünnyögő éjszakai manó. Az általad felvázolt fejlesztő nagyon távol áll mindettől: egy bizonyos szinten túl pontosan a kommunikációs készsége teszi igazán hatékony munkaerővé.
Hallottam egy történetet egy neves közgazdászról, aki arra utasította a tanítványait, hogy mindenekelőtt tanuljanak meg zongorázni, ha jó pénzügyi szakemberek akarnak lenni, mert a szaktudást bárki elsajátíthatja, de az intuitív rálátást csak azok, akik képesek holisztikusan szemlélni a jelenségeket. Ehhez a legjobb út, ha valamilyen művészeti ágban képezzük magunkat.
Az általad felvázolt tanács a leendő senior programozók számára az lehetne, hogy tanuljanak meg előadni, érthetően fogalmazni, egyszóval fejlesszék a kommunikációs készségüket! A világos közlési stílussal rendelkező kóder olvasható kódot ír.
M.I.: Sokat próbálom a munkatársaimat figyelni, és azt vettem észre, hogy a legjobb azokkal dolgozni, akiknek széles a látókörük és fogékonyak a szakmán kívül más dolgokra is. Mivel a kreativitás nagyon fontos, azt vettem észre, hogy az "értékes emberek" rendszerint valamilyen humán/művészi területen (területeken!) is kiemelkedőek vagy igencsak érdeklődőek iránta. ...és lehet, hogy ezzel nincsenek is tisztában! Ilyen megközelítésben egyet tudok érteni az általad említett neves közgazdásszal.
A kommunikációs készség fejlődésének egyik jele a felekkel történő kölcsönös megértés. Ilyetén módon a rendszeres előadás segíthet abban, hogy ez a készség javuljon.
Én pl. amikor valakivel beszélgetek, mindig azon jár az eszem, hogy úgy fogalmazzam meg a gondolataimat, hogy azt a partnerem megértse. Ezért ha ugyanazt a dolgot is kell elmondanom több embernek különböző alkalmakkor, soha sem lesz ugyanaz az előadásom, mert mindig próbálok ráhangolódni a másikra, és úgy fogalmazni, hogy az kifejezetten rá legyen testre szabva.

Programnyelvészet

Programnyelvészet

K.Zs.: Hogyan lehet kiigazodni a sokféle programozási nyelv között?
M.I.: Általában megvannak az "iparnak" a használatos eszközei, ismert a mainstream, és a szakma ezt alkalmazza. (Ez nem csak a programnyelvekre, de a kapcsolódó technológiákra/platformokra egyaránt igaz.)
Egy programozónak egyszerre több nyelvet is kell "beszélnie": gondoljunk bele abba, hogy manapság szükséges ismerni az alkalmazott platform "standard" nyelvét (pl. java, c#), mellette használatos még az SQL, XML, a kézzel fabrikált .txt vagy config állományok. Miért van ennyiféle nyelv? Azért, mert mindegyik nyelvben bizonyos problémákat egyszerűen lehet formálisan leírni.
Pl. manapság a legdivatosabb "irányzatok"/platformok (sorrendiség nélkül): Java, .NET, PHP, Ruby. A .NET ezek közül nyelvfüggetlen, tehát elvieg mindegy, hogy milyen programozási nyelvet használunk a fejlesztéshez (a két legelterjedtebb a C#, és VB.NET). A Java nyelv kötött szintaxisú, míg a Ruby nyelve annyira rugalmas, hogy annak a segítségével úgy írhatunk programot, mintha az kvázi egy másik programnyelven íródott volna. (Ez önmagában egy paradoxon hangzik, ld. a makrókat C-ben.)
Alapvetően a programnyelvek célja az, hogy egy közös hidat építsenek az emberek és a számítógép között. Formálisnak kell lennie, mert csak így fordítható le a megadott program a számítógép belső utasításaira, de viszonylag olvashatónak is kell maradnia, hogy az emberek is megértsék. Az olvashatóság nagyon fontos szempont, ezért létezik az a sokféle nyelv (pl. SQL, XML, Java). (No, meg azért, mert piacgazdaságban élünk:))
K.Zs.: Hogyan viszonyulnak a programnyelvek az emberi nyelvekhez?
M.I.: Az emberi nyelvek (természetes nyelvek) túlságosan nagyvonalúak, "hanyagok" abban az értelemben, hogy nem foglalkoznak a részletekkel, mint ahogy magunk is éhen halnánk, ha úgy kellene beszélnünk egymáshoz, mint egy számítógéphez (bizonyára mindenki látott már jó pár szerződést az életében, amely "emberi" (?) nyelven (jogi nyelven) próbál leírni egy egyezményt). Az emberi kommunikációhoz kialakultak azok az egyszerű nyelvek, amelyekkel az esetek többségében könnyen és egyszerűen tudunk információt cserélni valakivel, úgy hogy fenntarthassuk magunkat.
Egy jó programozónak arra kell törekednie, hogy a programkódja (az az a valamilyen nyelven megírt programja) önmagában is kifejező legyen, mintha csak egy történetet mesélne el egy másik embernek, mert a kódot nem csak a számítógépnek írjuk, hanem saját magunknak, sőt, kollégáinknak is!

Új hozzászólás

Hozzászólások

Érdekes írás a programozásról, várom a folytatást. A szoftverfejlesztés és a művészet szavakat ritkán látni egymás közelében, ezért már a címnek is nagyon örültem.
A szoftverfejlesztésben azt szeretem a legjobban, hogy itt lehetőség van arra, hogy az ember tökéletest alkosson. Ez hatalmas hajtóerő tud lenni az igazán minőségi szoftverek elkészítése felé, főleg annak, aki maximalista :)
A felmerülő problémákra mindig létezik egy végtelenül egyszerű és elegáns megoldás, és ha az ember ezt megtalálja, akkor az kitörő sikerélménnyel jár. Ha valaki egyszer ráérez ennek a dolognak az ízére, akkor nem fogja tudni abbahagyni. Szerintem itt kezdődik a művészet, amikor az emberben megjelenik ez a fajta igényesség, amikor nem csak egy eladásra kerülő terméket hoz létre, hanem egy műalkotást, amiben benne van a szépség, az algoritmusok, a működési metódusok, a problémák elegáns és tiszta megoldásának a szépsége, a tökéletesen működő gépezet szépsége. Ezeket a szoftvereket leginkább azokhoz a gyönyörű motorokhoz lehet hasonlítani, ahol minden csavar a helyén van, minden hézag a megfelelő méretű, minden időzítés tökéletes, és már csak a hangjuk miatt is érdemes őket beindítani.

Érdekes írás a programozásról, várom a folytatást. A szoftverfejlesztés és a művészet szavakat ritkán látni egymás közelében, ezért már a címnek is nagyon örültem.

http://www-cs-faculty.stanford.edu/~knuth/taocp.html

http://en.wikipedia.org/wiki/The_Art_of_Computer_Programming

Szóval lehet, hogy ritka, de nem teljesen egyedi! A motoros példa viszont tetszik.

Számomra a szabad szoftver mozgalom is egyrészről arról szól, hogy az ember nem magára a programra büszke, hanem az abban alkalmazott megoldásokra, vagyis az forráskódban leírt algoritmusra. ;) Egy feszített tempójú fejlesztés során ugyanis nem mindig van idő kiélni a művészi hajlamot. Sok kísérletezéssel jár ugyanis amíg az ember fia elkészíti a tökéleteset.
Ami az igazán izgalmas az egészben, hogy a kész terméknek olyan nagy számú paraméternek kell megfelelnie, mely "józan ésszel" már fel nem fogható ;) Gyakran csak a probléma egy részproblémájára lehet jó megoldást adni, ekkor kérdés az, hogy hogyan tudjuk ezeket a részmegoldásokat úgy egy egészbe ötvözni, hogy a gyakran ellentmondó igényeknek meg tudjunk felelni. Na ez a művészet.

Szerintem az igazán vonzó a programozásban az, hogy pillanatok alatt képes sikerélményt nyújtani. Bármi mást csinál az ember hosszas gyakorlás után ér csak el olyan eredményeket amelyre büszke lehet. (gondolok itt a modellezésre, vagy a különböző sportokra stb.)

sose felejtem el ;)

10 print "hello"
run 10

A cikk erősségét pedig abban látom, hogy - hasonlóan az itt olvasott cikkekhez - képes elemelkedni a talajtól és felülről rámutatni olyan összefüggésekre, melyek itt a földön állva nem láthatóak ;)

Várom én is a folytatást.

pp

A cikk nagyrészével egyetértek, sőt, kicsit személyesen érintve is érzem magam. ;)

Annyival egészíteném ki, hogy amit fentebb írtatok egy „hagyományos” berendezkedésű vállalati struktúra, ahol a BA tartja a kapcsolatot az ügyféllel, terveket sző, beszámol a vezetőségnek, segíti a munkában résztvevő többi kollégát stb.

Viszont sokkal inkább kíváncsi lennék István és Kulcsi véleményére az önszerveződő freelancer csoportok és a fenti „vállalati sztenderd hierarchia” között, pro és kontra, milyen üzleti szegmenseket tud megcélozni és miért. Előre is köszönöm a válaszotokat.
--
Aries

Aries, tapasztalatom szerint minden esetben szükség van egy fővállalkozóra az adott tender megnyeréséhez.

Gyakori az a felállás, hogy van egy fővállalkozó, aki viszi a projekt üzleti felét, az összes technikai részt pedig továbbítja az alvállalkozók irányába. Az elefánt és a bolha modell nagyon működik, viszont a sok bolha elefánt nélkül, vagy a bolhamentes elefántok szövetsége már nem annyira.

Tehát a freelancerek (bolhák) nagyvállalatokhoz (elefántokhoz) tapadva tudnak hatékonyan érvényesülni. Legalábbis nagyobb projektek esetén...

Nem erre gondoltam, hanem arra az alternatív lehetőségre (talán nevezhetjük paradigmaváltásnak is), ahol emberek fizikailag egy helyen dolgoznak, de mégsem egy cégként szerveződnek. El tudok képzelni egy olyan irodaházat többszáz fejlesztővel különböző területekről, amely tele van párfős bt-vel és kft-vel, és ezek egy-egy projekt vagy annak supportja erejéig közösen dolgoznak. Költséghatékony és nagy potenciált képvisel.

Manapság egy fejlesztő önmagában sokkal jobban brandelhtető, mint egy vállalat. Az, ami itthon ismert név, valószínű Svédországban vagy Szöulban senkinek nem mond semmit, de egy fejlesztőnél, aki lehet akár egy nemzetközi közösség aktív tagja, igen.

--
Aries

Gyakran csak a probléma egy részproblémájára lehet jó megoldást adni, ekkor kérdés az, hogy hogyan tudjuk ezeket a részmegoldásokat úgy egy egészbe ötvözni, hogy a gyakran ellentmondó igényeknek meg tudjunk felelni. Na ez a művészet.

Igen, valóban izgalmas kérdés, hogy miként lesz a részekből egész, hogyan lehet egy nagy projektet úgy szervezni, hogy a sok apró fejlesztés összeálljon, és egy új minőséget hozzon létre (a szoftvert).

Szerintem az igazán vonzó a programozásban az, hogy pillanatok alatt képes sikerélményt nyújtani.

Na igen. Ettől más, mint a matematika... :)

Engem az üzleti 'probléma' izgat, mikor nekikezdek a feladatnak. Ha a problémák rész feladatokra bonthatók, elsőként a részfeladatokat oldom meg, figyelembe véve az egész feladatot, utána foglalkozok a megoldások összehangolásával. Gusztávnak küldtem egy hivatkozást a projektemre, amiről említést is tett a honlap ajánlójában "Java EE programozási receptek" című bejegyzésnél. Ebben láttam a fenti beszélgetés lényegét megvalósulni, vagyis az architect tevékenységet és az üzleti szabályok fejlesztését együtt.

Hogy végeztem a fejlesztő munkát?

Először az átfogó üzleti feladatot elemeztem, diagrammokat rajzoltam, fejben lejátszottam a lehetőségeket, megrajzoltam a működési mechanizmust, és eljutottam egy általános megoldásig, a feladat magassabb absztrakciójáig. A következő lépésben a kiszemelt technológiára koncentráltam. Pilot programokat kezdtem írni, majd ezek eredményeit gyúrtam egybe. Az üzleti logika és a technológia megismerése együtt jelentette a motivációt. Mégsem tudtam befejezni, mert a megrendelőt nem győzte meg a fa törzse, már magát a fás ligetet szerette volna látni. Nyilván a nagy multik mellett mint kis bolha kis ugrásokat tehetek. Kis ugrásokkal értem el addig, hogy keresett munkaerő vagyok a piacon. Már ezt abból tapasztalom, hogy megbecsülik az összegyűjtött tudást kis vállalatoknál, ahol nincs még meg a nagy vállalatoknál összegyűjtött tudás. De ez nem elégít ki mégsem. Valóban a technológia megismerése nagyobb erővel motivál, mint az üzleti 'probléma', mégis a kettő együtt segít a megoldás keresésben.

Mi okból érzem magam jól a programozói/informatikus bőrömben?

A közösség sokat segít, vagyis a közösségben megélt, vagy megélni vélt érzések tartanak a pályámon. És a gondolat, hogy magam is irányítom a szűkebb/tágabb közösségemet, tudva-tudatlanul. Ez a jelen és a jövőkép alakítási élmény a 'siker' élmény.