Hogyan használjuk fel a clean code alapelveit a projektjeinknél

2021.03.25. · 4 perc olvasás

Van az a szállóige a programozás elméletében, hogy egy programot megírni annyira bonyolult, mint maga a probléma, amire azt írjuk. Mi az ASH szoftverháznál általában rendkívül összetett problémákra alkotunk szoftveres megoldásokat. Van ezenkívül a clean code, ami nagyon hasznos és mindenki használja is. Sokat segít abban, hogy rövidebb idő alatt jobb minőségű szoftvertermék készüljön. Az elemeinek a beépítése a mindennapi munkába és zökkenőmentesre csiszolása azonban egy hosszadalmas folyamat. Van benne része a „próba szerencse faktornak” is! Ki kell próbálni és ki kell elemezni, hogy melyik elem miként emelhető be a legjobban, esetleg milyen módosításokat kell elvégezni rajta, hogy a legoptimálisabban működjön. Mostanra sikerült elérni, hogy ez minden fejlesztésüknek az alap motorja. Hogyan használjuk fel tehát a clean code alapelveit úgy, hogy az a legjobban illeszkedjen a munkafolyamatainkba?

A clean code-t felfoghatjuk úgy mint egy ajánlás csokrot. Egy hatalmas nagy csokrot, ami az évek-évtizedek alatt felgyülemlett programozói tapasztalatot hívatott egy egységes és emészthető formába gyúrni. Rengeteg eleme van, ezek közül emelnék ki párat.

• Olvashatóság. Talán a legfontosabb. Egy jól megírt kód öndokumentáló. Akár a kommenteket is mellőzhetjük, hiszen egy mindenki számára világos, könnyen végig követhető vezérfonal rajzolódik ki, ami könnyen emészthetővé teszi még a legnehezebb részeket is.
• Egyszerűség. Semmi sallang. Egy program legyen céltudatos és lényegre törő.
• Egy objektum egy funkció. Értelmezhetjük metódusokra is, ez a „pure functio” elve. Ez talán a legnehezebben betartható ajánlás, mi is gyakran megküzdünk vele. Viszont egy dologból sosem engedünk: semmilyen építőegység ami a munkánkba bekerül nem tartalmazhat side effectet. Addig bontjuk tovább mindent kisebb alegységekre, amig ez meg nem valósul.
• Idő előtti optimalizáció. Szintén egy nehezen kezelhető rész. Az adott programnak annyi és csak annyi kódot szabad tartalmaznia, amennyire szüksége van a felhasználói vagy üzleti igény kielégítéséhez. Ami viszont folyamatosan változik és alakul át! Tehát mégis valahogy figyelembe kell venni. Nagyon sokat segít ebben ha a program minél kevésbé van összedrótozva, ezáltal könnyebben alakítható, módosítható. Fontos, hogy interfészekre programozzunk, ameddig csak lehet kerüljük a konkrét osztályok bevezetését. Szintén rossz, ha az osztályok a függőségeiket maguk kezeli, ehelyett célszerűbb DI-t (dependency injection) megvalósító keretrendszereket vagy factory mintákat alkalmazni.
• Duplikációk kerülése. Ez is egyszerűbben hangzik, mint amilyen a megvalósítása, bár a könnyebben beilleszthető alapelvek közé tartozik. Kerülendő, hogy csak amiatt, hogy megússzuk a duplikációt esetleges side-effecteket vezessünk be. Néha nehéz eldönteni, mi a fontosabb. írjunk e két különböző függvényt, ami csak egy sorban különbözik, vagy szegjük meg az egy függvény egy funkció elvét. Vannak minták amik itt is segíthetnek például a function overloading függvényeknél, vagy a polimorfizmus az osztályok metódusai esetén.

Ezek talán azok az ajánlások, amiket mindenképpen beemelünk a mindennapi munkánkba. De hogyan szervezzük meg magát a munkafolyamatot?

A legfontosabb szempont az újrahasznosíthatóság. Minden projektünknél az egyik fő priorítás, hogy a benne megálmodott elemek és struktúrák később minél jobban felhasználhatóak legyenek. Így térül meg a befektetett idő. Ehhez az kell, hogy már a kezdetektől ennek tudatában építsük fel az adatstruktúráinkat. Egy objektumnak a szabály szerint csak egy funkciót szabad megvalósítania, de ez az egy funkció különféle környezetekben is ugyanazt az eredményt kell hogy produkálja. Tehát analizálni kell az összes már megvalósult és a jövőben várható nagyobb munkát és ezekben megkeresni a közös atomi részeket. Csak olyan egységek jöhetnek szóba, amikhez olyan funkciót rendelhetünk hozzá, ami minden, a munkáink során előforduló környezetben idempotens eredményt hoz. Ez a legnehezebb rész. Utána jön az alapos tesztelés, majd ezeknek az építőkockáknak az egységbe rendezése. Majd az integrációs tesztek.

Mik segítenek az említett atomi részecskék megtalálásához? Természetesen megvannak erre a módszereink, amiket teljes egészükben itt nem fedhetek fel, csak néhány részletet.

• Erős DDD (domain driven design) szemlélet. Néha hasznosabb a dolgokat a másik oldalról, az üzleti igény oldaláról megközelíteni. Itt kulcsfontosságú a projektmenedszerek és a tapasztalt programozók kitűnő összhangja!
• TDD (test driven design) szemlélet. Sajnos ez nem mindig valósul meg, de ahol tudjuk felhasználjuk. Amelyik objektum az “atomi építőegység” szerepére aspirál, arra projekttől függetlenül azonos, releváns és egyszerű teszteket lehet írni.
• Az elnevezések fontossága. Triviálisnak hangzik, de nem lehet eleget hangsúlyozni!

Természetesen felhasználunk még rengeteg mást is. Ezeket nem akarom itt mind felsorolni, hisz mindenki kívülről fújja őket:)! Akik még nem, azoknak itt van pár hasznos olvasnivaló:

1. Erich Gamma: Design patterns.
2. Joshua Bloch: Effective java
3. Robert C. Martin: The Clean Coder: A Code of Conduct for Professional Programmers
4. Robert C. Martin: Clean Code: A Handbook of Agile Software Craftsmanship
5. Robert C. Martin: Agile Software Development: Principles, Patterns and Practices