Hogyan kezeljük a problémás kódot író munkatársakat?

Nagy valószínűséggel mindannyiunkkal megtörtént már, hogy beleakadtunk egy szörnyűnek hitt kódrészletbe, amit valamelyik munkatársunk írt. Amikor sokadszorra találunk ugyanazon tettes által írt ezersoros metódusokat, másolt kódokat és hasonló rémségeket, egy ponton biztosan megszületik bennünk a döntés, hogy komolyabban elbeszélgessünk az illetővel — ezelőtt azonban érdemes hideg fejjel átgondolni, hogyan közelítsük meg a dolgot. Ezt a kérdést járjuk ma körbe Erik Dietrich cikkének mentén.

Nem a beszélgetés a lényeg

Fontos mindenekelőtt tisztázni, hogy egy effajta beszélgetés mindig csak tűzoltás, és akármilyen ügyesen is közöljük a "problémás" kollégával az aggályainkat, ezzel nem oldjuk meg a valódi problémát.

Gondoljuk csak át a szituációt. Ha valaki rendszeresen alacsony minőségű kóddal bővíti a szoftverünket, az az egész csapat kudarca — ezáltal a sajátunk is. Érdemes ezt a beszélgetés részévé tenni, és a konstruktív kritikával egybekötve megpróbálni javítani az egész team folyamatain, hogy ez a rossz gyakorlat ne mehessen tovább.

Amit ne csináljunk

A fentiekben leírtak (jobb minőségbiztosítás, folyamatok javítása) persze nem egyszerűen és gyorsan bevezethető dolgok, általában időt igényelnek, ezért gyorsan térjünk át arra, hogy mik azok a dolgok, amiket semmiképp se csináljunk egy ilyen helyzetben!

• Ne akkor kerítsünk sort a beszélgetésre, amikor frusztráltak és mérgesek vagyunk. Várjunk egy kicsit, amíg leülepedik a kezdeti düh, és próbáljunk meg racionálisan közelíteni a problémához.
• Csakis akkor tegyük szóvá a kifogásolt dolgokat, ha azok valódi problémák. Ha csak esztétikai (pl. kisbetűs/nagybetűs változónevek), kozmetikai problémáink vannak, valószínűleg nem éri meg az egész dolog — arról nem is beszélve, hogy az ilyen jellegű problémákat jobb automatikus eszközökkel orvosolni.
• Ha csak annyit tudsz mondani, hogy ez a kód "rossz", ne is kezdj bele, ebben semmi konstruktív sincs. Ha valamiről például úgy gondolod, hogy sokat ront a kód karbantarthatóságán, mutass rá egy példát, hogy miért.

Akkor hogyan?

Ideje rátérni arra, mi az, amit csináljunk, azaz hogyan építsük fel a stratégiánkat. Ilyenkor három dologra kell kitérnünk: (a) fogalmazzuk meg pontosan a problémát, (b) tudjunk érvelni, hogy miért is rossz az a kód valójában, és (c) tudnunk kell, milyen kimenetelt várunk ettől az egésztől.

Az első pont elég egyértelmű. A probléma lehet mondjuk a túl hosszú metódusok használata, felesleges kód-duplikáció, a lényeg, hogy eléggé specifikus legyen és egyszerre csak eggyel foglalkozzunk. Legyél arra is felkészülve, hogy egy konkrét rossz példát mutass a kollégád kódjában.

Ezután jön az érvek összeszedése és a várt végkimenetel. Ilyenkor a saját véleményünk helyett (vagy mellett) sokkal hitelesebb, ha tudunk valamilyen elismert blogot vagy könyvet idézni. Ez azonban önmagában nem elég, hiszen teljesen jogosan szögezhetik nekünk a kérdést: "rendben, de akkor hogyan csináljam?". Legyünk felkészülve arra, hogy közösen, a kollégát segítve alakítsunk egy rossz példát jó megoldássá, így sokkal nagyobb az esély, hogy segítünk megszüntetni ezeket a rossz szokásokat.

Elsőre talán egy ilyen beszélgetést kezdeményezni nehéznek tűnhet, azonban a fenti pontokat követve sokkal kevésbé lesz az, sőt, akár egy konstruktív, minőségi javulást hozó folyamat kezdete is lehet.