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.

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.

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

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.

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?

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.

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.

Więcej nie znaczy wolniej cz.2 - analiza

kiedy jest tylko pomysł...

Czym jest analiza? Analiza to rozkład na składniki/czynniki (wikipedia). Trochę lakonicznie, nieprawdaż? Próbą zdefiniowania terminu w interesującym nas kontekście zajmę się w kolejnym akapicie. Teraz skupmy się na tym kiedy jest czas na analizę?

Jest to aktywność, która powinna być przeprowadzona na samym początku, to wyniki analizy dają nam podstawy do stworzenia dobrego projektu.

Więcej nie znaczy wolniej cz.1

o tym, co sprawia, że jesteśmy lepsi

Ostatnio robiłem podsumowanie roku kierowania projektem (pisałem o tym tutaj) i statystyki, które ujrzały moje oczy, były dużo lepsze niż się spodziewałem:)
Nie jestem jednak osobą, która długo cieszy się sukcesami. Większą radość odnajduję w kolejnych wyzwaniach, więc następnego dnia, po przedstawieniu zespołowi efektów naszej wspólnej pracy, zacząłem się zastanawiać, co dalej? Wychodzę z założenia, że pozostanie w tym samym miejscu jest równoznaczne z cofaniem się do tyłu, tak więc jedynie kolejne ulepszenia wchodzą w grę:)

SOLIDny kod cz. 2 - Single responsibility principle

w czym rzecz

Jak już ostatnio pisałem, Single responsibility principle (SRP), czyli zasada jednej odpowiedzialności, mówi o tym, że klasa nie powinna mieć więcej niż jednego powodu do modyfikacji.
Często spotykam się z tym, że programiści twierdzą, że takie myślenie prowadzi jedynie do niepotrzebnego rozbijania każdej klasy na kilka bądź więcej elementów składowych. Co za tym idzie? Potrzeby zarządzania wieloma klasami. A to wszystko tylko po to, żeby zrobić coś naprawdę prostego.

Cóż, można na to spojrzeć w ten sposób. Jednak jest kilka ale...