7 hasznos tipp a kódminőség javítására
Kódot írni könnyű, minőségi kódot írni annál nehezebb. Ezt mi sem bizonyítja jobban, mint hogy a “vadonban” valószínűleg sokkal kevesebbszer csattintunk elismerően egy kódbázis láttán, mint amennyiszer a hajunkat tépnénk a benne használt rossz megoldások miatt. Az alábbi posztunkban összeszedtünk 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ésve
Mé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.
A SOLID fontos, a tervezési minták kevésbé
A formális oktatásban sokszor nagy hangsúlyt fektetnek a tervezési minták bemagolására, ami sokszor ahhoz vezethet, hogy a gondolkodásunk túlságosan merevvé válik, hiszen bármilyen problémára az általunk ismert megoldások kötött listájából próbálunk egyet kiválasztani.
A tervezési minták a valóságban sokkal ritkábban fordulnak elő, mint gondolnánk. Természetesen néhány alap minta ismerete valóban szükséges, de számos komplexebb patternnel szinte sosem fogsz találkozni.
Tervezési minták bemagolása helyett inkább fontos, hogy betartsuk a SOLID szabályait. Ezeknek az ismeretése meghaladja a cikkünk kereteit, de ha ez számodra keveset mond, érdemes a hozzá tartozó Wikipedia bejegyzéssel kezdeni.
A fejlesztésben nincsenek dogmák
Egy problémának szinte mindig több megoldása van. Az, hogy ezek közül melyik a legjobb, óriási mértékben függ az adott kontextustól és számos egyéb paramétertől.
Ne használjunk valamilyen technikát, frameworkot vagy bármi mást csak azért, mert az épp trendi, vagy épp ún. “best practice”. Nincs legjobb programozási nyelv, legjobb keretrendszer, legjobb adatbáziskezelő rendszer. Csak eszközök vannak, amiket különböző problémák megoldására fejlesztettek ki; a mi dolgunk az, hogy megtaláljuk ezeknek egy olyan halmazát, amely a mi problémánkat a lehető legjobban oldja meg.