Wymowne nazwy metod i kontekst.

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

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:

// 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?

Testy Alibi

Spotkalem sie dzisiaj z nowym rodzajem testow. Tak mi sie on spodobal, ze zechcialem wspomniec o nim na blogu. Chodzi o Testy Alibi. Moja definicja tego pojecia jest nastepujaca:

Testy Alibi - to takie testy, ktorych glownym celem jest istnienie samo w sobie.

Jesli ktos pyta czy do danego kodu napisane sa testy to w przypadku testow alibi mozna odpowiedziec, ze oczywiscie tak. Najlepiej odpowiedziec na tyle stanowczo zeby nie otrzymac kolejnego pytania na ich temat.

S.O.L.I.D i refaktoring

Wszystkim zainteresowanym tematem polecam mocno wg mnie dobre darmowe e-booki traktujace temat SOLIDnego projektowania i refaktoryzacji.

Po co nam te javadocki, komantarze, etc...

Grzebiac w kodzie znalazlem kilka metod opatrzonych takim oto komentarzem:

"Life is too short..."

Autor mial zapewne wazniejsze rzeczy do robienia podczas pisania kodu i niepisania javadoca. Ocenil sytuacje i stwierdzil, ze szkoda jego cennego czasu, jego zycia na takie pierdoly. Po jakims czasie ja trafiam na to miejsce starajac sie zrozumiec jak cos dziala. Co z moim czasem, z moim zyciem? Patrzac z szerszej perspektywy, ktos bedzie musial za to zaplacic i z pewnoscia nie autor, ktory zaoszczedzil swoj czas.
Podumowujac:
Kod wiecej razy czytamy niz piszemy. Dlatego tak wazne jest zeby juz napisany byl czytelny i zrozumialy. Wszystkim piszacym kod polecam ksiazke "Clean Code" by Robert C. Martin (Uncle Bob).

Mylyn i code review

Generalnie jestem zwolennikiem tekiego code review gdzie nie ma wyznaczonego jednego guru, ktory to robi. Ludzie w projekcie sprawdzaja nawzajem swoj kod. Guru patrzy na wazniejsze kawalki. Zalozmy jednak, ze ty - guru yoda - jestes namaszcony zeby robic co jakis czas review swiezego kodu. Pisze go 10 koderow. Jak w prosty sposob przekazac tym koderom swoje uwagi i nie namacic w kodzie? Jak wskazac im te miejsca, ktore trzeba przepisac. Moze Excel ;P moze wstaei komentarze do kodu..
Tu z pomoca przchodzi znowu Mylyn! Oto super prosty i skuteczny, sprawadzony przez wielu przepis, a juz jak grupa jest rozproszona to nie ma lepszego...
Otoz kazde review traktujesz jako odrebne zadanie mylyna. Aktywujesz zadanie, przegladasz kod napisany przez Martina, a mylyn tworzy kontekst. Zeby nie smiecic w kodzie zbedynmi komentarzamie dodajesz bookmarki. Na koncu zapisujesz nowe zadanie jak np. bug przydzielasz Martinowi i dodajesz do niego utworzony przez mylyna kontekst. Martin przychodzi do pracy odpala swojego sexclipsa i widzi na swojej liscie nowe zadanie. Aktywuje je, otwiera mu sie kontekst i juz wie na co ma zwrocic uwage. Czyz to nie super narzedzie ten mylyn !!?