poniedziałek, 3 czerwca 2013

YAGNI + Test First

czy warto pisać testy przed implementacją?

Testowanie samo w sobie przynosi korzyści, zazwyczaj w dłuższej (oby:) perspektywie czasu, ale prędzej czy później jesteśmy w stanie dostrzec ich wartość i nieraz oddychamy z ulgą, gdy widzimy, że ludzie pracujący nad kodem przed nami, poświęcili trochę czasu na napisanie solidnych zestawów. Lecz o zaletach posiadania testów już pisałem ostatnio (tutaj i ciąg dalszy :).

I o ile z tym, że posiadanie testów przynosi korzyści i jest to jedna z tych rzeczy, którą wielu programistów chce praktykować nie kłóci się nikt, o tyle nie wszyscy widzą jakikolwiek sens w pisaniu testów przed implementacją. Że niby sprawia, że kod jest lepszy, że jeszcze raz myślimy o problemie, że patrzymy na niego od innej strony, itp., itd.
Problem z tymi wszystkimi stwierdzeniami jest taki, że to są jedynie oklepane zwroty, którymi karmią nas bardziej doświadczeni, mądrzejsi znawcy tematu, którzy powołują się na własne doświadczenie i którym powinniśmy zaufać. I ja wcale nie twierdzę, że nie mają racji, czy też nie neguję ich kompetencji, ale człowiek (a programista też człowiek :) woli uczyć się na własnych błędach. Przynajmniej do momentu, gdy nie zobaczy konkretnego przykładu, który pokazuje mu, że jednak jest tak, jak podpowiada starszy kolega.

wtorek, 21 maja 2013

Więcej nie znaczy wolniej cz.5 - testowanie po raz drugi

i jeszcze jeden i jeszcze raz...

Komentarze (krytyka :) pod wczorajszym wpisem zmotywowały mnie do powałkowania tematu testowania jeszcze przez moment.

Na wstępie jednak pragnę zaznaczyć, że i tym razem nie będzie ani jednej linijki kodu. Ta decyzja wynika bezpośrednio z tego, o czym wczoraj pisałem w komentarzu pod wpisem, a mianowicie z samego założenia dotyczącego serii - nie ma to być opis technik/procesów, czy też opis samej ich idei, chodzi mi raczej o przedstawienie argumentów, które mogą pomóc Wam (oczywiście jeżeli będziecie mieli na to ochotę) przekonać managera czy też właściciela produktu do zastosowania opisywanych aktywności w projekcie.

Muszę pokornie pochylić głowę i przyznać, że rzeczywiście we wczorajszym poście zabrakło przykładów z życia wziętych. Był zbiór uwag (swoją drogą całkiem słusznych :), które jednak poza opisem nie zawierał żadnych odniesień do rzeczywistości, w której przyszło nam się zmagać z klientami, managerami, czy też innymi opornymi przedstawicielami idei minimalizmu w odniesieniu do ilości procesów w trakcie tworzenia oprogramowania.

niedziela, 19 maja 2013

Więcej nie znaczy wolniej cz.4 - testowanie

no to co? może teścik?

A może jeszcze jeden? I kolejny? I jeszcze dziesięć następnych? I co?

No właśnie, i co? Obrońcy rzeczywistości, w której testów nie spotkasz nawet tam, gdzie mógłbyś (a wręcz chciałbyś) się ich spodziewać, nieustannie twierdzą, że z tą aktywnością nierozerwalnie wiążą się dwa podstawowe problemy:
  • Ilość kodu, który testujemy niekiedy jest dużo większy niż ilość kodu testowanego (czyt. a można by przecież napisać tyle więcej nowej funkcjonalności)
  • Testowanie nie daje gwarancji tego, że w produkcie nie ma bugów (czyt. jesteśmy tak pewni swojej aplikacji po je przetestowaniu, jak przed)

Oczywiście są to prawdy objawione, z którymi się nie da dyskutować.

Hmm... ale zawsze można spróbować :)

sobota, 11 maja 2013

Czy to już czas?

Jakiś czas temu, po długim ślęczeniu nad bugiem zgłoszonym przez klienta, gdy udało mi się w końcu odkryć źródło problemu i otworzyłem plik z klasą, której metoda była odpowiedzialna za całe wyrządzone zło, popatrzyłem na kod i przed oczami stanął mi obraz dżungli, pełnej pnączy, drzew, zwierząt, insektów i wszystkiego, co tam jeszcze w takich dżunglach się znajduje. Niby dżungla jedna, ale jak wejść do środka, szczególnie bez przygotowania i dość obszernej wiedzy, co w niej można znaleźć, to aż przebiega zimny dreszcz po plecach.

poniedziałek, 29 kwietnia 2013

Czy to już paranoja?

a zaczęło się to tak...

