Milyen vezetők a milliárdos techmogulok?

Bill Gates, Mark Zuckerberg, Larry Page, Jeff Bezos, Steve Jobs, Elon Musk, Zhang Yiming neve mindenkinek ismerős. Biztosan mindenki társítana hozzájuk rögtön cégnevet, projektet, küldetést, akár többet is. Milyen hard- és soft skill birtokában vannak a milliárdos techmogulok? Mi a szakterületük, azon belül mivel foglalkoznak? Milyen vezetők? Hogyan lehet velük kooperálni? Honnan származik igen erős küldetéstudatuk? Munkájukon kívül mivel foglalkoznak még? Vannak-e közöttük közös pontok, tulajdonságok, konfliktusok? Mitől sikeresek, eredményesek?

A Forbes üzleti magazin évről-évre megjelenteti a leggazdagabb emberek listáját. Közülük számos üzletember számítástechnikával, IT technológiával, szoftverfejlesztéssel, informati­kával foglalkozott/foglalkozik. Közülük válogattam ebben a blog bejegyzésben:

Mindhárom elemzett nagy vezető általában „nehéz ember”. A szakterületükön belül kiválóak, értenek ahhoz, mit csinálnak. Ez sokszor technológiai hard skilleket jelent. A vezetéshez viszont sok-sok soft skill is szükséges. Gyakran autokratikus stílust képviselnek, azaz tekintélyi, hatalmi eszközökkel, céltudatosan, fenyegetéssel érik el nagy céljaikat, amik erősen motiválják, vezérlik őket. A beosztottakra többnyire úgy gondolnak, mint kizsákmá­nyolható lehetőség, akik rendelkeznek a szükséges tapasztalatokkal, amire támaszkodnak a vezetők, de ezen túl a beosztottak emberek is (érzésekkel, gondolatokkal, véleménnyel), ami ezeknek a vezetőknek kevésbé vagy egyáltalán nem számít. Egy-egy projekt koordinálásában azonban mindegyikük kiváló, akár többféle szerepben is. Ez többnyire segít „elviselni őket”, hiszen meggyőző a szakértelmük.


Bill Gates

Bill Gates (1955-) amerikai üzletember, szoftverfejlesztő, feltaláló, filantróp, a világ egyik leggazdagabb embere. Életének mérföldkövei:

Szülei sikeres üzletemberek voltak. Érdeklődési területének meg­felelően a Lakeside középiskolába járt (1968-1973), mert ott kimagasló volt a számítás­tudomány specializáció. Felsőoktatási tanulmányait a Harvardon (1973-1975) matematika szakon kezdte, de 1976-ban halasztott és nem szerzett diplomát.

Gates első vállalkozása a Paul Allennel közösen alapított Traf-O-Data, amely a seattle-i utakon végzett forgalommérés adatait dolgozta fel mikroszámítógép segítségével. Az IT-ban hírnevét elsősorban a grafikus interfész forradalmasítása során végzett tevékenységéért szerezte. A Microsoft vezérigazgatója 1975-től.

A grafikus interfész ötletének eredete a ’60-as évekig nyúlik vissza, de sokáig laboratóriu­mokban, a nagyközönségtől elzártan maradt a koncepció. Az Apple alapító-tulajdonosának, Steve Jobsnak felkeltette az érdeklődését a Xerox PARC kutatólaboratóriumban folyó munka, illetve számítógépük, a Xerox Star, és az Apple elkezdett dolgozni a grafikus interfészen. Az Apple és a Microsoft ebben az időben szoros partneri viszonyban álltak, a Microsoft különféle szoftvereket fejlesztett a konstruktőr számára. A kapcsolatnak köszönhetően Gates tudomást szerzett a megvalósítási fázisba lépett tervről. Ő maga is elkötelezettje volt a grafikus felületnek. Steve Jobs előrelátóan olyan megállapodást kötött a Microsofttal, amelyben ki kellett jelenteniük, hogy 1983 decemberéig nem szállítanak grafikus felhasználói felületet az MS-DOS-hoz. Gates elhatározta, hogy az MS-DOS-hoz is kifejleszt egy grafikus képernyőt, ez lett a későbbi Windows. Amint ez Jobs tudomására jutott, lopással és ipari kémkedéssel vádolta meg Gatest, de akkor még sikerült elsimítani a konfliktust, mivel a Windows még csak ötlet szintjén létezett. 1984. január 23-án bemutatták az Apple Macintosht, amely óriási sikert aratott. A bemutatón Gates is részt vett, és kifejezte szándékát minél több Microsoft alkal­mazás Macintoshra történő adaptálására. A Microsoft következő generációs operációs rend­szere IBM-kompatibilis rendszerekre a grafikus felülettel rendelkező Windows 1.0 lett, amely kereskedelmi forgalomba majdnem két év késéssel, 1985. november 20-án került.

Bill Gates és felesége, Melinda 2000-ben hozta létre a Bill és Melinda Gates alapítványt. Az eleinte számítástechnikai irányultságú tervek (interneten elérhető nyilvános könyvtárak létrehozása) után a házaspár figyelme a szegény gyerekek támogatása és az orvosi célú kutatások felé fordult. Célul tűzték ki a gyermekhalandóság csökkentését, valamint az Egyesült Államokban beindítottak egy lakhatási programot hajléktalan családok számára. 2003-ban Indiában AIDS-ellenes kutatásokat támogatott az alapítvány, illetve malária-ellenes vakcinák kifejlesztésére fordítottak 258 millió dollárt. E két betegség ellen a szervezet ezt követően is kitartóan küzdött. 2006-ban az alapítvány három alappillérre helyezte tevékenységét, melyek a globális egészségügy, a globális fejlődés, illetve az Egyesült Államokban tapasztalható munkanélküliség csökkentése új munkahelyek teremtésével. Az alapítvány projektjei az évek során folyamatosan bővültek a fenntartható mezőgazdasági fejlődés, a természeti katasztró­fák elleni gyors reagálás, az éhínség leküzdése, a gyermekbénulás elleni harc, védőoltások és más hasonló témákkal, mely projektek elsősorban a fejlődő világ országaira fókuszáltak. Bill Gates 2012-ig 28 milliárd dollárt költött jótékonyságra. 2008-ban felhagyott a Microsoft-beli napi munkával, hogy minél több időt tudjon jótékonysági tevékenységére fordítani.

