Kódot írni könnyű, minőségi kódot írni annál nehezebb. Az alábbi posztban olvashatsz néhány hasznos tippet, amelyek segíthetnek a magas kódminőség fenntartásában.
A kódot elsősorban munkatársainknak, nem pedig a compilernek írjuk
Az általad írt programkód legkomolyabb tesztje, hogy az elég egyszerű és átlátható-e ahhoz, hogy bármely munkatársad könnyen megértse. Ha ez nincs így, és azt veszed észre, hogy a kollégáid nehezen tudják kihámozni az általad kódról azt, hogy mit csinál tulajdonképpen, próbáld meg kideríteni, miért van ez. Lehet, hogy a megoldásod túl komplex, vagy túl kevés tesztet írtál hozzá, de akár az is előfordulhat, hogy egy közismert problémára a megszokottól eltérő algoritmust használtál. A kulcs ezeknek a problémáknak a feltárására és megoldására a folyamatos párbeszéd.
A probléma, amit te fedezel fel, a tiéd
Ha a mindennapi munkádban felfedezel valamilyen hibát vagy szuboptimális megoldást, attól a ponttól a te saját felelősséged, hogy javíts a helyzeten. Természetesen ez egyáltalán nem azt jelenti, hogy azonnal változtatásokat kell eszközölnöd, ez már az adott problémától függ. Lehet, hogy elég egy bejegyzés egy bug-adatbázisban, lehet, hogy elég, ha megemlítjük munkatársainknak. A lényeg, hogy a legrosszabb, amit tehetünk ebben az esetben az, ha csendben maradunk.
Ne akarj túl okos lenni!
Egy fontos szabály: az “okos” kód általában rossz. Ne használj kriptikus, nehezen átlátható megoldásokat csak azért, hogy megmutasd, mennyire okos és szellemes vagy. A kulcsszavak az egyszerűség és az átláthatóság.
A követelmények nincsenek kőbe vésveMérnökként, fejlesztőként kötelességed, hogy megkérdőjelezz egy esetleges követelményt, ha az számodra nem teljesen világos, vagy értelmezhetetlen, zavaros. Nem robotok vagyunk, akik vakon implementálják az üzleti követelményeket, mindig próbáljuk megérteni, mit akar pontosan a másik fél elérni, és segítsük őt technikai szakértelmünkkel!
Itt azért fontos megjegyezni, hogy vannak, akik nem szeretik az ilyesfajta megkérdőjelező magatartást, így ebben az esetben fontos lehet a diszkréció – nem kell mindezt feltétlenül nyilvánosan tennünk.
Kezdj a “Miért?”-el!
A “vision” és a “big picture” eléggé elnyűtt, menedzserek szájából gyakran elhangzó szavak, azonban ahogy mondani szokás: nem zörög a haraszt, ha nem fújja a szél. Amikor egy projekten dolgozunk, próbáljuk a saját részterületünkön túl is megérteni, hogy miért is készítjük az adott szoftvert, milyen problémát és ki(k)nek oldunk meg vele.
Sokszor ha egy-egy nagyon specifikus probléma mélységeiben járunk, könnyen szem elől téveszthetjük ezt a bizonyos “miért”-et. Ezekben a pillanatokban érdemes egy kicsit magasabbról szemlélni a dolgokat, és végiggondolni a fentebb taglalt kérdéseket.
A “miért”-et persze legtöbbször nem mi magunk fogalmazzuk meg, hiszen a legtöbbünk valaki másnak dolgozik. Ebben az esetben a vezető feladata ezeket mindenki számára egyértelművé és világossá tenni.
Az általad írt programkód legkomolyabb tesztje, hogy az elég egyszerű és átlátható-e ahhoz, hogy bármely munkatársad könnyen megértse. Ha ez nincs így, és azt veszed észre, hogy a kollégáid nehezen tudják kihámozni az általad kódról azt, hogy mit csinál tulajdonképpen, próbáld meg kideríteni, miért van ez. Lehet, hogy a megoldásod túl komplex, vagy túl kevés tesztet írtál hozzá, de akár az is előfordulhat, hogy egy közismert problémára a megszokottól eltérő algoritmust használtál. A kulcs ezeknek a problémáknak a feltárására és megoldására a folyamatos párbeszéd.
A probléma, amit te fedezel fel, a tiéd
Ha a mindennapi munkádban felfedezel valamilyen hibát vagy szuboptimális megoldást, attól a ponttól a te saját felelősséged, hogy javíts a helyzeten. Természetesen ez egyáltalán nem azt jelenti, hogy azonnal változtatásokat kell eszközölnöd, ez már az adott problémától függ. Lehet, hogy elég egy bejegyzés egy bug-adatbázisban, lehet, hogy elég, ha megemlítjük munkatársainknak. A lényeg, hogy a legrosszabb, amit tehetünk ebben az esetben az, ha csendben maradunk.
Ne akarj túl okos lenni!
Egy fontos szabály: az “okos” kód általában rossz. Ne használj kriptikus, nehezen átlátható megoldásokat csak azért, hogy megmutasd, mennyire okos és szellemes vagy. A kulcsszavak az egyszerűség és az átláthatóság.
A követelmények nincsenek kőbe vésveMérnökként, fejlesztőként kötelességed, hogy megkérdőjelezz egy esetleges követelményt, ha az számodra nem teljesen világos, vagy értelmezhetetlen, zavaros. Nem robotok vagyunk, akik vakon implementálják az üzleti követelményeket, mindig próbáljuk megérteni, mit akar pontosan a másik fél elérni, és segítsük őt technikai szakértelmünkkel!
Itt azért fontos megjegyezni, hogy vannak, akik nem szeretik az ilyesfajta megkérdőjelező magatartást, így ebben az esetben fontos lehet a diszkréció – nem kell mindezt feltétlenül nyilvánosan tennünk.
Kezdj a “Miért?”-el!
A “vision” és a “big picture” eléggé elnyűtt, menedzserek szájából gyakran elhangzó szavak, azonban ahogy mondani szokás: nem zörög a haraszt, ha nem fújja a szél. Amikor egy projekten dolgozunk, próbáljuk a saját részterületünkön túl is megérteni, hogy miért is készítjük az adott szoftvert, milyen problémát és ki(k)nek oldunk meg vele.
Sokszor ha egy-egy nagyon specifikus probléma mélységeiben járunk, könnyen szem elől téveszthetjük ezt a bizonyos “miért”-et. Ezekben a pillanatokban érdemes egy kicsit magasabbról szemlélni a dolgokat, és végiggondolni a fentebb taglalt kérdéseket.
A “miért”-et persze legtöbbször nem mi magunk fogalmazzuk meg, hiszen a legtöbbünk valaki másnak dolgozik. Ebben az esetben a vezető feladata ezeket mindenki számára egyértelművé és világossá tenni.