Ha ez a bool értéke -3 az azt jelenti, hogy ...

Régi motoros c++ programozók egy részében gyakran meg szokott fogalmazódni az elhatározás, hogy bizony meg kellene tanulni Microsofték csoda-szuper találmányát a c#-ot. Az, hogy most ez mennyiben koppincs, mennyiben saját találmány, más téma. Számos oktatókönyv létezik a témában, de sajnos a legtöbb már ott elveszi a gyakorló szoftverfejlesztő kedvét az egésztől, hogy elkezdi elmagyarázni, mi az osztály és objektum között a különbség és hogyan kell megírni egy ciklust.

Ha egy kitartóbb egyed mégis átlapozza ezeket a részeket, akkor kap cserébe egy gyenge kis ismertetőcskét a Garbage Collector-ról, DataSet-ekről, Event-ekről és Delegate-ekről mindenféle érdekes és új dologról, amikről minden kiderül, csak az nem, hogy ezek valójában miért is annyira csodálatosak.

Miután azonban c++ fejlesztőként elhatároztam magam a nagy váltásra, gondoltam csak megkísérlem újra a lehetetlent és megpróbálok könyvből kiokosodni egy kicsit. Hosszas keresgélés után választásom Bill Wagner könyvére az Effective C#-ra esett. Már a tartalomjegyzék olvasgatásakor tudtam, hogy végre egy olyan könyv, ami tényleg programozóknak készült és nem kezdő középiskolásoknak. Nem magyaráz el semmi olyat, amit már úgyis tud bárki, aki életében írt már egy "Hello World"-nél bonyolultabb programot. Cserében jól érthetően, 50 tippen keresztül elmondja, hogy mik a c# előnyei, milyen tipikus hibákat követnek el a c++ programozók, amikor a régi gondolkodásmóddal próbálnak meg problémákat megoldani és hogy mik azok a minták, amiket ajánlott alkalmazni vagy elkerülni.

Az, hogy a tippeknek mekkora része hordoz valódi újdonságot és mennyi az, amelyik teljesen magától értetődő nyilván egyénenként változik, azonban szerintem még azoknak is érdemes a könyvet referenciaként a polcon tartani, akik már szinte mindent tudnak az ott leírtakból.

Ízelítőül néhány tipp a tartalomjegyzékből:

Item 1 - Always Use Properties Instead of Accessible Data Members.
Item 24 - Prefer Declarative to Imperative Programming
Item 27 - Avoid Icloneable.
Item 38 - Utilize and Support Data Binding.
Item 42 - Utilize Attributes to Simplify Reflection.

A könyv hátányaként két dolgot lehet megemlíteni. Egyik az, hogy aránylag régi, ezért csak a c# 1.0-val foglalkozik, a 2.0-s verziót csak megemlíti, az azutáni változatoknak pedig akkor még híre sem volt, amikor íródott. A másik probléma a magyar kiadásé, egy-két fogalmat sikerült annyira trükkösen lefordítani, hogy bizony erősen kellett gondolkozni, amíg rájöttem, mire is gondolhattak.

...avagy hogyan tegyünk védhetetlenül felelőssé egy felmondott alkalmazottat az aktuális projekt bukásáért.

Első teendő, az adott fejlesztő munkájának rendszeres ellenőrzése. Napi egy-két óra ráfordítással biztosan sikerül találnunk hibát benne (ha mégsem, keressünk olyan kódot, amit szintén ő csinált csak régebben és abba kössünk bele, nem fogja tudni elmagyarázni, hogy miért is tette még akkor sem, ha nincs benne hiba).

Miután ezzel megvagyunk, várjuk meg, hogy kiszemeltünk megunja a piszkálódást és tényleg ne dolgozzon az elvárható szinten (ez is be fog következni, az általam ismert fejlesztők 99%-a nem viseli el az ennyire közvetlen ellenőrzést), és ha ez megtörténik, nyert ügyünk van. Csak oda kell elé állni és megkérni, hogy mostantól vagy dolgozzon rendesen vagy pedig akkor elengedjük neki a felmondási időből hátralevő részt.

Ilyenkor már nincs jó választása, hiszen ha azt mondja, hogy inkább lelép, akkor igazunk volt, ha viszont bevállalja, hogy mégis dolgozna rendesen, akkor is, hiszen ezzel elismeri, hogy eddig nem ezt tette.

Ha ebből a szituból valahogyan mégis képes lenne kimanőverezni, akkor csak várni kell, hogy jól dolgozik-e vagy sem. Ha nem, akkor igazunk volt, már nem elég motivált, ha pedig igen, akkor is hiszen a beszélgetés előtt rosszul dolgozott, most meg jól, ergo a beszélgetés következtében változtatott.

Szerintem brilliáns, innentől az egész projekt bukása az ő hibája, hiszen a beszélgetés előtt rosszul dolgozott...

Esetleg ki lehet próbálni még nem felmondott alkalmazottal is, azonban akkor számoljunk vele, hogy tőle rövidesen meg kell váljunk.

Érdekes dolog felmondani. Amíg az ember nem teszi meg a "nagy lépést", azt gondolja, hogy milyen jó is lesz ez. Elmond majd mindent a főnökének, megmondja a tutit, megváltja a világot. Csupa móka, kacagás és káröröm még akkor is, ha ez utóbbira nem is vagyunk hajlamosak persze. 

Aztán eljön a nagy kérdés, hogy "nahát" és mégis miért, mit tehetett volna (mit tehetne!) A CÉG azért, hogy tán mégse.

És ilyenkor jön a meglepetés. Rövidzárlat, sokk, eufemizálás és hirtelen nagy-nagy megértés és jóindulat minden és mindenki iránt, így aztán köntörfalazás, finomítgatás, a csúnya igazságok mellé nagy empátia és főnök biztosítása róla, hogy nahát ez tényleg nem az ő hibájuk...

Na ezért nem vagyok jó a 'szakítás-dologban' sem.

Amikor pedig főnök bejelenti a hírt a többieknek, következő meglepetés(ek). Az egész dologból annyi lesz a hivatalos verzió, hogy az egyetlen oka a dolognak a vidékre költözés, ráadásul egy nő miatt...hogy a főnök ezt tényleg így érti, vagy pedig csak így akarja érteni, soha nem derül ki (persze gondolni sok mindent lehet róla). Ráadásul kiderül, hogy három év után elmenni a legnagyobb szemétség, amit alkalmazott elkövethet, hiszen főnök szerint három év után kezd el termelékeny lenni a programozó-állatfajta. Csak akkor nem kellene évről-évre extra-elismerést osztogatni szóbeli dicséret és/vagy prémium formájában.