Bill Gates 2005. március 2-án lovagi címet kapott II. Erzsébet brit királynőtől, elsősorban jótékonysági tevékenységének elismeréseként. Világszerte hírnévre tett szert.

Bill Gates legfontosabb vezetői tulajdonságai voltak

  • Céltudatos
    Gates kezdettől fogva arra fókuszált, amihez a legjobban – és mindenki másnál jobban – értett: a szoftverre. Ezt kemény munkával a lehető legmagasabb szintre tökéletesítette. Évtizedeken át képes volt kitartóan követni célját, bármilyen akadályok kerültek útjába. Céltudatossága megmutatkozik jótékonysági tevékenységében is.
  • Elkötelezett
    Az volt az álma, hogy minden háztartásban legyen számítógép. Ezt a célt gyakorlatias módon, lépésenként haladva kívánta megvalósítani. Vezetői gyakorlatában azt az elvet követte, hogy „Ahelyett, hogy megpróbálnánk egyből a csúcsra jutni, egyszerre csak egy lépést teszünk”.
  • A változásokból előnyt kovácsolt
    „Az egyetlen biztos dolog a változás, és minél jobban tudunk alkalmazkodni hozzá, annál sikeresebbek lehetünk.” Bill Gates tisztában volt azzal, hogy az üzleti életben mindig vannak fluktuációk és változások, amelyekhez a siker elérése érdekében alkalmazkodni kell. Ezzel a hozzáállással egy olyan vállalatot hozott létre, amely túlélte a nehézségeket, válságokat, és sikerrel jött ki belőlük.
  • Szenvedélyes, mindent beleadva dolgozott
    Gates hitt abban, hogy „Ha valamit érdemes csinálni, akkor azt érdemes a lehető legjobban csinálni”. Óriási lelkesedéssel és szeretettel csinált mindent. Gates szerint rendkívül fontos, hogy mindent, amit az ember elvállal, a tőle telhető legnagyobb odaadással végezze.
  • Önképző
    Annak ellenére, hogy abbahagyta a felsőoktatást és tisztában volt a formális oktatás korlátaival, Gates számára a tanulás egy élethosszig tartó folyamatot jelent, és vezetőként is ezt a meggyőződést adta át az embereinek. Folyamatosan tanult, képezte magát, fejlesztette a kommunikációs és társas készségeit, tanulta a nyilvános beszéd fortélyait. Emellett rengeteget írt és olvasott. Többet, mint amennyit legtöbbünk valaha is fog egész életében. A tudás – ahogy Gates vallja – korlátlan, az emberben pedig bölcsességet és alázatot kell, hogy eredményezzen felsőbbrendűség helyett.
  • Jótékonykodó
    Bill Gates a világ egyik leggazdagabb embere, azt is elmondhatjuk róla, hogy ő az egyik azok közül, akik jótékonysági munkájuk által a legtöbbet adják vissza az emberiségnek, lásd fenn: Bill és Melinda Gates Alapítvány.
  • Jövőkép-orientált
    A Microsoft azért tudta legyőzni versenytársait, mert Gates mindig, folyamatosan egyre nagyobb és nagyobb jövőképet vizionált.

Bill Gates ismert gyenge pontjai voltak vezetőként

  • Konfliktuskerülő
    Gates nem szeretett konfrontálódni. Gyakran amennyire csak lehetett, kerülte a konfliktusokat, mert kényelmetlenül érezte magát ezekben a helyzetekben.
  • Arrogáns
    Amikor valaki mélyreható tudással rendelkezik egy témában, amit szenvedéllyel kutat, könnyen átcsúszhat a túlzott magabiztosságból az arroganciába. Gates önérvényesítő volt, nyíltan kinyilvánította az általa helyesnek vélt elképzeléseket, ötleteket. Ha úgy érezte, hogy az ő ötlete a legjobb, akkor elvárta, hogy azt kövessék. Amennyiben kiderült, hogy az adott elképzelés mégsem működik, Gates könnyen arrogánssá vált, amivel megnehezítette mások munkáját.

Steve Jobs

Steve Jobs (1955-2011) amerikai feltaláló és üzletember volt. Az Apple multinacionális IT vállalat társalapítója, egykori elnök-vezérigazgatója. Jobs irányítása alatt fejlesztette ki a cég egyik fő termékét, a kultikus Macintosh számítógépet, valamint az iPod médialejátszót, az iPhone okostelefont és az iPad táblagépet. Életének mérföldkövei:

A fiatal Steve Jobsra nagy hatással volt apja ezermester-tudása és tökéletességre való törek­vése. Jobs az iskolai éveket unalmasnak találta, később pedig beilleszkedési zavarai voltak. Több csínytevése volt, de örökbefogadó szülei laza fegyelemmel nevelték. A Life magazin egyik éhező gyerekeket mutató címlapjának hatására megingott a bizalma a keresztény vallásban. Jobs a Homestead középiskolában tanult, ahol kiemelten foglalkozott elektronikával. Kipró­bálta a marihuánát és az LSD-t is. Különc volt megjelenési és étkezési szokásait illetően. Egy elektronikai témájú órán ismerkedett meg az öt évvel idősebb, zseniális Steve Wozniakkal. Habár a szintén némileg aszociális Wozniak jelleme különbözött Jobsétól, mégis összebarát­koztak. Később együtt alapították meg az Apple vállalatot.

