Egységtesztelés és függvény hossz kapcsolata
Sok könyben olvastam már, hogy 10-20-50 sor az ideális függvény/metódus hossz, és hogy egy osztályban 8-10-15 metódusnál ne legyen több. Persze mindenki kicsit mást ír, de a lényeg ugyanaz, van egy ideális függvény/metódus hossz és osztály méret.
Gondolkodtam kicsit azon, hogy vajon miért?
Elsőnek az jutott eszembe, hogy mindez az átláthatóság miatt szükséges. Ha kisebbek a metódusok, és az osztályok, és mindnek beszélő neve van, akkor ránézésre lehet érteni, hogy mit csinál a kód, viszont szerintem ezzel túlzásba is lehet esni, ha túlságosan széttagoljuk a kódot, ezért van egy ideális hossz. Nekem őszintén szólva egy idő után problémát okoz, hogy 10 soronként értelmes címet adjak a metódusaimnak, de lehet, hogy egy idő után belejön ebbe az ember, nem tartok vissza senkit ilyesmitől. :-)
Kicsit jobban átgondolva a témát bejön a képbe az egységtesztelés.
Ha megnézzük az egységtesztelést, mint szót, megtaláljuk a megoldást a kérdésre. Az egységteszteléshez szükség van egységekre. Minél nagyobbak ezek az egységek, annál több feladatot látnak el, annál komplexebb a kimenetük, és annál nehezebb teszteket írni rájuk. Ezért van szükség kis egységekre, melyekre nagyon egyszerűen tudunk teszteket írni. Szóval fejlesztési szempontból sokkal előnyösebbek az apróbb függvények/metódusok, mint a hosszabbak, mert könnyebb rájuk teszteket írni, és könnyebb megtalálni bennük a hibákat, mert kisebb kódrészt kell egyszerre megírni, majd hiba keresésénél áttekinteni.
■
Nagyon fontos azonban az
Ami a konkrét számokat illeti, minden absztrakciós szinten érdemes megcélozni a hetes számot – ki tudja miért, de az emberi tudat úgy lett megszerkesztve, hogy körülbelül ekkora elemszámmal tud a leghatékonyabban dolgozni (de felmerült, hogy ez még ennél is kevesebb).
Nagyon fontos azonban az
Nehezen tudom elképzelni ezt a ló másik oldalát, tudnál példát mondani rá?
Amikor kiemelsz egy részt egy nagyobb függvényből, akkor annak nevet is kell adni. Ha az adott rész egy feladat elvégzéséért felel, akkor egyszerű nevet adni neki. Ha túlságosan széttagolsz valamit, akkor a nagyon apró részeknek szerintem egyre bonyolultabb lesz értelmes nevet adni. Szóval a névadás nehézsége az, ami ellensúlyozza ezt az elaprózódást.
Jó megközelítés, ezek de
Rétegzés
Én írtam egy Antos build.xml-t, ami mindenféle metrika eszközöket futtat, ezekkel érdemes megismerkedni, ha érdekel a téma. A script egyébként BSD licenszes és Windows alatt is működik, használd egészséggel.
Ami a komolyan vevést illeti, valószínűleg nem azonnal, de megtérül, ha figyelsz ezen eszközök kimenetében okádott hibákra. Vannak extrém esetek, ahol nem jönnek be, pl. néhány soros függvények egy toolkit osztályban, de az nagyon extrém metrika számokat érdemes megnézni közelebbről.
Erről a témáról egyébként Tyrael mester tartott előadást PHP alkalmazások minőségbiztosítása címen.
Hát metrikával nem
Amúgy nem kifejezetten php-ra gondoltam, sőt eddig csak olyan refaktorálásos könyveket olvastam, amikben java példák voltak.
Nincs nagy tapasztalatom az absztrakciós rétegek halmozásával kapcsolatban, de úgy hallottam, hogy a vas mindig olcsóbb, mint a fejlesztő. Ha belegondolsz, akkor egy programozó napi díja 40K felett van, szóval egy nap alatt megy rá minimum annyi kiadás, mint egy szerverre egy hónapban.
egy programozó napi díja 40K
ez hogy jött ki?
Sehogy, van ismerősöm, akinek
hat ha teljes berkoltseget
2010ben 550k brutto az 295k netto, ami 707k teljes berkoltseg.
ebbol 20 napot dolgozik az emberke, ergo a napi atlagbere 35350(ebbol meg ugye le lehetne szamolni a szabit, ami eves szinten egy teljes honap).
ha mindebbe belekalkulalod, hogy a cegnek is kell nemi haszon, illetve nem mindig egyenletesen van munka, akkor szerintem alvallalkozokent a napi 40k brutto az nem pofatlanul sok.
persze 1 szemelyes cegnel nem fogod magad utan a teljes munkabert fizetni, de egy nagyobb konzulens cegnel, ahol tobb alkalmazott van (bar ott is elegge sokan csinaljak azt, hogy a dolgozok is alvallalkozok) ott mar igen.
ja, es termeszetesen a mostani szja valtozasok kedvezoen hatnak a magasabb bersavban, ergo lehet hogy lejebb mennek az oradijak is.
Tyrael
+1
Szemantika
Ez alól persze lehetnek kivételek, pl. ha valaminek nagyon gyorsnak kell lenni akkor lehet hogy érdemes spórolni kicsit a függvényhívásokkal és 50-60 sort egybe írni (jöhet a "maintainability above performance", kövezzetek meg :P)
Most csinálok egy apróbb php
Az optimalizálás az más kérdés, ott valóban lehetnek hosszabb metódusok is.
...
Üdv
Sanyi
Nem hiszem hogy a sok üres
...
Metrika
Szia! "Persze mindenki
"Persze mindenki kicsit mást ír, de a lényeg ugyanaz, van egy ideális függvény/metódus hossz és osztály méret."
Én ezzel nem értek egyet, szerintem ilyen nem létezik, lehet mondani, hogy van, és hinni is lehet benne, de a valóság szerintem az, hogy nincs ilyen. Szubjektíven, egyedileg neked és nekem létezhet, de másoknak ez lehet túl kevés, vagy túl hosszú. Az egységtesztelés valóban nyomós érv a szépen tagolt és átgondolt, rövidebb egységek mellett, de nem hiszem, hogy ez mérvadó lenne.
"Ha megnézzük az egységtesztelést, mint szót, megtaláljuk a megoldást a kérdésre. Az egységteszteléshez szükség van egységekre."
Bocsánat, de szerintem ez kicsit olyan mondvacsinált dolog :) erőltetett és olyan mintha rájönnél arra, hogy azért terem a cseresznyefa cseresznyét, mert van a spájzban 200 grammos cseresznyebefőtt, vagy valami hasonló :) Egyébként egyetértek veled abban, hogy jó dolog apróbb egységeket készíteni, de nem értek egyet abban, hogy ez általános érvényű lenne, az optimális méretet pedig képtelen vagyok meghatározni, de ez legyen az én hibám :)
Nem mondtam, hogy ez az
Valóban egy kicsit mondvacsináltra sikerült. Azt szerettem volna megfogalmazni, hogy az egységtesztelés használata egy hajtóerő afelé, hogy kisebb egységekre osszuk fel a programunkat, ugyanis a kisebb egységeket könnyebb tesztelni, mint a nagyobbakat.
Érdekes amit írtok, és pont
Egy egyszerű keretrendszert dobok éppen össze, és egyébként ösztönösen rövidebb függvényeket írkálok, erre eddig nem is figyeltem, csak érzéssel.
Volt egy függvény, ami viszont több sor volt (ilyenkor általában üres sorokkal választom el a logikailag egybetartozó dolgokat), és pont egy hibát debuggoltam, ahol viszont sokkal jobb lett volna, ha ezek a részek külön függvényben vannak, mert akkor előbb megtalálom.
Így a blokkok közé szúrtam be a debug sorokat, és ki is jött a hiba, de külön függvényben rögtön láttam volna.