ugrás a tartalomhoz

Tiszta kód – Az agilis szoftverfejlesztés kézikönyve

tiku I tikaszvince · 2011. Dec. 29. (Cs), 20.07

Szerző:

Robert C. Martin

Kiadó:

Kiskapu

Kiadás éve:

2010

ISBN:

9789639637696

Oldalak száma:

512

Értékelés:

7

Linkek

A Kiskapu Könyvkiadó gondozásában megjelent Tiszta kód – Az agilis szoftverfejlesztés kézikönyve, helyenként talán túlzottan sarkos kinyilatkoztatásokkal ugyan, de rendkívül hasznos tanácsokat ad a mindennapi kódolási munkához.

Ha valaki csak az Előszó és a Bevezetés részekben leírt alapelveket olvassa el, veszi komolyan, és alkalmazza a mindennapokban, már mondhatja, hogy elindult a jobb fejlesztővé válás rögös útján.

De aki hajlandó tovább olvasni olyan gyakorlati szempontokat tehet magáévá, melyek figyelembevételével megelőzhetőek az előállított kód logikátlanságai, elkerülhetőek a potenciális hibaforrások.

A tiszta kód írásának talán legfontosabb célja, hogy bárki is vegye a keze közé a jövőben az általunk írt forrást, azt érezze, ez a rendszer a keze alá dolgozik, segíti az áttekintést, a megértést. Utat mutat az új belépőnek, hogyan is kell a rendszerhez illő további kódokat előállítani.

Kár, hogy csak és kizárólag Java nyelven megvalósított példák vannak. Emiatt pl. a párhuzamossággal foglalkozó 13. fejezet számomra – PHP fejlesztőként – érdektelen volt. A kifejezett Java5 tanácsok Java ismeret nélkül sokszor zavarosak.

Az általunk írt kód árulkodik arról, mennyire figyelünk oda a részletekre, mennyire figyelünk másokra, mennyire magunkra. Igényes emberek igényes kódot állítanak elő, amiben hatékony a hibák felderítése és javítása. És nem csak az eredeti kódot előállító fejlesztő számára.

 ■
1

Szerintem nem számít, hogy

inf · 2011. Dec. 29. (Cs), 23.20
Szerintem nem számít, hogy java nyelvű példák vannak benne, az elvek, amiket tárgyal nyelv függetlenek... Alapmű mindenkinek.
2

Nem a közölt alapelveket

tiku I tikaszvince · 2011. Dec. 30. (P), 11.16
Nem a közölt alapelveket kritizáltam, hanem az azok átadására választott formát. A választott forma miatt akaratlanul is ad olyan tanácsokat, amik Java környezetben ugyan hasznosak és követendők, de más nyelvet használatakor többet ártanak mint használnak.

Csak egy példa: azt javasolja, hogy ne írjunk minden metódushoz JavaDoc megjegyzést, különösen akkor ha az csak a paramétereket és a visszatérési érték típusát sorolja fel, mert a modern IDE-k vagy a dokumentáció készítő alkalmazások a függvény definícióból tudnak dolgozni.

Mindannyian tudjuk, hogy a PHP-ban nem tudod megadni nyelvi elemekkel hogy egy-egy függvényed/metódusod milyen típusú adatot fog visszaadni, illetve nem mindig egyértelmű, hogy milyen típusú paramétereket vár. De minden modern IDE és dokumentáció generátor, PHP esetén, ezekre - a szerző szerint tök felesleges - megjegyzésekre építi szolgáltatásait.

Akár merről is nézzük alapvetően ez a könyv egy "best practice" gyűjtemény. De az egyes tanácsok nem csak az "így jó mert aztmondtam" érveléssel kerülnek megindoklásra, hanem a távolabbi cél, nagyobb jóhoz, a tiszta, átlátható, minőségi kód érveivel. De a használt forma (Java példák) miatt némelyik tanács csak és kizárólag Java környezetben áll meg.
3

Persze, ez igaz, vannak nyelv