Vegyük sorra legfontosabb találmányait, amelyek elkészültében többféle szerepet is betöltött (technológiai innovátor, tervező, termékmenedzser, folyamatmenedzser, értékesítő):

  • Apple I., 1975: korának megfelelően „teljesen összeszerelt” számítógép volt, de tápegységgel, monitorral, burkolattal, de még billentyűzettel se rendelkezett, csak a készre szerelt alaplap volt meg a szükséges csatlakozóhelyekkel.
  • Apple II., 1977: az egyik első rendkívül sikeres, tömeggyártású mikroszámítógép, kapcsolóüzemű tápegységgel, értékesítése fogyasztói piacra irányult: az amerikai háztartásokat célozta meg.
  • Macintosh 128k (1984): az első üzleti sikert hozó számítógép a Classis Max OS grafikus felhasználói felülettel rendelkező operációs rendszerrel.
  • Apple-boltok (2001-től): exkluzív üzlethálózat az Apple termékek kizárólagos értékesítésére szánva.
  • iPod (2001): az első hordozható mp3 lejátszó.
  • iTunes-bolt (2004): legális digitális zeneletöltési lehetőség, online platform.
  • iPhone (2005): az első saját, zárt platformos okostelefon és egyben fejlesztői platform és online alkalmazásbolt.
  • iPad (2010): az első óriási táblagép, ezzel az Apple mindenhol jelen van, ahol csak lehet az elektronikai piacon.

Egy lopás története: Steve Jobsszal kapcsolatban az egyik legtöbbet emlegetett kritika, hogy ellopta a Xerox PARC által kifejlesztett grafikus felhasználói felület (GUI) és az egér ötletét, megfosztva a feltalálót a jogos sikerétől. A valóság azonban ennél árnyaltabb. Habár Jobs a Xerox PARC által fejlesztett találmányt felhasználta, sőt a „lopás tényét” is elismerte, jóval többet tett egy technika átvételénél. A Xerox PARC által készített rendszer nem csak nagyon drága, de működése is kényelmetlen és kidolgozatlan volt. Jobs a Xerox PARC egeret nem csak továbbfejlesztette, hanem az árát 300 dollárról mindössze 15 dollárra csökkentette. A grafikus kezelőfelület pedig jóval kifinomultabb és felhasználóbarátabb lett, mint az eredeti. Habár nem közismert, de a Xerox PARC 1981-ben – jóval Steve Jobs előtt – bemutatta a maga modelljét Xerox Star néven. Azonban a forradalmi gép üzleti bukás volt és mindössze 30 ezer darabot tudtak értékesíteni. Jobs így lényegében egy olyan technológiát „lopott el”, amit feltalálója nem tudott sikeresen hasznosítani. Ez az eset jó példája Jobs munkásságának, amikor mások számára sikertelen vagy kevésbé sikeres technológiát gondol újra és áttervezve sikerre viszi azt.

Steve Jobs legfontosabb vezetői tulajdonságai

  • Nem szívesen delegált.
  • Jobs tudta, hogy a kreativitás csak „összekapcsolja a dolgokat”.
  • Megtalálta az egyensúlyt a munkatársai felhatalmazása és a példamutatás között.
  • Távol tartotta a kreatív munkatársait a kritikusoktól.
  • Az innováció néha a kivonásról szól. „Hagyjuk el a nem szükséges dolgokat, funkciókat, nyessük le a vadhajtásokat.”
  • Rendíthetetlenül szenvedélyes volt cégei iránt.
  • Nem félt másként gondolkodni.
  • „Sokkal többre van szükséged, mint a vízióra – makacsságra, szívósságra, hitre és türelemre van szükséged ahhoz, hogy megtartsd az irányt” – mondta Edwin Catmull, a Pixar társalapítója. „Steve esetében egészen a határig nyomul, hogy megpróbálja megtenni a következő nagy lépést előre.”
  • „A nagyszerű dolgokat az üzleti életben soha nem egy ember csinálja, hanem egy csapat ember.”
  • Hatékony prezentációs technikát fejlesztett ki.

Elon Musk

Elon Musk (1971-) dél-afrikai származású amerikai mérnök, vállalkozó és multimilliárdos újító, a világ egyik leggazdagabb embere. Nevéhez fűződnek a következő cégek/projektek: Zip2, X.com, PayPal, SpaceX, Tesla Inc., SolarCity, The Boring Company, Neuralink, Starlink, Hyperloop. Napjaink egyik géniusza, megszállott zseni, magával ragadó jövőképpel és tömény ambícióval. Életének mérföldkövei:

12 évesen játékprogramot írt, amivel 500 dollárt keresett. 17 évesen Amerikába szeretett volna emigrálni, de csak Kanadában kapta meg az állampolgárságot. Fizikát és közgazdaság­tant tanult, szerzett is 2 diplomát, majd az USA-ba költözött. 1995-ben meg alapította az öccsével a Zip2 vállalatot, majd ezt el is adták 1999-ben 345 millió dollárért a Compaqnak. Musk vállalatai az elektronika köré csoportosítható technológiákkal foglalkoznak, ő maga pedig az elektromos járműveinek (Tesla típusok), akkumulátorainak és napenergiás termékei­nek terméktervezési, mérnöki és globális gyártási munkálatait látja el. Űrkutatással foglalkozó vállalata kifejlesztette a Dragon űrhajót és a Falcon hordozórakétát, amelyek képesek a Nem­zetközi Űrállomás ellátására, innovatív, nagy arányban újrahasznosítható/visszatérő modulok­ból állnak.

