rss

Programowanie przez prototypowanie

Często zdarzają się sytuacje, w których wiele dostępnych opcji wydaje się podobnych i trudno wybrać jedną. Łatwo wówczas popaść w manię analizy, zastanawiając się bez końca jakie konsekwencje będzie miała każda z decyzji. Wystarczy je tymczasem kolejno wypróbować, żeby niewielkim kosztem znaleźć tą najlepiej odpowiadającą potrzebom.

Michał Paluchowski, 18 maja 2010

Argument czy funkcja, argument czy funkcja, argument… Jeśli dodam do istniejącej funkcji kolejny, opcjonalny parametr, utrzymam dotychczasową konwencję i tylko dla niektórych przypadków będę musiał zmienić wywołania. Jeśli jednak dodam nową funkcję, uzyskam krótszy, bardziej przejrzysty kod. Ostatecznie wybór padł na argument, ponieważ potrzebny był w niewielu przypadkach.

W ten oto sposób, poszukując najlepszego rozwiązania, spędziłem dobrze ponad godzinę. Problem z punktu widzenia całego systemu był nieistotny. Podobne sytuacje zdarzają się jednak bardzo często:

Dotyczy to zarówno programowania jak i innych dziedzin:

Bliźniaki

Co gorsze, im mądrzejsza osoba podejmująca decyzje, tym częściej zdarza jej się paraliż decyzyjny. Jest tak ponieważ osoba mądra zobaczy znacznie więcej czynników mających wpływ na decyzję i jej możliwych konsekwencji – zjawisko znane jako „paraliż analizy” (ang. analysis paralysis). Osoba mniej wyrafinowana najpewniej pójdzie po najkrótszej linii oporu.

Nawalaj wcześnie i często

Z angielska fail early, fail often to jak się okazuje najlepsza droga wyjścia z sytuacji paraliżu. Można ponosić porażki. Co więcej, można i powinno się je ponosić często. Żadnych długich analiz, studiów wpływu środowiskowego czy powoływania komisji ekspertów od dyskutowania. Zamiast tego prototypujemy rozwiązanie, czyli testujemy je „na brudno”. Instrukcja postępowania jest krótka:

  1. Wybierz rozwiązanie, co do którego masz najlepsze przeczucie.
  2. Wykonaj jego najprostszy możliwy prototyp.
  3. Sprawdź jak spisuje się w rzeczywistości. Czy spełnia oczekiwania?
    1. Tak. Gratulacje! Teraz przepisz to „na czysto”.
    2. Nie. Wyrzuć i wróć do punktu 1.

A więc jeśli programując zastanawiasz się czy zastosować architekturę MVC czy MVP, wybierz pierwszą, szybko naszkicuj i zaprogramuj. Czy komunikacja między klasami jest przejrzysta i wygodna w zarządzaniu? Czy łatwo ci testować kod? Czy logika, dane i prezentacja pasują tam, gdzie chciałbyś je mieć?

Im trudniejszy problem, z którym się mierzymy, tym ważniejsze jest żeby pójść właśnie taką drogą. Szybkie sprawdzenie rozwiązań zaoszczędzi mnóstwo czasu i zdecydowanie podniesie końcową jakość kodu.

Pytanie, które pada często w takim przypadku: a co z kontrolą wersji? Nie możemy przecież pozwolić nikomu takiego kodu ‚testowego’ umieścić w repozytorium. Słusznie. Nic nie stoi na przeszkodzie, żeby utworzyć dla niego osobną gałąź. Jeszcze lepiej jeśli mamy do dyspozycji rozproszony system kontroli wersji. Wówczas na eksperymenty możemy stworzyć osobną, lokalną kopię. Najlepiej jednak w ogóle nie poddawać takiego kodu kontroli wersji. Z założenia jego żywotność będzie krótka, a jakość ośmieszająco niska.

What if I fail?

A co z liderami?

No tak, ale przecież nie możemy wybrać pierwszego lidera z brzegu i dać mu do pokierowania zespół, a jeśli się nie sprawdzi, wyrzucić i wziąć kolejnego. W końcu ludzie to nie kod źródłowy i nie można ich się pozbyć klawiszem Delete. Można jednak w podobny sposób sprawdzić każdego kandydata: dać obu prawdziwe zadanie, które wymaga zarówno dobrego kontaktu z ludźmi jak i sprawnego podejmowania decyzji:

W każdej organizacji aż roi się od podobnych zadań. Wystarczy przydzielić i sprawdzić wyniki. Kto osiągnął cel? Kto nawiązał lepsze relacje z udziałowcami?

Z czasem decyzje na pewno będą przychodzić łatwiej i szybciej. Doświadczenie to w końcu nic innego jak rozpoznawanie wzorców. Zanim tak się stanie, warto pomóc sobie podejmować szybko te decyzje, które można podjąć. Wtedy można skoncentrować się na naprawdę trudnych i ciekawych problemach, dla których rozwiązania nie widać ani jednego.