inf · 2011. Dec. 30. (P), 21.39
Persze, ez igaz, vannak nyelv függő dolgok, ezért kell megérteni, hogy mit miért csinálunk ezek közül a technikák közül, aztán ha értjük, akkor tudunk mérlegelni, hogy az adott nyelvben működik e vagy sem. Például a beszélő nevek és a kis metódusok és osztályok teljesen jól működik nekem PHP-ban is, ugyanúgy ahogy a comment nélküliség. Még nem olvastam teljesen végig ezt a könyvet, de ha lesz időm, akkor végigtolom, és írok egy kis összefoglalót róla. Nehéz 400 oldalt 5 oldalba sűríteni, de azért megpróbálom :-)

kieg:
PHP egyébként nem a legjobb nyelv arra, hogy Clean Code szemlélettel programozzunk benne. A gond a típusossággal van, az általam használt NetBeans kódkiegészítője sok objektumról nem tudja eldönteni, hogy micsoda. Ez általában abból következik, hogy setterrel állítom be őket kívülről... Jó lenne, ha php-ban lehetne típusokat rendelni az osztályok tulajdonságaihoz...
4

9 pont :)

T.G · 2012. Jan. 2. (H), 20.21
Tudom, hogy egy könyv osztályozása rendkívül szubjektív, és ha azt vesszük, akkor a 10-ből 7 nem is lenne rossz, de látva, hogy a Refactoring - Adatbázisok újratervezése 9 pontot kapott, mégiscsak írok ide egy kis pozitívabb véleményt.

Véleményem szerint a Refactoring könyv megkérdőjelezhetetlenül 10-ből 10 pontos! Ám azt érzem, hogy a mű sikere kapcsán két felesleges könyv is született, míg az eredeti könyv hosszú évek tapasztalatait írja le, addig a HTML, illetve az adatbázis könyvek csak közhelyeket durrogtatnak. (nem lepne meg, ha csupán néhány hónap alatt dobták volna őket össze, nem tudom)

E két könyvvel szemben a Tiszta kód viszont nagyon olvasmányos, számtalan hasznos tanácsot tartalmaz. Mindamellett az előzőekhez képest is sok újdonsággal. A most kiadott könyv az eredeti mű második kiadása, emiatt jobban kiemelte a szerző, hogy az előző verzióhoz képest mik változtak a Java nyelvben. Több előzőleg leírt szabályt módosított. Ez valóban PHP-s szemmel nem előny, de véleményem szerint nem is (akkora) hátrány. :)
5

+1 :-)

inf · 2012. Jan. 3. (K), 07.36
+1 :-)
6

Pontozás

Török Gábor · 2012. Jan. 22. (V), 23.48
A könyv pontozását mindig aszerint kell értelmezni, hogy az ajánlót beküldő mit írt (a la kontextus). Szubjektívek a kritikák, én például 10-es pontot adnék a Clean Code-ra, mert szerintem alapmű, és én ezt így fejezném ki, mégha nem is tökéletes a könyv.
7

10

pacsee · 2012. Már. 19. (H), 21.50
Én most fejeztem be a napokban a könyv elolvasását, voltak - python programozóként - nehezen átültethető részek, de a leírt elvek, hogy hogyan álljunk neki, kitűnőek.
Azt gondolom nagyon hasznos lesz nekem, és azoknak akik majd egyszer a munkámat folytatják ;)

Szerintem is alapmű, én is 10-est adnék a könyvnek.
8

Én még csak most kezdtem el

H.Z. v2 · 2012. Már. 19. (H), 22.07
Én még csak most kezdtem el (csak nincs hozzá türelmem, hogy végig olvassam)
Itt-ott belelapozva nem tudok 100%-ig egyetérteni a szezővel. Mondjuk korábban próbáltam ismerkedni a java-val, így aztán egyáltalán nem zavar, hogy java példákat hozott, de pl. kommentek terén nem feltétlenül fogadnék szót a szerzőnek.
9

Nekem bejött a comment-es