Elon Musk vezetői tulajdonságai

  • Megszállott
    A munkája a lételeme. Hajthatatlan. Minden ébren töltött órájában formálja, finomítja és megvalósítja elképzeléseit. Szenvedélyesen merül bele a munka legapróbb részleteibe is. Napjainkra elért sikerének kulcsa, hogy heti kb. 100 órát dolgozik. Extrém magas elvárásokat támaszt önmaga és a cég emberei felé is, és hidegvérrel kirúgja azokat, akik nem képesek megugrani ezeket. Nagyon személyes kapcsolat fűzi találmányaihoz és vállalkozásaihoz. Ez a szenvedély és szeretet pedig ragályos: bizalmat, tiszteletet, sőt odaadást, imádatot vált ki másokból. Hosszú távú és másokat is magával ragadó jövőképpel rendelkezik. Rendkívüli ambícióval és kitartással valósítja meg mindazokat a dolgokat, amiket mindenki más lehetetlennek tart. Musk jövőképe, a sikerei mögött rejlő hajtóerő: az emberiség jobb jövője. Egy olyan világ, amely a fosszilis energiahordozók helyett környezetbarát energiaforrásokkal működik. Egy olyan világ, amely elektromos autókat használ, amely meghódítja az űrt és kolóniákat épít a Marson. Ezenfelül Musk azáltal, hogy megosztja grandiózus jövőképét és céljait a munkavállalókkal, képes magához vonzani a világ legtehetségesebb, legjobb szakembereit. Még olyankor is, amikor más vállalatok jelentősen nagyobb fizetéseket vagy kedvezőbb feltételeket ígérnek nekik. Az egyik tehetséges szakembere így nyilatkozott erről: „Amikor döntenem kellett, hogy Musknak akarok-e dolgozni vagy egy másik cégnél, ahol többet fizetnek, eldobtam minden logikát és óvatosságot, és a kreatív géniusz mellett döntöttem.”
  • Csapatban gondolkodik
    Musk folyamatosan nyeri el követőinek bizalmát még a bizonytalan helyzetekben is azáltal, hogy kiszámítható, megbízható és átlátható. Ezért tartanak ki mellette a befektetői és támogatói még a gazdaságilag instabil időszakokban is. Musk rendkívüli mértékben tudja inspirálni az embereit. Kulcsfontosságú számára, hogy a legjobb embereket a számukra legmegfelelőbb munkakörökben alkalmazza. Majd ezt követően magas követelményeket támasszon feléjük és – amennyiben teljesítik ezeket – tisztességes javadalmazásban részesítse őket. Ugyanakkor igen gyorsan kirúgja azokat, akik nem végzik munkájukat kellő szenvedéllyel és lelkesedéssel.
  • Rendíthetetlenül optimista
    Musk ötleteit sokan kételyekkel fogadják. Őt azonban semmilyen módon nem befolyásolja mások szkepticizmusa, és nem törődik azzal, ha mások nem hisznek benne. Folyamatosan kiáll azért, amiben hisz. A kritikát, ellenvéleményeket azonnal lereagálja, és konkrét tényekkel érvelve támasztja alá meggyőződéseit. Musk számára a kudarc a kreatív, alkotó folyamat természetes velejárója. Nagyra értékeli a visszajelzéseket. Folyamatosan arra törekszik, hogy egyre jobban teljesítsen, mert tudja, hogy csak így juthat el céljai megvalósításához. Musk a kudarcok ellenére is mindig megtartja rendíthetetlen optimizmusát, és teljes bizonyossággal tudja, hogy sikert fog elérni.
  • Az állandó tanulásra, fejlődésre fókuszál egyéni és vállalati szinten egyaránt
    Muskot a folyamatos kíváncsiság, tudásszomj és tanulási vágy jellemzi. Az összes vállalkozásának minden részletét alaposan kitanulta. Hibáiból, kudarcaiból és sikereiből egyaránt gyorsan tanul. Minden új információra nyitott, és nem fél a változtatástól, amikor új információk segítségével ismeretlen szituációkhoz kell alkalmazkodnia. Dolgozóit is arra biztatja, hogy merjenek elrugaszkodni a megszokottól, a hagyományos módszerektől, és legyenek kreatívak, innovatívak. „Igen, lehet, hogy hibázni fog az ember. Ha sosem hibázik, az azt jelenti, hogy nem eléggé újító.”
  • Nagyra értékeli önmagát
    Musk a gyengeségei helyett az erősségeire fókuszál, és ezeket nem rejti véka alá. Nem szerénykedik képességeivel, tudásával, sőt, nyíltan vállalja azokat.
  • Nyers stílusban kommunikál
    Muskot agresszív, követelőző magatartás jellemzi. Makacs és rugalmatlan. Nyers, durva stílusban kommunikál és konfrontálódik. Egocentrikus, és ez a mindennapos kommunikációjában is jelen van. Hiányoznak az érzelmi intelligenciához szükséges bizonyos képességei. Nem képes az empátiára, és nem tudja felismerni mások érzéseit. Számára egyébként sem fontos a dolgozók lelkivilága, vagy az, hogy az emberei hogyan érzik magukat a cégnél. A termelékenység és a hatékonyság élvez prioritást a humán tényezőkkel szemben.

Források

A TIOBE Java kódolási szabályokról

A TIOBE Java Coding Standard aktuális verziója a 3.10. Java programozási nyelven írt/karbantartott forráskódra vonatkozó szabályokat/ajánlásokat tartalmaz. Célja: a kódolási hibák elkerülése, az elavult vagy implementációfüggő nyelvi funkciók használatának elkerülése, illetve a következetes, konzisztens kódolási stílus kialakítása.

A TIOBE Java Coding Standard dokumentáció szerkezete

A TIOBE Java kódolási szabályok 19 kategóriába soroltak, 1-8-ig szint alapján csoportosítottak, továbbá ellenőrzött és nem ellenőrzött állapotban vannak. Az alábbi Sankey-diagram segít áttekinteni a dokumentációt:

A TIOBE Java kódolási szabályok kategóriánként

