← Esettár

FTKONF-014

Amikor az értékeid különböznek a kollégáidétól

Helyzet

„Hogyan magyarázzam el az üzleti prioritásokat egy programozónak?” · „How to explain business priorities to a programmer?” · szerző: Benubird · CC BY-SA

Egy kis cégben (kb. 10 fő) a vezető és egy fejlesztő hónapok óta ugyanazon vitázik: hogy mi számít „jó munkának". A fejlesztő számára a legfőbb érték a szakmai színvonal: mindent a tankönyvi sztenderd szerint kell csinálni. A másiknak viszont az számít, hogy a megoldás működjön és kiszolgálja az üzleti igényt (gyors legyen, legyen kész a határidőre, és legyen karbantartva). Egy konkrét eset: a „szép" megoldás 4 óra alatt futott le, a „csúnya" 30 mp alaott; a fejlesztő mégis elvi alapon visszautasította az utóbbit, és nem hajlandó a kódnak azon a részen dolgozni.

A forrásposzt teljes szövege (magyarul és angolul)

Az eredeti Stack Exchange-kérdés hű magyar fordítása · szerző: Benubird · The Workplace, q47548 · CC BY-SA.

Hogyan magyarázzam el az üzleti prioritásokat egy programozónak?

Visszatérő nézeteltérésem van egy programozóval a kód minőségéről. Ő azt állítja, hogy minden kódját a lehető legmagasabb színvonalon írja (vagyis pontosan úgy néz ki, mint a kódolási stíluskönyvek példái), tekintet nélkül arra, hogy ez milyen hatással van a működésre. Én ezzel szemben fontosabbnak tartom, hogy a megírt kód az üzlet igényeit szolgálja ki, vagyis hogy hatékonyan működjön, ne tartson túl sokáig a fejlesztése, és ésszerűen karbantartható legyen. Nemrég összevitatkoztunk egy konkrét szkripten, amelyet ő írt: remekül néz ki, tökéletes a stílusa, és pontosan úgy működik, ahogy a különféle könyvek a legjobb gyakorlatként leírják. Nekem van egy alternatív változatom, amelyet egy úgynevezett „antimintával” írtam meg, és amelyről ő azt állítja, hogy abszolút borzalmas kód, amelyet soha nem volna szabad használni. Csakhogy ez történetesen körülbelül ötször gyorsabban fut. Próbáltam meggyőzni, hogy szüksége van erre az antimintára, még ha az „rossz kód” is, mert a gyors futás fontosabb, mint a csinos kinézet. Ő nem ért egyet, és kerek perec megtagadta, hogy bármilyen olyan kódot fontolóra vegyen, amely nem felel meg az elismert „jó” stílusmintáknak, még akkor is, ha ez azt jelenti, hogy tovább tart megírni, és nem teljesít olyan jól. Példaeset: ő egy ORM-et akar használni az adatbázis eléréséhez. Egy különösen bonyolult lekérdezésnél az ORM nem optimalizál jól, és a futás több mint 4 óráig tart. Beillesztettem egy kis nyers SQL-t közvetlenül, és a végrehajtási időt 30 másodperc alá csökkentettem. Ő nagyon határozottan tiltakozott, mondván, hogy nyers SQL-lekérdezéseket közvetlenül írni rossz gyakorlat, és mindig az ORM-et kell használnunk. Most már megtagadja, hogy a program azon a részén dolgozzon. Próbáltam elmagyarázni, hogy egy jól működő program fontosabb, mint egy szépen kinéző kód, de ő csak annyit mond: „nem, nem az”, és tovább írja a stílusos, nem hatékony kódját, amelyet aztán nekem kell néha rosszul átírnom, mielőtt használható lenne. Jelenleg rossz helyzetben vagyunk, mert ő nem hajlandó kompromisszumot kötni a normáiban, ami azt jelenti, hogy mindent, amit csinál, nekem kell átnéznem, és bizonyos esetekben módosítanom, hogy biztos legyek benne: az üzlet igényeinek felel meg, nem csupán az ő esztétikai mércéinek. Hogyan tudnám meggyőzni, hogy rangsoroljon át, és az üzlet céljait helyezze a kódja csinossága elé? Szerkesztés: Stephan Kolassa javasolta, hogy ezt is írjam bele: technikailag én vagyok a főnöke, de olyan kis cég vagyunk (~10 fő), hogy én is programozok, így egyúttal mintegy a társa is vagyok, ami épp egy kicsit bonyolultabbá teszi a dolgot, és nincsenek rögzített szervezeti normáink vagy konfliktusrendezési eljárásaink.

A közösség legjobbnak ítélt válasza

user1450877 (169) · CC BY-SA

I wouldn't try to dictate his style of coding … If performance is an actual documented business requirement and he fails to fulfil it, call him out on that. If he carries on failing to meet business requirements then he is failing to do his job.

Magyar összefoglaló: értékvitát nem lehet meggyőzéssel „megnyerni". Tedd mérhető, kimondott követelménnyé (pl. „a futásidő legyen X alatt"); onnantól nem ízlés kérdése, hanem teljesített/nem teljesített elvárás. Az értékét hagyd meg neki, a követelményt rögzítsd.

Valós forrás: „How to explain business priorities to a programmer?” · szerző: Benubird · Stack Exchange / The Workplace (q47548) · CC BY-SA · magyar fordítás, anonimizálva. Az eredeti poszt →