inf · 2012. Már. 19. (H), 23.37
Nekem bejött a comment-es fejezet is, azóta olyan elvek alapján fejlesztek, és mondjuk ha nem tudok elnevezni valamit rendesen, és comment-hez kéne nyúlni, akkor általában valami tervezési hiba szokott lenni a dologban. Eddig legalábbis minden alkalommal ez történt. (Mondjuk csak 4 hónapja tolom így, úgyhogy még bármi lehet.)
15

Sokszor az a baj, hogy a

MadBence · 2012. Már. 21. (Sze), 08.27
Sokszor az a baj, hogy a csapat többi tagja nem érti a könyvben taglalt kommentelési filozófiát. Mármint valamiért az egyik srác ha ki van adva, hogy most kommentelni kell, akkor minden áron minden sort kommentelni akar. Hiába magyarázom el neki, hogy semmi plusz információt nem ad az, hogy
//ha aktív
if(isActive())
{
//...
}
Mondjuk azért szerintem a metódusokhoz JavaDoc kommenteket írni nem hülyeség, már csak dokumentációs célok miatt se, hiába olvasható akármilyen folyékonyan a kód. Egész egyszerűen ha doksit csinál az ember a kódból, akkor kell.
16

Az ehhez hasonló eseteknek is

H.Z. v2 · 2012. Már. 21. (Sze), 08.56
Az ehhez hasonló eseteknek is lehet jelentősége, mivel úgy látom, a mai napig dolgoznak olyanok is programozóként, akik nem tudnak angolul - bár kicsit nehezen tudom felfogni, hogy jön nekik össze.

De nekem úgy tűnt, hogy az ennél kevésbé triviális esetek jó részét is feleslegesnek tartja a szerző. Ha félreértettem volna, akkor vegyétek úgy, hogy nem szóltam.

Fenti példa esetében úgy gondolnám, a könyv szerint az isActive() fv./metódus sem igényelne kommentárt (még paramétere sincs, a neve - elméletileg elég beszédes), holott részben dokumentációs céllal, részben arra az esetre, ha évekkel később kell előszednem, érdemes pár szót vesztegetni rá, hogy valójában ki is ő és mi célból keletkezett.

Ráadásul én úgy vettem a könyvet, hogy bár az írója java példákra épít, nem nyelvfüggő amit ír. Akkor meg lásd korábbi pythonos példában a help() használata!
ui: dokumentációs céllal = valamelyik doksi generátor használatához.
17

Azt hiszem ez akkor megszokás

inf · 2012. Már. 21. (Sze), 16.10
Azt hiszem ez akkor megszokás kérdése is. Engem pl kifejezetten zavar, ha a commentektől nem látom a kódot. NetBeans-ben pl be van kapcsolva az auto fold vagy collapse (nem tudom hirtelen melyik szót használja), szóval hogy összecsukja a commenteket... Tagolásban még így is zavar, mert kihagy egy-egy sort miattuk.
18

Is. Amíg friss/jól ismert

H.Z. v2 · 2012. Már. 21. (Sze), 16.42
Is. Amíg friss/jól ismert kódot piszkálgatsz, addig meg is tudom érteni, hogy zavarnak a kommentek. Ez az auto... egy egész jó dolognak tűnik – sajnos vim-ben még nem találkoztam vele, a többi, kipróbált fejlesztőeszközzel meg nem ismerkedtem össze ennyire. (eclipse-nek valószínűleg van ilyenje, de még nem láttam)

Egyébként ma megint előszedtem a könyvet és felfedeztem, hogy pont az a példa, ami úgymond kiverte a biztosítékot, folytatódott kicsit lejjebb és nem úgy lett "kiherélve", ahogy én a fölötte lévő szöveg alapján gondoltam: a Kiskapu-féle (szóval a magyar) változatban a 77. oldalon a 4.4-es ábrán van két komment, vastagon szedve. Az egyik valami olyan, hogy "semmi gond, valaki leállította".
Ezt speciel lényeges infónak tartom, de alatta a "tartózkodjunk az ilyen kirohanásoktól!"-t úgy éreztem, erre is vonatkozik.