A továbbiakban néhány kategóriából emeltem ki néhány szabályt/ajánlást – amiket fontosabbnak tartok.

  • 34 db alapszabály van. Ezek olyan jó gyakorlatok, amiket mindenkinek követnie kell. Nem írunk üres if, switchutasításokat. Nem írunk üres while, try, finally, synchronized, static blokkokat. Nem írunk tesztelős ciklust számlálósként, így: for (;true;). Nem módosítjuk a for ciklus változóját a ciklusmagban. Ne használjunk felesleges public, static, finalmódosítókat és (eljárásokban) return utasítást.
  • 8 db kódmérethez kötődő szabály van. Ne írjunk hosszú, sok utasításból álló metódusokat. Ne használjunk túl sok paramétert metódusok, konstruktorok esetén. Ügyeljünk a forráskód ciklomatikus komplexitására, amely a tesztelési nehézségek egyik mutatószáma. Ne tervezzünk túl sok publikus metódust és mezőt/tulajdonságot egy osztályba. A limitek a fentiek sorrendjében: 100 utasítás, 10 paraméter, 1000 kódsor, 10-es komplexitású metódus, 45 metódus, 15 mező/tulajdonság.
  • 4 db kommentekre vonatkozó szabály van. Ezek forrásfájlokra, annotációkra, TODO-kra és speciális JavaDoc-ra érvényesek.
  • 4 db ellentmondásos/vitatott szabály van. Például ne importáljunk a sun.* csomagokat, illetve ne használjunk felesleges kerek zárójelpárokat, értékadással egybeépített összehasonlítást egy feltételben.
  • 42 db tervezési szabály van. Függvényben lévő if-then-else utasításben lévő két return helyett adjuk vissza közvetlenül a logikai kifejezés értékét. Logikai kifejezésekben ne legyenek felesleges összehasonlítások. A switch utasításban hiányzó break utasítás tervezési hibára utal (bár nem szintaktikai követelmény, hogy legyen). A switch utasításban kellene default ágnak lennie (és egyben álljon az utolsó helyen). Ne definiáljuk felül egy metódus bejövő paraméterét. Az equals() összehasonlító metódust ne hívjuk meg null paraméterrel. Ne használjunk idempotens műveleteket, például ne adjunk értékül egy változót/objektumot saját magának. A SimpleDateFormat osztály és String.toLowerCase()/toUpperCase() metódusok használata során mindig állítsuk be a Locale objektumot. A synchronized kulcsszót ne kívülről, metódusra, hanem belülről, blokkban használjuk. Konstanst ne inicializáljunk null-ként. Kollekciók esetén a size()==0 vagy size()!=0 helyett hívjuk meg az isEmpty() függvényt. Az instanceof operátor használata előtt nem kell ellenőrizni, hogy az objektum nem null. A megnyitott erőforrásokat mindig zárjuk le a close() metódussal.
  • 7 db véglegesítéshez kötődő szabály van. Ha írunk finalize() metódust, akkor az ne legyen üres és ne legyen paramétere sem. Inkább ne írjunk finalize() metódust, mert nincs garancia arra, hogy végrehajtódik (illetve szintén nem tudjuk, hogy mikor fut le).
  • 5 db importáláshoz kapcsolódó szabály van. Importáljunk pontosan. Ne importáljunk a java.lang csomagból (mert ez alapértelmezett). Ne importáljunk többszörösen. Ne maradjanak nem használt importok a végleges forráskódban.
  • 4 db logolásra vonatkozó szabály van. Egy osztályban egyetlen Logger legyen. A System.(out|err).print() metódus és kivételkezelés során printStackTrace() helyett inkább logoljunk.
  • 1 db szabály van a többszálúsághoz kötődően. Példányváltozó közvetlenül elérhető több szál számára. Az ehhez való megosztott hozzáférés szabályozása, szinkronizálása nehéz, ezért inkább hozzunk létre belőle annyi példányt, ahány szálon fut a program.
  • 10 db elnevezésre vonatkozó szabály van. Kerüljük a hosszú változóneveket és a rövid metódusneveket. Ne használjunk $ jelet a változók, metódusok, osztályok, interfészek elnevezése során. Ne használjunk a Foo osztályban Foo() metódusnevet (mert ez a konstruktor), és foo változónevet sem. Minden osztály és interfész tartozzon csomagba.
  • 8 db optimizáláshoz kötődő szabály van. Ha egy változó nem módosul és csak egyszer kap értéket, akkor legyen konstans. Ha tömbből generikus listát készítünk, akkor használjuk az Arrays.asList() metódust (ahelyett, hogy ciklust írunk az adatszerkezet konstrukciójához). Csomagolóosztályt csak szükség esetén alkalmazzunk (mert autoboxing van). A Calendar helyett használjunk inkább „olcsóbb” osztályokat.
  • 2 db kódbiztonsági szabály van. Ne égessünk a forráskódba kriptográfiához kötődő adatokat (kód, jelszó, hash). Ezeket a kulcsokat külső fájlokban tároljuk.
  • 11 db szabály vonatkozik a kötelező kivételkezelésre. Nem szabad catch (Throwable t) ágat használni, mert memóriaproblémát okozhat. Konstruktor/metódus ne dobjon általános kivételt ( Exception) – helyette dobjon szükség esetén speciálisabb/leszármazott kivételt. Ne kapjunk el általános kivételt; specializáljuk ezt is. Kivételkezeléssel ne valósítsunk meg vezérlést. Ne kapjunk el NullPointerException-t; inkább szüntessük meg a keletkezésének okát. Ha lehet, akkor a try-catch-finally blokk helyett alkalmazzunk erőforrás-kezelő kivételkezelést.
  • 14 db szabály vonatkozik a szövegkezelő String és StringBuffer osztályok használatára. Közvetlenül inicializáljuk a String típusú objektumokat, felesleges hozzá konstruktort használni. Csak akkor használjuk a toString() metódust, amikor feltételül szükséges. Összehasonlításnál az equalsIgnoreCase() metódus gyorsabb a toUpperCase/toLowerCase().equals() metódusoknál. Láncoljuk az append() függvényeket, amikor csak lehet. Ha nem szükséges, akkor ne használjuk a String.valueOf() függvényt. String objektumok összehasonlítát az equals() metódussal végezzük el.
  • 3 db típusrezolúciós szabály van. Használjunk ArrayList list=new ArrayList() helyett List list=new ArrayList() deklarációt (értékadás bal oldalán statikus típus (interfész), jobb oldalán dinamikus típus (implementáció)). Tömb létrehozásához használjunk int[] x=new int[] {1, 2, 3} helyett int[] x={1, 2, 3} inicializáló blokkot. Generikus lista létrehozásánál használjunk List<String> strings=new ArrayList<String>() dupla gyémánt operátor helyett csak egyet, így: List<String> strings=new ArrayList<>().
  • 5 db nem használt forráskódokra vonatkozó szabály van. Ezek privát változókra, lokális változókra, privát metódusokra, felesleges értékadásokra, üres utasításokra érvényesek.

Nem tértem ki a 2 db klónozáshoz, 2 db csatoláshoz (importáláshoz), az 1 db stílushoz kötődő szabályra. Továbbá van 5 db már elavult, tervezésre vonatkozó szabály.

