Celem tekstu, który tutaj tworzę jest wymuszenie bardziej refleksyjnego spojrzenia na rzeczy z pozoru oczywiste
Z pośród całej masy publikacji dotykającej tematyki programowania niewiele jest pozycji, które poruszają specyficzną tematykę tworzenia kodu "ogólnie". Co więcej masa książek noszących inicjały światowej sławy inżynierów prezentuje wręcz kod śmiało nadający się do kategorii "syf" a nie "arcydzieło". Jedna z lepszych pozycji, która nie wymiotuje na czytelnika pseudo przykładami to Czysty kod napisany przez pana mieniącego się : Robert C. Martin.
Jest to jedna z lepszych (jeśli nie najlepsza) pozycji stawiających sobie za cel znalezienie właściwej drogi do tworzenia czytelnego kodu, ale jednak czegoś w niej brakuje. Weźmy taki rozdział o optymalnej ilości parametrów przekazywanych do funkcji :
- 0 - super
- 1 - jeszcze ok
- 2 - zaczyna być groźne
- 3 - pachnie zjebatorstwem
- 4+ - niezbędny refaktoring
Niestety autor jedynie stwierdza, że za dużo argumentów funkcji jest po prostu nieczytelne i zadowala się tak płytką argumentacją.
Jest taka profesjonalna biznesowa technika wkurwiania ludzi nazywająca się "5 razy dlaczego" fachurkowo wymawiana przez ludzi piastujących stanowiska nazwane bynajmniej nie po polsku "fajw whais" (5_Whys).
Cała sztuczka polega na zadawaniu pytania "dlaczego" tyle razy aż dojdzie się do bazowej przyczyny problemu. Niestety większość argumentacji pojawiających się w wywodach odnośnie pisania czytelnego kodu byłoby rozerwanych przez tę technikę, bo jak mogłaby wygladać taka rozmowa:
- 3 argumenty funkcji to zdecydowana granica
- dlaczego ?
- bo później kod staje się nieczytelny
- dlaczego ?
- bo pojawia się za dużo kombinacji
- dlaczego fakt, że pojawia się za dużo kombinacji sprawia że trudniej czytać kod
- ...
I ch*j, tutaj już schodzimy na intuicję.W zakresie prasy IT nie znalazłem żadnej, choćby pseudonaukowej próby wytłumaczenia dlaczego 2 parametry mają być dobre a 3 lub 4 już nie.
Może Inżynierowie nie szukali odpowiedzi na to pytanie ale psychologowie znaleźli ja ponad 50 lat temu
"Magiczna liczba 7"
Własnie pół wieku temu przeprowadzono badania, które określiły granice ludzkiej pamięci (krótkotrwałej) i dały odpowiedź na to : ile koncepcji,idei czy obiektów istota ludzka jest w stanie przeanalizować w danej chwili.
Link do dokładnych badań :
http://www.musanim.com/miller1956/
Streszczenie w wikipedii : http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
Kto ma ochotę może zapoznać się szczegółowo z raportem a dla bardziej leniwych dwa wnioski podsumowania :
- Możemy w jednej chwili ogarnąć około 4-6 koncepcji.(liczba 7 jak się okazuje była zastosowana tylko z powodów marketingowych). Dlaczego tyle? Być może przez miliony lat ewolucji taka liczba była najwłaściwsza aby ogarnąć codzienność ówczesnego życia : Tygrys, Kobieta, Ogień , Jaskinia
- Pojęcie koncepcji :
-
funkcja(flaga1,flaga2,flaga 3)
- od razu zaznaczam, że jest to przykład maksymalnie zjebanego kodu. Funkcja przyjmuje trzy niezależne od siebie parametry, których kolejność interakcji może mieć znaczenie, więc mamy 2^3=8 możliwych interakcji co skutkuje wyjściem poza granicę buforu pamięci krótkotrwałej -
funkcja(imie,nazwisko,ileKasy)
- tutaj da się wyodrębnić dwie koncepcje : DaneNadawacy i KwotaPrzelewu, do tego mamy tylko jeden sposób interakcji , który docelowo można nazwać DaneDoPrzelewu
-
Patrząc na powyższe przykłady można zaryzykować twierdzenie, że pierwsza funkcja jest do wyjebania a drugą można poddać prostemu refaktoringowi.
Wnioski
Przykład był uproszczony to i wnioski wypływające z niego będą uproszczone : Trzy parametry w funkcji nie zawsze oznaczają totalnie zjebany kod ale ta liczba stanowi doskonały wyznacznik dla potencjalnego "smrodu" w kodzie . W firmie ustawiliśmy regułę statycznego sprawdzania kodu w Sonarze na maks 3 parametry w metodzie i jak na razie się to sprawdza. Jak dołożymy do tego masę innych praktyk, o których kiedyś wspomnę to rezultat faktyczny jest taki, że nawet dosyć rzadko pojawiają się w naszym kodzie funkcje z wspomnianymi 3 parametrami.
Ważne aby potencjalnemu czytelnikowi drzewa nie przesłoniły lasu. Parametry parametrami ale głównym zamysłem jaki chcę przekazać z tego artykułu jest zachęta do szukania głębszych wyjaśnień pewnych kwestii a nie zadowalanie się wytłumaczeniem "bo wydaje się to mieć sens"
Pod tym względem dobra jest książka "Effective Java", bo każdy koncept jest poparty wyjaśnieniem dlaczego jest warty uwagi, jakie ma zalety i wady, kiedy używać, a kiedy nie.
OdpowiedzUsuńIdźmy dalej tym tropem :) to dlaczego
OdpowiedzUsuńfunkcja 1 jest gorsza niż funkcja 2.
funkcja(flaga1,flaga2,flaga 3)
funkcja(imie,nazwisko,ileKasy)
Według mnie dlatego że jest bardziej czytelna.
W clean codzie podali kilka przykładów - i oparli wytłumaczenie na intuicji. Programista powinien po nazwie metody, klasy, parametru spodziewać się co zrobi metoda:
I tak metoda size() w ArrayList, która zwraca pierwszy element nie jest dobra- ale jeśli metoda zwraca rozmiar listy - to każdy tego się spodziewa tego.
Dlaczego 3 parametry to już jest źle:
Mnie przekonał eclipse:
tzn jak mi podpowiada ( a nie mam podpiętej dokumentacji ) to gdy piszę nazwe metody i naciskam [Enter] to widzę np:
String.valueOf(value) //podpowiedz jakiego typu jest value
Gdy metoda nie ma argumentów: nie muszę myśleć/pamiętać:
list.size() i wiem, intuicja mi podpowiada co mi da ta metoda.
1 parametr:
String.valueOf(boolean value) //intuicja podpowiada mi że jak dam tam boolean to otrzymam string - nie muszę jeszcze nic pamiętać.
2 paramerty:
Assert.assertEquals(expected, actual) - tutaj już zaczynają się schody, nie mogę bezmyślnie wpisać argumentów tej funkcji :) muszę pamiętać gdzie wpisać parametr expected i actual //ludzie często się mylą.
3 parametry:
Dobra kto pamięta bez zaglądania w dokumentacje
Assert.assertEquals(
który parametr to message ?
1, 2 czy 3 ?
A teraz wyobraźcie sobie, że piszecie w J2me i tam wszystkie argumenty nazywają się arg1 arg2 .... :)
Wtedy jest jazda i wiadomo dlaczego się nie lubi wieloparametrowych funkcji :) - za każdym razem do dokumentacji trzeba zaglądać :)