ugrás a tartalomhoz

Refactoring módszertan

szabogabor · 2011. Feb. 8. (K), 12.25
Feltételes kifejezések egyszerűsítése a refactoring módszereivel
 ■
1

Néhány észrevétel, nevezzük

szabo.b.gabor · 2011. Feb. 8. (K), 13.42
Néhány észrevétel, nevezzük építő jellegű kritikának.

-a kiindulási kódodban kétszer meghívod ugyanazt a függvényt, majd rájössz, hogy ez nem jó, ezért az eredményt eltárolod egy változóba, majd a kiinduló függvényed köré raksz egy osztályt, és ugyanúgy meghívod kétszer, ráadásul egy bool visszatérési értékre készítesz két hívási lehetőséget, amik egymás ellentettjei..

aludj rá egyet, szerintem ez így nagyon nem kerek..

-figyelembevéve hogy a php hogyan értékeli ki az integer értékeket logikai kontextusban, semmi baj nem volt a legelső megoldásoddal

if( task::getNumberOfOpenTask()) {
	//van nyitott feladat
}else{
	//nincs nyitott feladat
}
kb ennyi épp elég is lett volna..

de ha mindenképpen logikai értéket visszaadó függvényt szeretnél, akkor is inkább egy 

task::hasOpenTask()
volna a megoldás jelen esetben.. szerintem jobban illik az elnevezés arra amit csinálni szeretnél..
4

Feltételes kifejezések egyszerűsítése

szabogabor · 2011. Feb. 9. (Sze), 01.08
Nem állítom, hogy ez a legjobb példa, de azt gondolom megfelelő arra, hogy bemutassam ezt a technikát.

Szerintem beszédesebb egy avatatlan szem számára - aki először olvassa a kódot -, a task::isOpenTask(), valamint a task::isNotOpenTask() hívás.

Talán könnyebben is megérthető - ha éppen azt vizsgáljuk, ha nincs feladat -, mint például az alábbi megoldás:

if( !task::getNumberOfOpenTask() ) {
  ...
}
(A task::hasOpenTask() ugyanakkor valóban jobb elnevezés lehet.)
5

Avatatlan szem

Joó Ádám · 2011. Feb. 9. (Sze), 15.29
Az, aki átsiklik egy negálás felett annyira avatatlan, hogy leginkább egyáltalán ne olvasson kódot, pláne ne nyúljon hozzá. Ha pedig nem tartod jól olvashatónak a felkiáltójelet (én sem tartom annak), akkor használj egy beszédesebb nyelvet.
6

Ne reagáld túl. Nem a

Török Gábor · 2011. Feb. 9. (Sze), 16.30
Ne reagáld túl. Nem a felkiáltójelen volt a hangsúly, hanem a !task::getNumberOfOpenTask() értelmezésén („ha nincsen feladatok száma” (?)). Ami valóban nehezebb, lévén ezt mindenki helyből task::getNumberOfOpenTask() == 0 formában írná, és máris minden tiszta.
10

De megállapodhatunk abban,

Joó Ádám · 2011. Feb. 11. (P), 21.01
De megállapodhatunk abban, hogy mindenféleképpen túl van reagálva a dolog ezzel a dedikált függvénnyel :)
2

Hát nekem van néhány gondom

neogee · 2011. Feb. 8. (K), 20.31
Hát nekem van néhány gondom ezzel amit bemutatsz az írásodban.
1: minden függvényre pontosan dupla annyi kód.
2: nekem speciel olvashatóbb a függvény negált vizsgálata, mivel így pontosan tudom, hogy ugyanazt csinálja az adott függvény mint 23 sorral előtte, és nem keveredek bele, hogy akkor most melyiket is hívjam meg ahhoz hogy a megfelelő értéket kapjam?...
3: ha minden feltétel elé teszel egy 3 vagy 4 szavas magyarázatot, az többet mond mindenféle feltétel átszervezésnél. Főként arra tekintettel, hogy ügye dokumentálni úgyis kell!!
4: ha egy függvényt kétszázhetvenhatszor kell egy kódrészletben meghívni mondjuk 10 soronként, az a kód egyrészt nem teljesen átgondolt, másrészt ha nem megoldható másképpen, akkor a rengeteg függvényhívást célszerűbb egyre csökkenteni, és változóba menteni az értéket, ahogyan te is tetted. És ahogy az előttem szóló is mondta: itt meg is lehet állni. Az általad bemutatott módszerrel főként az a bajom, hogy speciel ha ez a task::getNumberOfOpenTask() függvény egy combosabb adatbázis táblában keres táblában keres akkor eléggé vissza fog esni a teljesítmény ha sokszor hívkodjuk össze vissza, lehet mögötte bármilyen kód refactoring.

