Mi az a cargo cult engineering?
Hívhatjuk rakománykultusznak is, az olvasók többségének valószínűleg akkor sem fog beugrani elsőre, hogy miről van szó, és egyáltalán honnan kapta a nevét a napjainkban is számtalan helyen megfigyelhető jelenség. Bár a tüneteit, velejáróit én is ismertem, bevallom, a kifejezéssel először néhány hete találkoztam. Hogyan jön egyáltalán az antropológia ahhoz, ha valaki ész nélkül másolgatja, és módosítja a forráskód részleteit, és miről hadováltam az előző mondatokban? Erre keressük a nem is olyan egyértelmű válaszokat.
Honnan ered a név?
Megmondom őszintén, ha leültetnek, hogy találjam ki a cargo cult jelenség eredetét, soha nem jöttem volna rá. Amikor Óceánia néhány bennszülött törzse először találkozott idegenekkel, akik az őslakosok számára teljesen ismeretlen ételeket, tárgyakat, szerszámokat hoztak különféle, szintén ismeretlen közlekedési eszközök segítségével, akkor logikus magyarázat híján az a nézet terjedt el köztük, hogy az idegenek közvetlenül az istenektől kapják ezeket a javakat, ráadásul bedobozolva (innen a cargo név). Ahhoz pedig, hogy ők is részesüljenek minden jóból, nem kell mást tenniük, csupán utánozniuk az idegeneket, így hát repülőt építettek szalmából, rádiót kókuszdióból, és így tovább, a sor hosszasan folytatható (az alábbi fotón épp egy, a bennszülöttek által épített kamurepülőgép látható). A cargo cult kifejezést az angol nyelvben éppen ezért előszeretettel használják olyan szituációkban, amikor valaki egy adott képesség hiányában, ész nélkül másol le dolgokat, azt a látszatot keltve, hogy hozzáértő a témában.
Hogyan jelenik ez meg egy informatikai cégnél szervezeti szinten?
Steve McConnell két nagyon jó példát hoz fel erre: vegyünk két képzeletbeli céget, az egyik a folyamatorientált, a másik a feladatorientált szemléletmódot részesíti előnyben. Az előbbi a bürokratikus nagyvállalatokat tekinti példaképének (állami szervek, multik, stb...), akik kínosan ügyelnek a dokumentációk meglétére, és fontosnak tartják, hogy gyakran tartsanak meetingeket. Ezen vállalat vezetősége úgy látja, hogy az ilyen cégek sikeresek, úgyhogy ők is sokat fognak ezentúl dokumentálni, és meetingelni, hogy sikeresek legyenek.
Utóbbi, a feladatorientáltsággal szimpatizáló cég vezetősége azokat a vállalatokat tekinti példaképének, ahol keveset dokumentálnak, a feladatokra összpontosítanak, részvényeket adnak juttatásként az alkalmazottaknak, akik mindeközben sokat túlóráznak.
Ha az említett két cég semmi mást nem csinál, csak gondolkodás nélkül lemásolja a példaképek módszereit, akkor egy valami biztosan közös lesz bennük: hogy nem fogják jól érezni magukat a dolgozóik.
A saját cégükre vonatkozó hatástanulmány, vagy bármilyen előzetes elemzés, felmérés híján ugyanis figyelmen kívül hagyják, hogy nem a bürokrácia, vagy a túlórázás a siker kulcsa, ezek csupán a melléktermékei egy-egy adott módszernek, szemléletmódnak. A folyamatorientált cégnél a túlzott dokumentálási kényszer egy szükséges rossz, ami a szigorú szabályozásokból fakad, míg a feladatorientált példa esetén az alkalmazottak valószínűleg azért túlóráznak "boldogan", mert szeretik, amit csinálnak, és nem csak azért, mert részvényesek lesznek a cégben.
Hasonlóan problémás az agilis módszertanok szuperfegyverként való kezelése, melyről mi is írtunk már korábban.
... és hogyan az egyes alkalmazottaknál?
Tegye a fel a kezét, aki még soha nem írt be egy konzolra úgy parancsokat, hogy fogalma sem volt azok pontos jelentéséről, működéséről! Nincs ezzel baj, senkinek sem kell polihisztornak lennie az informatikában, de fontos meghúznunk egy határt: ha valaki napi szinten, a munkája részeként másolgat kódrészleteket anélkül, hogy értené, mit csinál, az nem jó. Se az érintett személynek, se a munkaadójának.
A jelenség könnyen felismerhető jegyei a "cargo cult fejlesztőnél":
- A bugfix, refaktorálás, stb. okán módosítandó, eredetileg más által írt kódot, vagy a módosítás okát nem tudja értelmezni
- A saját kódját se érti, mert vagy csak másolta valahonnan, vagy addig próbálkozott a módosításával vakon, amíg valahogy a helyes működésre bírta
- Értelmetlen, funkció nélküli kódrészleteket ír
- Over-engineering - felesleges, szükségtelen funkciók, vagy a szükségesek indokolatlan szintű túlbonyolítása
- Felesleges kommenteket hagy, általában olyan helyeken a kódban, ahol egyébként nem is lenne indokolt
- Gyakran hangzanak el a szájából: "Eddig is működött ez így, nem kell felforgatni a bevált dolgokat!"; "Nem tudom, miért van ez így, de biztos okkal van!"
Design pattern, keretrendszerek, stackoverflow?
A fenti hármas szolgáltatja a téma végeláthatatlan vitáinak alapját, nem véletlenül. Néhány évvel ezelőtt a mostaniaknál lényegesen "fapadosabb" keretrendszerek álltak a fejlesztők rendelkezésére (vagy még ilyenek sem), nem is beszélve az online elérhető közösségi tudásbázisokról, ahol a felmerülő problémák többségére néhány perc alatt választ, és megoldást találhatunk. Adódik tehát egy csomó érdekes, nem egyértelműen megválaszolható kérdés: Cargo cult fejlesztő lesz-e attól valaki, ha:
- nem érti, hogy egy design pattern miért előnyös egy adott helyzetben, csak használja?
- problémába ütközik, melyet idő, vagy motiváció hiányában nem szeretne kizárólag a saját energiájából megoldani, ezért szakmai fórumokon már kivesézett, kész megoldást használ?
Egyesek tovább mennek a vitában, és megkérdőjelezik pl. az MVC keretrendszereket használó fejlesztők szakmai kvalitását is, bár személy szerint ezt már csak felesleges kötekedésnek érzem: a kutya valahol ott lehet elásva a vitában, hogy nem a felhasznált eszköz teszi a fejlesztőt jobbá, vagy rosszabbá, hanem a felhasználás módja, és oka.