Újra megnézve észrevettem, hogy alatta, a javított változatban, ezt a megjegyzést mégis megtartották, csak már nem volt vastagítva.
Más kérdés, hogy tiszta kód címén egy try-catch blokkot átpakolt önálló függvénybe/metódusba, ami egy ritkán lefutó kód esetén nem gond, de ha lényeges a performancia, akkor háromszor meggondolnám, akarok-e még a hibakezelés köré egy újabb réteget pakolni...
19

eclipse-nek valószínűleg van

Karvaly84 · 2012. Már. 21. (Sze), 18.20
eclipse-nek valószínűleg van ilyenje, de még nem láttam

klikk a szerkesztő baloldalára a sorszámoknál, és a helyi menüben ott a folding.

Egyébként én komplett example-t is szoktam kommentbe írni html tag-ekkel :D
23

GeSHi

T.G · 2012. Már. 21. (Sze), 22.38
Jaj, ugye ezt csak átvitt értelemben érted? Mármint a forráskódba ugye nem írsz mintakódot HTML formázással?
Ennél rosszabbat nehéz elképzelni, alapvetően a forráskódot nézi az ember, ha pont ott lesz olvashatatlan a minta, akkor az igen komoly probléma.

Én erre a GeSHi kódszínezőt használom, először legyártom a dokumentumot, majd az így legyártott fájlokban kicserélem a mintakódot:

<?php
include_once 'geshi/geshi.php';
foreach (glob('../output/*.html') as $filename) {
    $content = file_get_contents($filename);
    preg_match_all('|<source>(.*)</source>|isU', $content, $matches);
    if (count($matches[1])) {
        foreach ($matches[1] as $source) {
            $geshi = new GeSHi(trim($source), 'javascript');
            $content = str_replace('<source>'.$source.'</source>', $geshi->parse_code(), $content);
        }
        file_put_contents($filename, $content);
    }
}
1. a forráskódban teljesen olvasható a kód
2. a dokumentációban színes a kód
24

most itt ne arra gondolj,

Karvaly84 · 2012. Már. 22. (Cs), 00.21
most itt ne arra gondolj, hogy egy komplett weboldalt írok le a kommentbe, csupán arról van szó, hogy linket, felsorolást, forráskódot a megfelelő html tag-ekkel emelem ki, igy az eclipse beépitett dokumentáció megjelenítője, illetve a dokumentáció generátorok szebb dokomentációt jelenítenek meg.
20

vim

solkprog · 2012. Már. 21. (Sze), 19.59
Ezekkel a beállításokkal lehet a vim-ben nyitni-csukni a megjegyzéseket. 
:set fdc=1
:set fdm=indent
:set fdl=10
22

Köszi.

H.Z. v2 · 2012. Már. 21. (Sze), 20.42
Köszi.
25

Ne keressünk ott hibát, ahol nincs! :)

T.G · 2012. Már. 22. (Cs), 08.25
Én is kikerestem az adott példát, az előtte lévő oldalt is olvassuk el!
A 4.4 példa első megjegyzés helyénvalónak tűnik, hiszen megmagyarázza, hogy miért nincs szükségünk a cacth blokkra. A második megjegyzés azonban nem más, min zaj.


Tehát a kirohanás jelző az a második kommentre vonatkozik, mert valóban az.
26

Nem kerestem! :-P Ha keresem,

H.Z. v2 · 2012. Már. 22. (Cs), 09.08
Nem kerestem! :-P
Ha keresem, akkor talán alaposabban megnézem a mögötte lévő kódot is.
Ettől függetlenül, nekem jobban tetszik az a variáció, amikor sok a comment, de eltüntethető, bár olyat eddig sem a netbeansben, sem az eclipse-ben nem találtam, ami kizárólag a kommenteket húzta volna össze, a többi kódot meg békén hagyta volna.
27

Eclipse-ben Java esetén:

