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.
Original Stack Exchange question · author: Benubird · The Workplace, q47548 · CC BY-SA.
How to explain business priorities to a programmer?
I have a recurring disagreement with a programmer about code quality. He insists that all of his code is written to the highest standard (i.e. that it looks just like the examples in the coding styles textbooks), regardless of the impact this has on functionality. I, on the other hand, think it is more important that the code written meets the needs of the business - i.e. that it works efficiently, does not take too long to develop, and is reasonably maintainable. We recently had an argument, where a specific script he has written looks great, is perfectly styled, and works exactly as the various books describe as best practice. I have an alternate version, which has been written using a so-called "anti-pattern", and which he insists is absolutely terrible code that should never be used. However, it also happens to run approximately five times as fast. I have been trying to convince him that he needs to use this anti-pattern, even if it is "bad code", because running quickly is more important than looking nice. He disagrees, and has point blank refused to consider writing any code that does not conform to the recognized "good" style patterns, even if this means it takes longer to write and does not perform as well. Example case: He wants to use an ORM to access the database. For one particularly complicated query, the ORM does not optimize it well, and it takes more than 4 hours to run. I inserted some raw SQL directly, and reduced the execution time to under 30 seconds. He objected - very strongly - saying that writing raw sql queries directly is bad practice, and we should always use the ORM. Now he refuses to work on that part of the program. I have tried to explain that having a program that works well is more important than having code that looks nice, but he just says "no it's not" and carries on writing his stylish, inefficient, code, which I then sometimes have to rewrite badly before it can be used. At the moment, we are in a bad position, because he refuses to compromise his standards, which means that everything he does has to be checked over by me and in some cases modified to be sure that it meets the needs of the business, and not just his aesthetic standards. How can I convince him to reprioritize, and put the objectives of the business ahead of the prettyness of his code? Edit: Stephan Kolassa suggested I include this: I am technically his manager, but we're such a small company (~10 ppl) that I also program, and so am sort of his peer at the same time, which just makes it a little more complicated, and we don't have any fixed organizational standards or conflict resolution procedures.
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 →