A fentieket érdemes megfogadni, betartani, céges környezetben megfelelően kiegészíteni, testre szabni. A teljes angol nyelvű dokumentáció elérhető: Coding Standard Viewer. A weboldalon érdemes a Java programozási nyelvre vonatkozó szabályokat, ajánlásokat összehasonlítani más nyelvekre vonatkozó szabályokkal, ajánlásokkal. Összesen 8 programozási nyelvhez találhatók szabályok, ajánlások. Elérhetők a forráskód minőségét, karbantarthatóságát kifejező TQI szempontok, paraméterek dokumentációi is: TIOBE Quality Indicator (TQI), valamint a TIOBE TÜViT Trusted Product Maintainability ISO/IEC 25010 Quality Model. Egy szint felett már ezeket is figyelembe kell venni.

Korábbi blog bejegyzésünk a fenti saját készítésű ábra, grafikon elkészítéséről: Sankey-diagram készítése. Érdemes a hozzászólásokat is tanulmányozni a jó példákért.

Murphy törvénykönyve – görbe tükör IT szemmel

Arthur Bloch népszerű könyvéből gyűjtögettem néhány szösszenetet. Biztosan sokaknak ismerős. A címe: Murphy törvénykönyve, avagy miért romlik el minden? A gondolatokat itt-ott kiegészítettem a programozásra, szoftverfejlesztésre jellemző szemléletmóddal. Ezt a blog bejegyzést április 1-jén tesszük közzé. Nem véletlenül. 🙂 Az alap Murphy-törvényből induljunk ki: „Ami el tud romlani, az el is romlik.” Következzen 13+1 bölcsesség.

„Semmi sem olyan egyszerű, mint amilyennek látszik.” Pláne, ha az ügyfél úgy gondolja, hogy ezt az apróságot bizony 4 perc alatt megoldja egy ügyes fejlesztő.

„Minden több időt vesz igénybe, mint gondolnád.” Ha csak egy paraméter típusát változtatod meg egy metódusban, akkor az biztos, hogy lavinát indít és a forráskódban sok helyen kell módosítanod.

„Ha többféle dolog is elromolhat, biztos, hogy az romlik el közülük, amelyik a legnagyobb kárt okozza.” Elegendő belegondolni abba, hogy egy WordPress-ben lehet bármennyi bővítményed, amik általában gond nélkül frissülnek, de egy apró PHP frissítéstől összedől az egész weboldal.

„Ha rájöttél, hogy egy művelet négyféle módon mondhat csődöt, s mindegyiket kivéded, menten fellép az ötödik.” Hiába készülsz fel minden input adatra, billentyűzet- és egéreseményből adódó problémára. Egy webes űrlap esetén, egy macska mindig átfuthat a billentyűzeten. Teljesen váratlanul.

„Semmit sem lehet a kétbalkezesek ellen bebiztosítani, mert a kétbalkezesek rendkívül találékonyak.” Egy tesztelő mindig tud olyan tesztesetet produkálni, amire senki sem gondolt korábban a tervezésnél, megvalósításnál, dokumentálásnál. Bár egy kicsit sántít ez a gondolat, mert egy tesztelő messze nem kétbalkezes, hanem tudatosan csinálja, amit csinál. Legalábbis remélem.

„Ha javulni látod a dolgokat, akkor valami fölött elsiklottál.” Amikor azt érzed, hogy ez a sprint végre most elkészül határidőre, akkor az utolsó napon, órában, percben tutira borul valami.

„Ha egyszer összekutyulódott valami, a kijavítására tett minden kísérlet csak rontani fog rajta.” Pláne, hogy mindenhol, még a jól megtervezett osztálykönyvtárakban is van legalább egy leggyengébb láncszem.

„Amit ember összerakott, előbb-utóbb szétesik.” Amikor azt gondoljuk, hogy egy jó dátumkezelő funkciót kiválóan megterveztünk, rommá teszteltünk, akkor bezzeg nem 3,9 év múlva jön egy szökőév…

„Egy esemény előfordulásának valószínűsége fordítottan arányos bekövetkezésének kívánatosságával.” Azt kár feltételezni, hogy a jogszabályok, végrehajtási rendeletek ritkán változnak. Pedig gyakran építünk sok-sok funkciót ezekre építve szinte bármilyen szoftverben, webáruházban.

„Nyomás alatt a dolgok tovább rosszabbodnak.” Pedig kipróbáltuk az legkritikusabb adatbázis táblát 1000 db tesztadattal, de arra nem számítottunk, hogy élesben napi 500 rekord kerül bele és ugye előbb-utóbb eljön a havi zárás annyi adattal, amire nem készültünk fel. Ugyanilyen, ha nem skálázható webtárhelyen futó WordPress-re irányítunk intenzív marketingkampánnyal sok-sok látogatót és akkor egyszer csak összeomlik a weboldal a váratlan nagy terhelés alatt.

„Ha n számú alkatrészre van szükség, éppen n-1 van raktáron.” Ez – főleg – akkor (is) igaz, ha egy SCRUM csapatban az alkatrészt kollégának tekintjük. Még szűkebb keresztmetszet, hogy legyen releváns tapasztalata is az aktuális problémához és éppen érjen is rá. És persze ne holnap menjen el a konkurenciához/külföldre dolgozni f+1 fizetésért és ne holnapután üsse el a villamos.

„Legjobban azzal ébreszthetsz magadban új gondolatokat, ha leragasztasz egy levelet.” Korszerűsítve és adaptálva a gondolatot: miután lenyomtad a Deploy gombot egy webalkalmazás aktuális változatának publikálásához, akkor biztosan eszedbe jut, hogy mit kellett volna még beletervezni, fejleszteni a szoftver aktuális verziójába. Nem baj, hamarosan kiadjuk majd a következő frissítést is.

Eddig volt 13 bölcsesség. Azzal akartam zárni, hogy a +1-edik bölcsesség elromlott, hiszen biztosan erre is érvényes a Murphy-törvény, de inkább írok még egyet. Még jó, hogy „Murphy optimista volt”. 🙂 Ez a szerencsénk. Mi lenne velünk, ha pesszimista lett volna? 🙂

