A “Szoftverfejlesztő és -tesztelő technikus” (5-0613-12-03) szakmai képzés jelentősen megváltozott tavaly. Szerintem nagyon jó irányba. Számos új képzési követelmény jelent meg, amelyeknek megfelelni igazi kihívás lesz az oktatók és a diákok számára. Egy ilyen újdonság az, hogy a vizsga része egy Projektfeladat, melynek többek között meg kell felelnie a következő kritériumnak: “A forráskódnak a tiszta kód elveinek megfelelően kell készülnie.” Jelen bejegyzésben ezt járom körül.

Mi is az a tiszta kód?

Nem egyértelmű a kimeneti követelményekből, hogy az azt megalkotók a könyvre, vagy egy valahol definiált konkrét fogalomra gondolnak. A kérdés azért is érdekes, mert utóbbira számtalan megfogalmazás létezik. Azonban még a könyv se specifikálja azt, hanem felsorol számos definíciót, melyet különböző, a szakmában elismert fejlesztő megfogalmaz. A majd ötszáz oldalas könyvben található ismeretek készségszintű elsajátítására pedig inkább a szakmában éles projekteken eltöltött egy-két év gyakorlatra lenne szükség. Itt pedig egyetlen egy projekt elkészítéséről van szó. Márpedig azt Bob bácsi is leírja, hogy senkitől se várhatjuk el, hogy képes legyen első nekifutásra tiszta kódot készíteni. Adott tehát a kérdés, hogy meghatározzuk, mi az, amit tanítani szeretnénk és milyen eszközökre lesz ehhez szükségünk.

Kivonat

Az első lehetőség, ami az ember eszébe jut, az az, hogy nem olyan mélységig ismertetjük meg a teljes anyagot, mint ahogyan az a könyvben szerepel. A legegyszerűbb, ha vesszük a könyv tartalomjegyzékét (nagyjából ez van a PPT-ben is), vagy keresünk egy CheatSheet-et. Itt van pl. Urs Enzler által megalkotott puska. A feladat nehézségére utal, hogy a 2010-ben megjelent első egy oldalas verzióhoz képest a most elérhető négy oldalra hízott. Ez a dokumentum azért is kedves a szívemnek, mert itt található az a definíció ami a legközelebb van az én általam gondoltakhoz:

“Code is clean if it can be understood easily – by everyone on the team.”

vagyis:

A kód akkor tiszta, ha a csapat minden tagja számára könnyen érthető.

Top X

A másik lehetőségünk, hogy rákeresünk arra, hogy az egyes fejlesztők mit tartanak a legfontosabb technikáknak a tiszta kód területén. Amennyiben magyar nyelvű tartalmakra vágyunk, akkor nem lesz olyan sikerélményünk, hisz a témában csak egy blogbejegyzés található Marhefka Istvántól. Amennyiben tőlem kérdeznéd, hogy mi az a három szabály amit mindenképpen be kéne tartani, akkor olvasd el a korábbi bejegyzésem a Code Review-ról. Annyit elárulok, hogy az első nem fog meglepni. Tudod, a kód akkor tiszta, ha a csapat minden tagja számára érthető. Ezen túl fontos, hogy az előre megbeszélt formázási szabályokhoz tartsuk magunkat, valamint legyen tesztelhető a kódunk és készüljön is hozzá teszt.

Mire lesz szükségünk?

Első körben mindenképpen meg kell valahogy oldani, hogy a tanulók közösen dolgozzanak. Itt fontos, hogy a diákok ne osszák fel a projektet backend, frontend és alkalmazás részekre, amiknél minden egyes diák egy-egy résszel foglalkozik. Mindegyik részen dolgozzon mindegyik diák, legyen közös alkotás a végeredmény.

Ez lehet az, hogy egy gépnél ülnek, amibe két egér és két billentyűzet van bedugva, de lehet egyszerűen egy gyakori code review is. A code review-hoz nem kell feltétlenül eszköz, főleg akkor, ha egy légtérben dolgoznak egy időben. Kész van valamivel az egyik, szól a másiknak, aki odamegy és átnézik közösen. Eszköz akkor kell, ha időben vagy térben máshol dolgoznak. Ekkor jól jöhet egy olyan eszköz mint a GitHub pull request, vagy a GitLab merge request. Meg lehet nézni a különbségeket és azokhoz megjegyzéseket lehet fűzni. Ezek segítségével megvitatható és tisztázható minden kérdés.

