Clean Code - Miért fontos a beszélő kód, és miért rossz a sok comment?

Az előzőekben tehát lejött, hogy a kódolásnál igazából absztrakciós szintek és felelősségi körök szerint daraboljuk fel a kódot kis egységekre, osztályokra, metódusokra, és így tovább. Ez egy része a dolognak. A másik része a clean code-nak, hogy milyen osztály, metódus és változóneveket használunk.

Ez elsőre nem tűnik valami fontosnak. Annak idején én is úgy kezdtem a programozást, hogy az abc összes betűjét felhasználtam. Sokan megkérdezték, hogy ez már az obfuszkált kód és hogy hol az eredeti, meg hogy hogyan vagyok képes ezt elolvasni? Így utólag elég vicces visszagondolni rá.



Ha azonban megismerkedünk a már említett alapfogalmakkal, akkor szép lassan nyilvánvalóvá válik, hogy igenis fontos a jó elnevezés. Ez is egy jelző, ha nem tudunk jó nevet adni egy osztálynak vagy metódusnak, akkor sokszor valami nincs rendben. Nálam sokszor az angolommal, de az más kérdés. :D

Persze nem csak jelző, hanem logikusan is következik az absztrakciós szint fogalmából. Nyilván ha valami magasabb absztrakciós szintre kerül, akkor közelebb kell állnia az emberi gondolkodásmódhoz, amit általában a beszélt nyelvvel írunk le. (Leírhatjuk RDF-el is, de abba most ne menjünk bele, az inkább REST meg szemantikus web témakör.)

Kifejezetten jó, ha az osztálynév arról árulkodik, hogy mi az osztálynak a feladatköre. A metódus nevek pedig arról árulkodnak, hogy mit csinál az adott metódus, a metódus kódja meg nyilván azt írja le, hogy hogyan csinálja azt a bizonyos dolgot a metódus. Ezt már eggyel alacsonyabb absztrakciós szintű fogalmakkal persze. Így ha jobban érdekelnek minket a hogyan részletei, akkor megnézzük az alacsonyabb szintű osztályok kódját is, majd így haladunk egyre alacsonyabb absztrakciós szintek felé. Ez nagyon jó kereshetőség szempontjából, mert általában nagyjából be tudjuk lőni, hogy hol van az a kódrészlet, amihez hozzá akarunk nyúlni. Így könnyen eljutunk a megfelelő kódhoz, és csökken a fejlesztésnek az a holtideje, amikor csak fel-le scrollozunk, hogy megtaláljuk a kódot, amit éppen keresünk.

Ha eljutunk odáig, hogy napi szinten használjunk ezt a módszert, akkor a comment-ek nagy része feleslegessé válik. Sokan meghagyják őket dokumentáció generálásra, de ez annyira nem jó. Dokumentációt általában az API-ból, a legkülső rétegből készítünk. Nyilván belsőbb rétegekből is megpróbálhatjuk, ha sok időnk van. Ez a külső réteg viszont ha mondjuk REST és linked data-t használ, akkor RDF-ben kapásból meg tudjuk írni a dokumentációt. Az RDF generálható  commentekből, annotációkból. Egyedül ilyenkor van értelme szerintem comment-eket írni. Egyébként ha csak arra van szükség, hogy működjön a kód, és ránézésre nagyjából tudjuk, hogy mit csinál, akkor elég a beszélő neveket használni. A hosszú comment-ezéssel több baj is van. Az egyik, hogy eltördeli a kódot, amit az IDE-k manapság már többé-kevésbé kompenzálnak expand-collapse megoldásokkal. A másik, ami talán nagyobb baj, hogy karban kell tartani. Ha refaktorálunk valamit, akkor a comment-et is át kell írni. Nyilván olyankor refaktorálunk, ha egy metódus onnantól egy kicsit mást csinál, ha kiemelünk egy új osztályt, és így tovább. Mind-mind olyan dolog, ami a comment-ek módosításával jár. Így szerintem inkább csak akkor van értelme dokumentációs céllal használni ezeket, ha nagyon már kiforrott a projekt és közel van az 1.0-hoz. Egyébként csak kivételes esetekben érdemes comment-et hagyni, pl ha egy nem nyilvánvaló bug-hoz csinálunk workaround-ot, és így tovább. Ilyenkor is érdemes megfontolni, hogy valami bug specifikus adaptert használjunk inkább az eredeti függőség helyett, mert az legalább már úgy működik, ahogy elsőre elvárnánk, és nem kell emiatt comment-et írni lépten nyomon, amikor használni akarjuk.

Nincsenek megjegyzések:

Megjegyzés küldése