Karvaly84 · 2012. Már. 22. (Cs), 09.41
Eclipse-ben Java esetén: Window/Preferences/Java/Editor/Folding és itt az engedélyezés után be lehet állítani azokat az elemeket amiket alapból be akarsz csukni, köztük van a comments is.
28

Most nincs kéznél, de ha a

H.Z. v2 · 2012. Már. 22. (Cs), 10.59
Most nincs kéznél, de ha a linuxos változatban is így van (és miért ne lenne), akkor valamit nagyon csúnyán "benéztem", mert nem találtam meg. Windows-ost nem néztem egyáltalán.
Tankjú!
10

Hanem?

T.G · 2012. Már. 20. (K), 08.46
Melyik része az, amelyikkel nem értesz egyet? A Refaktoring könyv elolvasása után átnéztem a kommentjeimet és meg kellett állapítanom, hogy sokszor, mintha hülyéknek magyaráznám, hosszan leírom, hogy mit csinálok. Azóta inkább jobban figyelek a függvény és változónevekre.
Több gondolkodást igényel egy jó elnevezés, mint rizsázni arról, hogy miért is, ám végeredmény szempontjából sokkal olvashatóbb a kód, ha jó az elnevezés. Ám ha jó az elnevezés, akkor meg felesleges leírni a kommentben még egyszer ugyanazt.
11

Nekem a kommentekről szóló

pacsee · 2012. Már. 20. (K), 11.29
Nekem a kommentekről szóló rész azért tetszett különösen, mert ha belegondolok, bármilyen jó is egy komment, azt a függvény neve alapján meg kell keresni, el kell olvasni. Persze vannak IDE-k, amelyek kattintás nélkül megjelenítik, de egy jó, és beszédes függvénynév elegendő lehet, időt spórol. Persze nem árt - ahogy a könyv is írja - hogy ez a szép nevű függvény pontosan azt csinálja amire a neve utal.
Mindamellett az olyan függvények, amelyeket direkt más fejlesztők felé készülnek (pl api), azon függvényeket azért nem árt magyarázni.
12

Részben azért, mert a

H.Z. v2 · 2012. Már. 20. (K), 12.26
Részben azért, mert a pythonnal ismerkedve fedeztem fel, hogy a beépített help rendszer épít ezekre a kommentekre. Elég kellemetlen érzés, mikor egy ismeretlen kódot nézegetve csak reménykedhetek, hogy a változót azért hívják date-nek, mert dátumot tartalmaz és ennek nincs több jelentősége.
Részben azért, mert anno én még úgy tanultam, hogy minél több kommenttel lássam el a kódomat, mert öt év múlva nem biztos, hogy emlékezni fogok rá, miért is lett x változó azért x, mert... vagy azért mert ... vagy egyéb okból.

Ráadásképp úgy tűnt a mellékelt példákból, hogy úgy általánosságban szereti a szerző a kommenteket hanyagolni, mondván: épp elég beszédesek a változók, függvények, metódusok, osztályok nevei...
13

JavaDoc

T.G · 2012. Már. 20. (K), 13.01
Nem ismerem a python dokumentációs kommentjeit, de gyanítom hasonló elv mentén készülnek, mint Javaban. A JavaDoc használatát preferálja a könyv. De ugye script nyelveknél ezek a kommentek sokkal hasznosabbak, mert típust rendelhetünk változóhoz. Elolvasva a könyvet én nem éreztem, hogy ezek ellent szólt volna.
A felesleges kommenteket tartja rossznak a szerző, majd felhívja a figyelmet arra, hogy sokkal több komment felesleges, mint azt elsőre gondolnánk. Ám vannak jó megjegyzések is. :)
14

+1

inf · 2012. Már. 21. (Sze), 03.55
+1
21

Offtopic :-)

H.Z. v2 · 2012. Már. 21. (Sze), 20.37
http://www.youtube.com/watch?v=taMpEsqOIOs&feature=related
Déry János és Antal Imre vitatkoznak. Valahogy a Tiszta Kód jutott eszembe róluk. :)