Wydajność mojego zespołu zwiększyła się w ostatnich miesiącach kilkukrotnie. Oczywiście jest to powód do zadowolenia, ale generuje to również wiele code review, które wcześniej czy później trzeba przejrzeć. Co prawda, nie wszyscy muszą oglądać wszystko, ale tak czy inaczej, ich ilość ostatnimi czasy jest przytłaczająca. Zazwyczaj rano przy kawie przeglądam ich listę i po kolei, jeden po drugim, zamykam bądź oglądam, w zależności od tego, ile osób przede mną już miało przyjemność patrzyć na ten kod. Tak też zrobiłem ostatnio. Gorąca, czarna, parzona i aromatyczna kawa powoli cuciła mnie i przywracał do świata żywych, a ja w między czasie przedzierałem się przez kolejne linijki kodu.

W pewnym momencie trafiłem na bardziej złożone zadanie i po ilości klas byłem w stanie stwierdzić, że zrozumienie wszystkiego będzie wymagało ode mnie trzeźwości umysłu i skupienia, o jakie ciężko we wczesnych godzinach porannych. Ale któż powiedział, że życie lekkie jest:) Łyk, już tylko ciepłego, napoju i do dzieła.

niedziela, 14 kwietnia 2013

Test ma testować, nie powielać kod metody.

czy aby oczywiste jest to wszystko?

Niby jasne, że właśnie tak to powinno wyglądać, ale naprawdę często (dobra, dla ścisłości - częściej niżbym chciał:) zdarza mi się oglądać testy, w których ciele mam dokładną kopię kodu, który znajduje się wewnątrz metody testowanej.
Zdaję sobie sprawę, że w przypadku niektórych rzeczy dużo wygodniej jest wykonać kilka instrukcji niż zastanowić się jaki może być wynik. Najczęściej, takie mam przeświadczenie, programiści decydują się na kopiowanie kodu z metody po to, aby się przypadkiem nie pomylić i żeby oczekiwany wynik był na pewno dobry.

I w tym miejscu pragnę wrzucić delikatne, ale jakże wymowne - WTF?!

środa, 10 kwietnia 2013

Diagramy statyczne nie są drogą do celu

Ostatnio miałem okazję przyglądać się kilku osobom, które nie mają zbyt wielkiego doświadczenia w tworzenia projektów. Posiadają wiedzę na temat programowania obiektowego, znają paradygmaty, wzorce, ogólnie całkiem nieźli z nich programiści, jednak swoją przygodę z tworzeniem designów dopiero zaczynają.
Jedną z obserwacji, która rzuciła mi się w oczy jest sposób w jaki większość z nich rozpoczyna tworzenie projektu. Mianowicie - zaczynają od tworzenia diagramów klas.

sobota, 6 kwietnia 2013

SOLIDny kod cz. 3 - Open/closed principle

łatwo powiedzieć

W najprostszej i najkrótszej postaci definicja drugiej zasady SOLID, to: elementy systemu powinny być otwarte na rozszerzenia, ale zamknięte na zmiany. Proste, jasne i przejrzyste, czyż nie? No dobra, może nie takie jasne i przejrzyste, ale przynajmniej proste. Łatwo zapamiętać:)

Może przesadzam z tym, że nie jest ona (definicja) równie przejrzysta jak prosta, bo w większości przypadków programista jest w stanie wytłumaczyć o co chodzi - "O to, żeby łatwo było rozszerzać bez mieszania w kodzie". Problemy zaczynają się wtedy, gdy docieramy do projektowanie czy też tworzenia kodu, bo to, co prosto powiedzieć, już wcale takie banalne w realizacji nie jest.

Jak umożliwić rozwój, który nie wymaga zmian?

niedziela, 24 marca 2013

You Aren't Gonna Need It

programista = wróżbita

Z moich obserwacji wynika, że większość programistów ma podświadomy pociąg do arkanów sztuk tajemnych, w szczególność do wróżbiarstwa. I o ile nie widzę nic złego w oderwaniu się od codziennej rutyny, to problem zaczyna się wtedy gdy owe zainteresowania zaczynają praktykować również podczas tworzenia kodu. I jeszcze śmiem twierdzić, że to również nie jest takie tragiczne, ale... no właśnie... ale najczęściej to przepowiadanie przyszłości programistom najzwyczajniej nie wychodzi zbyt dobrze.

Żeby nie powiedzieć - wcale.

niedziela, 10 marca 2013

Więcej nie znaczy wolniej cz.3 - projektowanie

zaprojektujmy coś...

Kiedy przeprowadziliśmy już analizę i wiemy, co klient chce abyśmy zrealizowali, wiemy, czego nie chce i obie strony rozumieją co i jak ma działać, możemy ruszać dalej, czyli przełożyć wymagania na coś, co lepiej pasuje do naszego obiektowego świata:)
Jednym zdaniem - pora na zaprojektowanie naszej aplikacji.