Balogh Péter emlékére

Mély megrendüléssel tudatjuk, hogy oktatói csapatunk egyik tagja, Balogh Péter elhunyt.

Ismeretségünk az ELTE MSc informatikatanár szakán kezdődött, ahová egy évfolyamra jártunk és 2005-ben végeztünk. Az egyetemi időszak alatt az általunk Kockakörnek hívott 6-8 fős csapat tagjaként mindannyian aktívan támogattuk egymást. Akkoriban ő Kecskeméten lakott én pedig Cegléden, így évekig vonatoztunk többen is együtt a csoportból a fővárosba – a MÁV Szeged-Budapest vonalán – és küzdöttünk az ELTE-s diplomáért. Sokat ötleteltünk, építő jellegű kritikával segítettünk egymást a szakdolgozatírásban, kölcsönösen számíthattunk egymásra.

Magunk között az ELTE-s zh-kat csak IQ-tesztnek hívtuk, hiszen általában mindig olyan feladatokkal találkoztunk, amikre bármennyit készültünk is, elsőre minden alkalommal ismeretlennek és megoldhatatlannak látszottak. Belemélyedve a papíros és kódolós feladatokba, már korántsem bizonyultak annyira elvontnak és persze megugrottuk az akadályokat.

Az egyetem után – változó intenzitással, de – többen is együttműködünk a Kockakörből. Online gyakrabban, de offline is találkozunk néhány alkalommal évente. Mindannyian fejlesztünk és tanítunk is. Változatos, hogy ki milyen területtel foglalkozik éppen, de a programozás, mintapéldák, módszertani kérdések, érdekes szakmai problémák időről-időre felbukkannak. Körkihívásokat is szoktunk csinálni. Aggteleken 2-3 évente nyáron néhány napot azóta is eltöltünk.

Péter szakmai kíváncsisággal fogadta, amikor összeállítottam 2009-ben a Programozási alapok és 2010-ben a Programozási technológia tankönyveimhez tartozó Java példatárakat. Sok ötletet kaptam tőle, több evolúciós feladat kidolgozásában is segített. Szakmai publikációimat mindig véleményezte. Ha adódott lehetőség, akkor még az előkészítés fázisában, vagy ha ez éppen nem úgy alakult, akkor utólag mindig értékelt, reagált, javasolt. 2012-2014-ig több pályázaton dolgoztunk együtt, főként tananyagfejlesztéshez kötődően. 2014-2018-ig több webes alkalmazás fejlesztésében, karbantartásában, továbbfejlesztésében közreműködtünk: terveztünk, elemeztünk, implementáltunk. Több szakmai továbbképzésen is részt vettünk közösen.

Az it-tanfolyam.hu projekthez Péter 2018 tavaszán csatlakozott. Több vidéki és külföldi csoportunknak tartott Java SE és EE szoftverfejlesztő tanfolyamokat és speciális Java tematikával több, egyedi céges tréninget is. Lelkesen blogolt is velünk, már évek óta. Amikor bemutatkozó szöveget kértem tőle az Oktatók lapjára, ezt írta: „Saját bevallása szerint munkamániás, illetve kommunikációs készsége jóval az átlag IT kocka szintje felett van és ennek minden előnyére igyekszik építeni. Szoftvertervezést és programozást tanít magyar, angol és német nyelven is. Szakmai kihívásként tekint az oktatásra.” Mottót is kértem tőle: „Nem kell mindig tökéletesnek lenni. De ha itt az ideje, akkor tökéletesnek kell lenni.”

2020. márciusában összeültünk ünnepelni – a szokásos KFC-s vödör csirkével – néhány nappal a 38. születésnapja után, amikor így fogalmazott: „Nem lesz több születésnapi csirkém. Komoly baj van. Ezen a világon néhány hónapom van hátra. This is already the end of the road, nothing can be done.” Szokása volt, hogy privát beszélgetések közben egy-egy gondolatmenetének lezáró mondatát angolul, németül, franciául vagy oroszul mondta. Többé ezt nem hoztuk szóba, mert így kérte. Aktívan dolgozott tovább velünk, mert így akarta. Tegnapelőtt küldte utolsó előadásának vázlatát a kapcsolódó Java forráskóddal együtt, amit már novemberre készítettünk elő a Kutatók éjszakája rendezvényünkre és mára egyeztettük, hogy megbeszéljük. Tegnap elment.

Péter lelkes sci-fi rajongó volt. Sokszor beszélgettünk kedvenc sorozatairól, karaktereiről. Star Trek, Végtelen határok, A bolygó neve: Föld, Orion űrhajó… Egyszer azt mondta: „Azért nézünk a tizenéves fiaimmal együtt sci-fit, hogy lássanak alternatív világokat, elképzeléseket. Ezzel kizökkenünk a hétköznapokból. Fontos, hogy elgondolkodjanak arról, hogy lehet(ne) másképp is élni, élményeket szerezni, látni, tapasztalni. Létezhet(né)nek más prioritások is.”

A Star Trek Voyager sorozat 5. évad 11. Látens kép című epizódjában a csillaghajó legénységének egyik tagját Janeway kapitány ezekkel a szavakkal búcsúztatja a temetési szertartáson: „We are assembled here today to pay final respects to our honored dead… His intelligence and his charm have made our long journey home seem not quite so long. As he continues on a journey of his own. We will keep him in our hearts and in our memories.”

Ezzel búcsúzom Pétertől.

Szoftverfejlesztő mémek

IT mémek

IT mémekAz IT kockáknak speciális humorérzéke van. Nekünk külön kategóriákba sorolható mémek készülnek és persze magunk is gyártjuk időnként. Az alábbi összeállítást szabadon keresgélve a weben szedtem össze és csoportosítottam a szoftverfejlesztés, programozás ismert szakterületeihez, folyamataihoz kötődően. Nem fordítottam le angolról magyarra a szövegeket. Aki érti, úgyis érti. Aki nem, úgyis továbbgörget. Enjoy!

Alapelemek, ciklusok