Az általam vezetett csoportnak (mindenképp) ajánlanék egy olyan eszközt is, ami statikus kód analizálást végez, és megjelöli azokat a kód részleteket, melyek potenciális problémát jelenthetnek. Ezek az úgynevezett code smell-ek. Ezt az eszközt aztán érdemes az IDE-be is integrálni, hogy jelölje a problémás részeket szerkesztés közben is. Általánosságban a SonarLint-et tudom ajánlani, mert az több nyelvet és több IDE-t is támogat egyidejűleg szóval könnyedén használható. (ha tudsz hasonlót, ami tud több nyelvet és IDE-t egyszerre szólj és belinkelem azt is ide.) Szemben mondjuk a PHP CodeSniffer programmal, ami specifikus és nagyobb tudású ugyan, de csak a PHP-t támogatja és minden IDE-ben külön-külön be kell állítani, ráadásul a pl. a PHPStorm-ban két helyen is. Középfokú képzésben inkább előbbit, ipari alkalmazás esetén utóbbit, vagy mindkettőt szoktam ajánlani.

Ha van lehetőséged rá, egy iskolai SonarQube jól jöhet, már csak azért is, mert az képes az egyes projektek technikai adóságát napokban kifejezni.

Mekkora hangsúlyt kapjon?

Ha engem kérdezel, minél nagyobbat. Sőt, ha lehet minden órán, minden példánál térjetek ki rá. Ha vannak minta kódjaid, akkor azokat a Beszédes nevek (Elnevezések), Függvények, Megjegyzések (Kommentek), Formázás (Kódformázás), Láthatóság fejezetekben tárgyaltaknak megfelelően írd át. Ha a példa zavaró lenne, vagy túl bonyolult, akkor először jöjjön a nem túl jól szervezett kód, majd a végén legyen rá gondod, hogy átszervezd a fenti elveknek megfelelően. A Hibakezelés és Egységtesztek fejezetek bevezetését az alapok után a függvények bevezetésével együtt el lehet kezdeni, de arra figyelj, hogy az egységtesztek futtatása ne legyen nehéz. Ez utóbbit egy jól beállított és működő környezettel tudod elérni. Bár nem a tiszta kód témaköréhez tartozik, de a verziókezelés is egy olyan dolog, amit már az elején javaslok bevezetni és egy olyan rendszert összerakni, ahol a tesztek minden egyes módosítás esetén automatikusan lefutnak. Igen, egy felállított és működő CI-ról beszélek. Az Objektumok és adatszerkezetek (adatstruktúrák), Határok (és külső kód használata), Osztályok benne a S.O.L.I.D. elvekkel az Objektum Orientált programozás és paradigmák bevezetése után kerülhet csak elő. Természetesen, ha olyan a csapat, akkor a Single-responsibility (SRP), Open-closed (OCP) és Dependency Inversion (DIP) elvek már korábban is előkerülhetnek mint követendő minták. Az SRP-t például a függvények bevezetésekor már elővehetjük. A Lambda és névtelen függvények bevezetését az OCP ismertetésével könnyedén összeköthetjük. A DIP pedig szuper lenne, ha előjönne, amikor dátum és idő függvényeket vezetjük be. Bár a tananyagnak (ami így is elég feszes) nem része a dátumkezelés, bár szerintem említés szintjén úgy is elő fog kerülni, ha máshol nem, akkor a közismereti Digitális Kultúra tantárgynál, ahol a tankönyv tartalmaz ilyen feladatot is.

Mit tegyek, ha elakadnék?

Amennyiben tanárként dolgozol, keress meg nyugodtan, igyekszem segíteni. Egy heti két órás keretet a vállalkozásom társadalmi felelősségvállalás programja keretében erre tartok fent. Amennyiben az iparban dolgozol, akkor is keress meg nyugodtan, 2014 óta hivatásszerűen azzal foglalkozok, hogy kisebb-nagyobb cégekbe segítek bevezetni a különböző modern fejlesztési módszertanokat és eszközöket.

A blogposthoz felhasználtam Andreas Breitling képét a Pixabay -ről.