Ráadásul szerintem ez szintaktikailag is hibás:
if( !( 0 < $numberOfOpenTask ) { ... }
3

Kinek a pap

szabogabor · 2011. Feb. 9. (Sze), 01.02
A hivatkozott kódrészlet valóban hibás, javítottam, köszönöm az észrevételt.

1: Nem szükséges minden egyes feltételes változatnak megcsinálni a negált változatát. A példa azt mutatja be, hogy ezt hogyan tudnád megtenni.

3: A komment elhelyezése valóban segíthet a megértésben, de pont az lenne a cél, hogy a kód maga írja le a működését, és ne kelljen kommentezni. (Ráadásul minden ugyanolyan feltételvizsgálat előtt el kellene helyezni ugyanazt a kommentet.)

Ezzel a megoldással ezt el tudod kerülni.

4: Maximálisan igazad van abban, hogy egy nagy erőforrásigényű hívás esetén ez nem teljes értékű megoldás - de nem is ez volt a célja. (Mindenesetre ki fogom egészíteni a cikket.)
7

Igazad lehet. Viszont

neogee · 2011. Feb. 9. (Sze), 20.26
Igazad lehet. Viszont szerintem egy új ember először nem a kódot látja, hanem a dokumentációt. Aminek egy része a kód kommentjeiből készül automatikusan. Véleményem szerint ez a legjobb dokumentációs lehetőség. :) A forrás is beszédes, illetve generálni is tudsz olyan nyomtatható dokumentációt, aminek a segítségével könnyen és gyorsan feltérképezhető a rendszer működése. Valamint egy-egy metódus logikáját nem feltétlenül kódból kell elolvasni, megvannak erre a megfelelő ábrák és módszerek, amelyekkel maradéktalanul leírható a belső működés.
8

Oké, de a kód dokumentálása

Török Gábor · 2011. Feb. 9. (Sze), 22.02
Oké, de a kód dokumentálása pont ne azt jelentse, hogy minden elágazásnál dokumentálnod kell, hogy mit csinálsz. Az belső kód komment, ami alapjában véve nem is a mitre, hanem a miértre kell, hogy választ adjon bonyolult vagy nem triviális lépések esetén. Amire te gondoltál az a metódus, osztály vagy modul szintű dokumentációból generált referencia. A kód dokumentálja saját magát a lehető legjobban.
9

Igen ez abszolút így van. De

neogee · 2011. Feb. 9. (Sze), 22.13
Igen ez abszolút így van. De ettől függetlenül nekem az emberi nyelven leírt néhány szavas dolgok a feltétel előtt teljesen szimpatikusak és érthetőek. Igazából a feltétel érthetősége szerintem nem elsősorban azon múlik, hogy hány függvény van egy adott eldöntésre, vagy hogy logikai vagy szám értékkel tér e vissza az a függvény. Sőt a példában mutatott módszerek egy része engem csak még jobban összezavarna. Nekem ez nem szimpatikus csak. Alapvetően persze a feltételeket célszerű minél beszédesebbre írni, ezzel én is egyetértek, de úgy vélem hogy a cikk meg már átesik a ló túloldalára. Túl sokat akar fogni, aztán csak bizonyos szempontból még rosszabbá teszi a helyzetet.

Egyébként nem csak az osztályleírásokból generált referenciákra gondoltam, hanem például egy egyszerű folyamatábrára is akár, ami egy-egy függvény belső működését írja le.