Metoda malych kroczkow wprowadzam do kodu, z ktorym na codzien pracuje pewne konwencje. Piszac testy staram sie nazwac metode testowa tak aby w pewien sposob oddala kontekst testu. Jednak na nic te konwencje jesli tylko ja bede ich uzywal. Wiec pokazalem jednemu koledze moj kod z takimi dlugasnymi nazwami metodami (okolo 100 znakow na nazwe) i poprosilem o komentarz. 100 znakow! WTF! No wybacz, sa taki jezyki (nie programowania), ktore potrzebuja duzo miejsca. Podobno jezyk finski przebija wszystkie.
zwracaTrueDlaProcesowZewnetrznychTechnicznieZwalidowanychWersjonowanieRozpoczete
No wiec pokazje koledze pierwsza motode.... a on czytajac ja w polowie dostal stackoverflow. Czyta drugi raz i znowu. Mowi do mnie, ze to nie przejdzie, ze to do dokumentacji, ze jak dla niego 3 wyrazy i basta. Na koniec podkreslil jeszcze dobitnie, ze to za duzo. Sie zdziwilem, ze tak od razu, ze sie nie reebotuje i nie walczy no ale coz. Dla mnie jego zdanie jest wazyne bo przeciez na jednym kodzie pracujemy. Staram sie jednak mu pomoc i go zachecic. Czytam mu nazwe metody i robie przerwy. On to zwuwazyl i mowi mi, ze z tymi przerwami juz kmini ale ich w nazwie nie widzi. No wiec edytuje kod:
zwracaTrue_DlaProcesowZewnetrznych_TechnicznieZwalidowanych_WersjonowanieRozpoczete
Kolega jeszcze sie krzywi, no jest lepiej ale. Pokazuje mu inna, stara nazwe metody testowej:
rodzajSourcinguZmieniony
// GIVEN
wstepny kontekst, setup, ustawienie stanu systemu
// WHEN
zdarzenie faktycznie testowane (np. wywolenia metody)
//THEN
sprawdzenie wynikow tesotwanej metody, asercja
i pytam czy ta nazwa mu cos mowi. Kolega zaczyna parsowac, glowi sie, patrzy w kod (zaslonilem mu na chwile ;)). No nic, z samej nazwy metody nic nie wyprodukuje, nie wie w ktorym kosciele dzwoni. Odslaniam kod testu. W sumie pogorszylo tylko sprawe :D
No ale nie cisne na sile. Skoro jemu trudno to odczytac i woli w dokumentacji to mu pokazuje dokumentacje klasy i szeroko opisan kontekst. Swieteni, robi sie jasniej. Zmarszczki na czole powoli sie prostuja ( mam nadzieje, ze pod czaszka nastepuje proces odwrotny). W powietrzu czuc porozumienie. No to ide za ciosem. Cialo metody:
No ale nie cisne na sile. Skoro jemu trudno to odczytac i woli w dokumentacji to mu pokazuje dokumentacje klasy i szeroko opisan kontekst. Swieteni, robi sie jasniej. Zmarszczki na czole powoli sie prostuja ( mam nadzieje, ze pod czaszka nastepuje proces odwrotny). W powietrzu czuc porozumienie. No to ide za ciosem. Cialo metody:
// GIVEN
wstepny kontekst, setup, ustawienie stanu systemu
// WHEN
zdarzenie faktycznie testowane (np. wywolenia metody)
//THEN
sprawdzenie wynikow tesotwanej metody, asercja
I tu pozytywna reakcja. Weszlo jak w maslo, sa pochwaly, jest dobrze. Rownoczesnie patrzymy na inne metody testowe napisane dawno temu. Czy ktos myslal kiedys o tym, ze inni beda je czytac szukajac powodu defektu? Czy ty myslisz o tym, piszac kod?
Bardzo fajny wpis. Pokazałeś, że nie tylko konwencje "kompilowalne" są ważne, ale też te, które kompilator olewa.
OdpowiedzUsuńO!!! Koziołek!!! :) W jls jest napisane:
OdpowiedzUsuń"An identifier is an unlimited-length sequence of Java letters and Java digits, the first of which must be a Java letter." Kusi mnie zeby ulozyc piekna, wymowna nazwe dla metody i to w jezyku niemieckim...
Popieram! Krok po kroku aczkolwiek konsekwentnie... Na szczęście w nowym kodzie częściej można spotkać nazwy, które coś znaczą. Świat nie popiera już bylejakości :)
OdpowiedzUsuńCiekawe jest to stwierdzenie, ze swiat juz bylejakosci nie popiera... Ostatnio ogladalem ciekawy film na temat jakosci: http://alterkino.org/spisek-zarowkowy-nieznana-historia-zaplanowanej-nieprzydatnosci
UsuńCiekawe jak sie to ma do planowania jakosci softu...
Bez sensu by było takie postępowanie ponieważ kod nie może się zużyć. Najlepszym dowodem jest tu COBOL. Soft jest migrowany tylko i wyłącznie ze względu na koszty suppportu i konieczność zatrudniania nekromantów by wskrzeszali programistów.
UsuńCzy ja wiem? Jakby trzeba bylo to ekonomiczne uzasadnienie by sie znalazlo. Kiedys pracowalem w firmie, ktora w umowie na soft miala zapisy o ilustam letniej gwarancji jego uzytecznosci (ze produkt bedzie rozwijany, supportowany, itd) przez np. 10 lat. Chodzilo o to, zeby inwestycja miala szanse sie zwrocic. A po 10 latach nowy soft.
UsuńTu nie o to chodzi. Takie umowy oznaczają, że będzie ktoś kto będzie dodawał do softu nowe funkcjonalności wraz z rozwojem biznesu. Po 10 latach nie będzie potrzeby przepisania softu, bo będzie działał poprawnie (tyle o ile, ale zawsze). Jedyną motywacją może być np. konieczność zmiany systemu operacyjnego czy sprzętu.
UsuńProponuję fiński zamiast niemieckiego. Niemiecki ludzie jeszcze znają.
OdpowiedzUsuńTak na bieżąco z kodu:)
[code]public interface DataArriveListener{
public void whenDataArrive(RequestResult result);
}[/code]
Hmm ciekawa nazwa... pierwsze co mi sie cisnie do lba to
UsuńzaGoramiZaLasami(Request cdn) :)
Idealnie oddaje sens działania tego interfejsu.
UsuńHuh, nie zmuszaj mnie do nauki finskiego.
OdpowiedzUsuńWygrzebalem, ze j. finski moze sie pochwalic najdluzszym palindromem na swiecie "saippuakivikauppias".
Najdluzsze finskie slowo: "lentokonesuihkuturbiinimoottoriapumekaanikkoaliupseerioppilas". Specjalnie wsadzile w cudzyslow. Smialo odpytaj google, zobaczysz co ci powie :D
Ciekawe jestem na wygladaja okienka aplikacji :) Ale jak wejdziecie na finska wiki to juz od pierwszego spojrzeniw w tekst widac ze cos jest na rzyczy...
Akurat fiński, no może poza wymową, nie jest aż tak trudny. Jeżeli niemiecki można traktować jako odnośnik dla języka "składanego z klocków", to fiński można by zapodać kompilatorowi i spoko by sobie poradził.
OdpowiedzUsuń