Az algoritmusok alapvető építőelemeivel, egyben a strukturált programozás alapfogalmaival illik tisztában lenni. Ismerni kell ezek működését, egymásba ágyazásának lehetőségeit. Szekvencia, szelekció, iteráció. Időnként döntéseket is hozni kell. Néha úgy érezzük, hogy túl korán, néha pedig későn. Érezzünk rá, mikor jó. Sosem árt lezárni egy-egy blokkot és tudni jól egymásba ágyazni amit kell. Azért a metódusokkal csínján kell bánni.

IT mém 1

Tisztázni kell bizonyos dolgokat

Nem érthetünk mindent és persze nem érthetünk mindenhez. A dolgokat különböző szemüvegen át látjuk, hiszen eltérő tapasztalatokkal rendelkezünk. Persze hasznos, ha egy csoportban értjük egymást, vagy legalább egy valaki tisztában van az ügyfél igényével. J Például a webfejlesztés során el kell fogadni, hogy vannak látványos, azonnali élményt nyújtó változtatások (pl.: design), és hosszú távon megtérülő háttérmunkák (pl.: technológiai SEO).

IT mém 2

Tervezni is tudni kell(ene valakinek)

Azért nem árt a precíz, pontos, konkrét feladatspecifikáció. Mindez akár több szinten is megfogalmazva: fokozatosan közeledve az ügyfél bölcsészmondataitól a kockaságig. Hasznos, ha nem csak a határidő motivál. Nyilván a pénz is. 😉 Érdekek mindig ütköznek, de ezt is meg kell tanulni elfogadni/kezelni. Néha csupán az erősebb kutya esete áll fenn, néha a hatáskörig is megy a történet.

IT mém 3

Ne feledjük: mindenki mást gondol

Mivel a különböző kapcsolódó szakterületeken tevékenykedő szakemberek szókincse eltérő, így ezekből gyakori és tipikus félreértések születhetnek. Ha a fejlesztés hosszabb ideig tart, akkor menet közben is változhatnak – és változnak is 😉 – az igények. Célszerű lenne folyamatokban gondolkodni és feltenni némi empátiával azt a kérdést, hogy igazából mit is akar az ügyfél? Vajon milyen problémát szeretne megoldani, milyen folyamatot tenne könnyebbé a fejlesztendő/karbantartandó szoftverrel? Egy bizonyos szint felett az interdiszciplináris megközelítés elengedhetetlen. Visszacsatolás során kiderül(het), hogy az ügyfél hogyan használja a szoftvert. Lehet, hogy teljesen másképpen, mint ahogyan gondolnánk. Örök bölcsesség: a tervezésre fordított idő később mindig többszörösen megtérül.

IT mém 4

IT mém 5

Módszertanok

Előbb-utóbb eljön az a szint, ahol már a különböző módszertanok is megjelennek. Ezekhez is alkalmazkodni kell. Minden fejben kerül helyre. Ezek többnyire a folyamatokhoz, a napi/heti munka szervezéséhez/ütemezéséhez is kapcsolódnak.

IT mém 6

Amikor már végre kódolunk…

Sokféleképpen mérhető/értékelhető egy fejlesztő munkája. Nyilván nem kilóra, például a megírt forráskód sorainak számával. Persze egy komplex szempontrendszernek lehetnek/vannak kvalitatív és kvantitatív mutatói.

IT mém 7

… kiderül, hogy persze semmi sem könnyű

Sosem az számít, hogy milyen hatások érnek bennünket. Az a fontos, hogyan reagálunk ezekre. Semmi sem könnyű, de természetesen erről is különbözőképpen gondolkodunk. Helyén kell tudni kezelni a dolgokat és akkor minden fenntartható hosszú távon. A programozást elkezdeni sosem késő, vagy másképpen: nem lehet túl korán kezdeni? Mindez nézőpont kérdése.

IT mém 8

A tesztelés sem árt…

Legyünk tisztában a tesztelés alapjaival és folyamatával is. Ha lefuttatjuk még egyszer az összes tesztesetet, azzal biztosan nem rontunk el semmit. 😉

IT mém 9

… ahogyan némi dokumentáció sem

Sokan és sokszor nem szeretünk dokumentálni. Bárki bármit mond és tapasztal, a dokumentálás szükséges és hasznos. Ugye senki sem gondolta, hogy ebből a mém gyűjteményből Chuck Norris kimaradhat? 😉

IT mém 10

Többnyire mindez csoportmunkában zajlik

Tisztában kell lennünk a helyünkkel a csoportban: feladatkör, pozíció, felelősség, szerep, kommunikáció. Három fontos kulcsszó: konfliktuskezelés, időmenedzsment, érdekérvényesítés. És persze a hatékony csoportmunkához szükséges soft skillek is előtérbe kerülnek. Kevesek működnek alapból/ösztönösen jól együtt csoportban, a többségnek ezzel tudatosan foglalkoznia kell. Ne éljünk a tipikus csoportmunka hozzáállással: „megcsináltam”, „elrontottuk”. Ezzel megvolt a kötelező cicás kép, már triplán is. 😉

IT mém 11

Tudni kell tanulni is a programozást

A programozási nyelvek csupán eszközei annak, hogy amit kigondoltunk, megterveztünk, modelleztünk, azt megvalósítsuk és működjön asztali gépen, böngészőben, telefonon. Elveket, koncepciókat is meg kell érteni. Kihagyhatatlanok az alapvető algoritmusok, adatszerkezetek. Meg kell ugrani az objektumorientált paradigmát is. A funkcionális paradigma is egyre népszerűbb. Hasznos, ha a tanulás során el tudjuk fogadni a tapasztaltabbak véleményét, javaslatait. Többnyire elsőre nem alkotunk tökéleteset, de minden hibából tanulunk. Tudomásul kell venni: nincsenek átugorható lépcsőfokok. Egyszerűen kell egy kritikus tömegű önálló gyakorlás és utána jön a sikerélmény.

IT mém 12

Ha elszántad magadat és szoftverfejlesztést/programozást tanulnál Java nyelven, akkor jó helyen jársz. A Jelentkezés lapon követheted, mikor indulnak csoportjaink.