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?

Projekt - miejsce gdzie spedzasz wiekszosc dnia.

Bierzesz udzial w projekcie, w tworzeniu produktu (w moim przypadku jest to software). Narodzil sie on jakis czas temu, co kilka miesiecy ewoluuje o kolejne funkcjonalnosci. Cykl ewolucji powtarza sie z jednego wydania na drugie. W tym wszystkim obserwujesz przerozne formalizmy projektowe, ustawki, rozne formy wspolpracy, podkniecia, czkawki itd. Wszystko dziala w dosc sztywnej ramce, ktora potrzebuje z gory zdefiniwanych kosztow, terminow oddania, zakresu zmian, z gory okreslonego przadzialow prac dla osob w zespole, i calej masy innych z gory przewidzianych rzeczy. Ta ramke mozna co prawda usprawniac jednak wiaze sie to z praca w high tech czyli z ludzmi!
A gdyby tak zamiast myslec o kosztach pomyslec o ciaglych inwestacjach (brzmi troche inaczej)
Zamiast wersji i realeas'ow zalozyc ze produkt niegdy nie bedzie zakonczony za to ciagle rozwijany, ulepszany, malymi kroczkami.
Zamiast z gory okreslonego zakresu bedzie swiadome i ciagle odkrywanie nowych wartosci o jakie mozna go wybogacic, wsparte uczeniem sie w trakcie i umiejetnoscia obchodzenia sie z tym co jeszcze nieznane.
Zamiast zarzadzania zasobami (czyt. ludzmi) starac sie utrzymac balans miedzy tym co powinno zostac dostarczona, a tym ile jestesmy w stanie wytworzyc...

Ta, akurat, pitu pitu bedzie wiosna... juz to widze, ze to moze tak dzialac.

No i tu mozna przypomniec to co Jeff De luca powiedzial:

"I’m saying that
the Agile methods are more suited to types of people
and organisational cultures than types of project.”