[Java lista] Agilis módszertanok alkalmazása magyarországi cégeknél

2008. Sze. 16., K, 09:26:31 CEST

Hmmm,

kicsit valószínű, hogy ketten (fejlesztő meg reviewer) ugyanazt nézzék be. Másrészt a kód ellenőrzés (na jó, legyen code review) arra is használható, hogy az ellenőr ne vegye át a kódot akkor, ha túlságosan bonyolult, áttekinthetetlen, uncommented, "gány". Így már magában áttekinthető kódolásra ösztönöz, az pedig szerintem Egy Jó Dolog. Az olyan kódokat, amelyek megírása egy napba, megértése egy hétbe telik, el kell küldeni a kőkorszakot bemutató kódmúzeumba, mert oda való. A "new wave" az áttekinthető kódról szól, a hatékonyság, méret, ilyenek ma már nem nagyon játszanak. Az áttekinthető kód gyakrabban bizonyul hibamentesnek, mint a trükkös megoldásokat alkalmazó.

Amúgy a unit test meg csak akkor működik, ha tényleg "mindent" képes vagy lefedni tesztesetekkel. Az ellen valamennyire véd, hogy ne rontsd el azt, ami már egyszer működött (már ha az adott működést egyáltalán ellenőrzi). A kód azonban ettől még lehet gány, utólagos módosításnak jól ellenálló, meg minden. (Tegyük most eleve fel, hogy a unit test maga nem hibás, amely feltevés persze maga is megér egy misét).

A legjobb megoldás pedig nyilván mindkettő egyszerre.

Mellesleg az egész történet arról szól, hogy a hibák minél korábbi fázisban kiderülhessenek. Minél később derül ugyanis ki, várhatóan annál költségesebb a javítása. Ha viszonylag kis egységeket rögtön ellenőriz a munkatárs, akkor az ottani (akkor még kicsiny) implementációs, de akár tervezési hibák is rögvest kiderülhetnek, mielőtt még ráépülne egy teljes felépítmény. Jobban is emlékszik rá a gazdája.

Időnként van olyan is, hogy valaki más kódjára épül a saját modulom viselkedése. Na ilyenkor, ha reviewer vagyok, akkor olyan szemmel is nézhetem, hogy valóban tudom-e majd használni a kódjának a publikus felületét.

Végül azt se feledd, hogy az "igazi" code review esetén az ellenőr nem piszkít bele a kódba, csak megjelöli a javítandó helyeket, esetleg ajánlásokat tesz a javításra. Ebből pedig minden értelmes fejlesztő teljesen jól tanulhat is, magyarán "ingyen", pontosabban mellékhatásként egyre jobb fejlesztői csapatom lesz, hiszen egymástól tanulnak a munkatársak. Ésszerűen megvalósítva tehát akár a coaching is lefedhető (persze vigyázni kell, mert egyrészt nem szabad nagyon eltérő tudású embereket összeereszteni, másrészt a tekintélyelvre is ügyelni kell). Ugyancsak jókat lehet persze tanulni más kódjának olvasásakor, hiszen nem vagyunk egyformák, és sajátunknál másnak bizony jobb ötlete is lehet időnként ugye - tehát a dolog oda-vissza működik. Csak komolyan kell venni, mert ha a "haverom" kódját gyakorlatilag átnézés nélkül elfogadom, cserébe ő ugyanezt teszi az enyémmel, akkor becsapjuk egyrészt magunkat, másrészt a társunkat, harmadrészt a céget, és előbb-utóbb ki is leszünk rúgva (mert ugye minden csalafintaság előbb-utóbb kiderül azért).

Arra kell még figyelni, hogy ne "versenynek" élje meg senki. Nem az a cél, hogy nagy diadallal szétszedjem a munkatársam kódját, majd hetekig azt meséljem mindenkinek, hogy mennyire benézett valamit a béna. A review legyen "confidential", cserébe majd legközelebb én is ezt kapom. Amint az már elhangzott itt, "zseniális, ám antiszociális kóderekre ma már általában nincs szükség".

Nem hiszem persze, hogy sok újat mondtam volna, de talán nem haszontalan újra elismételni. Meg persze ellenvéleményem is van, amint az a fentiekből is látszik, szerintem a code review nem csak, és nem is elsősorban a kód tervezési hibák kiküszöbölésére való.

Zárszóként egy rövid "interjú" saját magammal:

Fejlesztőként szeretem-e, hogy mindenféle checkstyle és egyéb módon rákényszerítve köteles vagyok bizonyos dolgokat betartani?
Nem, kicsit sem szeretem.

Fejlesztőként vettem-e már hasznát, hogy rá voltam kényszerítve bizonyos kódolási "formalizmusra"?
Igen, fordult már elő, hogy anélkül valószínűleg benéztem volna egy névütközést.

Fejlesztőként szeretek-e kommenteket írni a kódba?
Néha igen, gyakrabban nem, mert elvon az "igazi" munkától, és kódot írni bizony érdekesebb.

Fejlesztőként vettem-e hasznát, hogy más vagy akár a saját kódom jól volt dokumentálva?
Igen, nagyon gyakran, már a fél éve írt kódomban is értek "meglepetések" (jééé, milyen trükkösen tudtam ezt megoldani).

Projektvezetőként szeretem-e, ha a munkatársaim betartják a közösen megalkotott szabályokat?
Ez most valami beugrató kérdés? Persze hogy igen! Van más helyes válasz is?

Na ebben (is) segít(het) a code review.

Üdvözlettel,

Iván

Iván Ketler
Project Coordinator

Lufthansa Systems Hungaria Kft.
Airline Management Solutions
Schedule & Revenue Management
Alkotás u. 53.
1123 Budapest
Hungary

Tel: +36 1 887-2815
Fax: +36 1 887-2977

Room: MOM Park, Building A, Room 556

e-mail: istvan.ketler at lhsystems.com
Internet: www.LHsystems.hu

> 

Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Monika Houck

-----Original Message-----

> From: javalist-bounces at javagrund.hu 
> [mailto:javalist-bounces at javagrund.hu] On Behalf Of Marai Laszlo
> Sent: Monday, September 15, 2008 10:57 PM
> To: javalist at javagrund.hu
> Subject: Re: [Java lista] Agilis módszertanok alkalmazása 
> magyarországi cégeknél
> 
> On Mon, 15 Sep 2008 13:19:27 -0700
> Gergely Hodicska <felho at avalon.aut.bme.hu> wrote:
> 
>   Hali!
> 
> > > Persze, hogy sokkal hatekonyabb, csak masra valo.
> > Lehet félreérthető voltam: számomra az volt meglepő, hogy pont unit 
> > tesztelés helyett ajánlották.
> 
> Szerintem az tenyleg marhasag. A code review leginkabb a 
> (kod)tervezesi hibak kiiktatasara alkalmas. Persze, a masik 
> kodjaban konnyebben eszreveszed a bugot, de attol meg 
> emberkent ugyanugy el fogsz nezni ezt-azt, a unittestet meg 
> ugye eleg egyszer megirni, aztan az minden kis valtoztatas 
> utan ellenorizni fog neked. Probald ki ugyanezt egy kollegaval :)
> 
>   atleta
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
> 