ugrás a tartalomhoz

Egységtesztelés és függvény hossz kapcsolata

inf · 2011. Feb. 13. (V), 15.35

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.

 
1

Nagyon fontos azonban az

Joó Ádám · 2011. Feb. 13. (V), 16.51
Nagyon fontos azonban az arany középút, mindig a feladat szerint kell mérlegelni. Ha túl nagy a felelősség köre az adott egységben, akkor nehéz felügyelni, azonban a ló másik oldalán a túl egyszerű egység túlontúl transzparenssé és dependenssé válhat, amivel a célját veszti el, és épp ezért megintcsak nehezen kezelhetővé válik.

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).
5

Nagyon fontos azonban az

inf · 2011. Feb. 15. (K), 18.11
Nagyon fontos azonban az arany középút, mindig a feladat szerint kell mérlegelni. Ha túl nagy a felelősség köre az adott egységben, akkor nehéz felügyelni, azonban a ló másik oldalán a túl egyszerű egység túlontúl transzparenssé és dependenssé válhat, amivel a célját veszti el, és épp ezért megintcsak nehezen kezelhetővé válik.


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.
7

Jó megközelítés, ezek de

Joó Ádám · 2011. Feb. 15. (K), 19.49
Jó megközelítés, ezek de nagyon kreatív fejlesztők dolgoznak ebben a szakmában ;)
2

Rétegzés

janoszen · 2011. Feb. 13. (V), 20.09
Egyfelől hallottam már rendszergazdákat rászólni a programozókra, hogy legyenek kedvesek ennél több absztrakciós réteget nem építeni, mert nem fogják bírni a vasak. A másik oldalról meg kérdés, hogy mely ponton jön el az, hogy építeni kell valami specializált megoldást, mert drágább a vas, mint a fejlesztő. (Egy szerver havi díja kb. 30-50e Ft, ezzel lehet számolni.)

É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.
4

Hát metrikával nem

inf · 2011. Feb. 15. (K), 18.04
Hát metrikával nem foglalkoztam még eddig. Azt hittem, az valahogy külön létezik, mmint az Ant-ot megnéztem, és az egy deploy kezelő. De végülis logikus, hogy ha már megy a deploy, akkor közben adatokat gyűjtünk.

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.
8

egy programozó napi díja 40K

Crystal · 2011. Feb. 15. (K), 20.44
egy programozó napi díja 40K felett van


ez hogy jött ki?
9

Sehogy, van ismerősöm, akinek

inf · 2011. Feb. 15. (K), 21.13
Sehogy, van ismerősöm, akinek van egy kisebb cége. Ő 40-140 fizet napi díjat alvállalkozóknak. Valamekkora árrést nyilván ő is rátesz, de azt mondja alacsonnyal dolgozik, meg hogy a legtöbb cég rabló ilyen szempontból.
10

hat ha teljes berkoltseget

Tyrael · 2011. Feb. 15. (K), 21.56
hat ha teljes berkoltseget nezunk, akkor akorul van.

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
14

+1

janoszen · 2011. Feb. 16. (Sze), 21.36
Tényleg annyi. Az a baj a magyar piaccal, hogy mindenki a zsebbe árakon számol, így aztán nagy a meglepetés, amikor valaki rendesen adózik, de ebbe ne (itt) menjünk bele, az másik téma.
3

Szemantika

Crystal · 2011. Feb. 13. (V), 23.11
Szerintem arra kell figyelni, hogy minden programegység "egy egységnyi" munkát végezzen, egy atominak tekinthető dologért feleljen; nem pedig arra, hogy hány sort írunk egybe. Aztán ha ezt normálisan csináljuk, akkor valószínűleg 10-30 soros metódusaink lesznek általában.

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)
6

Most csinálok egy apróbb php

inf · 2011. Feb. 15. (K), 18.15
Most csinálok egy apróbb php projektet, 1÷20 sor ami nálam kijött, és nem voltak problémáim a névadással.
Az optimalizálás az más kérdés, ott valóban lehetnek hosszabb metódusok is.
11

...

carstepPCE · 2011. Feb. 16. (Sze), 09.05
Szerintem nagyon függ attól is, hogy ki mennyire olvashatóan írja meg a kódját, én rengeteg üres sort is hagyok benne. Ettől átláthatóbbá válik a kódom. Másik szempont, ha egy összetettebb SQL utasítás is bekerül a kerékvágásba, vagy csak rengeteg oszlopot kell lekérdezni, nehezen tartható a 20 soros függvényhossz. Bár azt kell mondjam átlagban nagyjából ki is jön a 20 soros hossz. De mivel on demand refaktorálok, ezért ha egy kódrészletet nem használok többet, akkor nem feltétlen pakolom ki külön függvénybe, talán csak ha javítja az adott függvény olvashatóságát és nagy a függetlensége és segíti az egységtesztelést.

Üdv
Sanyi
12

Nem hiszem hogy a sok üres

Crystal · 2011. Feb. 16. (Sze), 12.47
Nem hiszem hogy a sok üres sor átláthatóbbá tenné a kódot, így kevesebb kód fér el egyszerre a képernyőn ami nem jó. Én nagyon keveset szoktam betenni. Persze kinek mi :)
13

...

carstepPCE · 2011. Feb. 16. (Sze), 14.39
Nekem szempont az ures sor ( az ures sorokat inkabb a vezerlo szerkezetek kornyeken szoktam beiktatni ), hogy bizonyos dolgokra jobban tudjak koncentralni. Abban igazad van, hogy kevesebb sor fer ki a kepernyore, de az kevesbe szokott zavarni, hiszen 60 sor azert kifer a kepernyore mindig :)
15

Metrika

janoszen · 2011. Feb. 16. (Sze), 21.38
Na, elvileg pont itt segít a metrika, mert az üres sorok legjobb tudomásom szerint nem számítanak bele a LOCba. Tudom ajánlani a PHP Mess Detector nevű cuccot, nagyon hasznos és lényegre törő reportokat ad.
16

Szia! "Persze mindenki

virág · 2011. Feb. 28. (H), 00.48
Szia!

"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 :)
17

Nem mondtam, hogy ez az

inf · 2011. Feb. 28. (H), 07.22
Nem mondtam, hogy ez az ideális hossz nem lehet szubjektív, többféle logika szerint is fel lehet osztani egységekre egy nagyobb kódrészt, ill. mindenkinek más a felfogó képessége, szóval van aki nagyobb egységeket is könnyebben felfog, van aki kevésbé. Én a széttagolt kódot jobban szeretem, mert könnyebb refaktorálni, és dokumentáció nélkül átlátni, hogy mi mit csinál benne.

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.
18

Érdekes amit írtok, és pont

deejayy · 2011. Júl. 1. (P), 20.31
Érdekes amit írtok, és pont bele is futottam néhány órája.

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.