[MoodOfTheSong] 12. Puzzle Driven Development

Stosuję w MoodOfTheSong technikę Puzzle Driven Development.

Co to jest? Co to za kolejna Coś Tam Driven Development metodyka? Jest to podejście stojące w sprzeczności z powszechną praktyką zabraniania komentarzy TODO.

Niektóre narzędzia do analizy statycznej kodu, np.: javowy Checkstyle, w domyślnej konfiguracji zgłaszają wręcz słowo TODO w komentarzu jako błąd! A moim zdaniem – jak również Yegora Bugayenko, twórcy tej techniki i wspierających ją narzędzi – takie komentarze są ważne.

Oczywiste jest przecież, że nigdy nasz kod nie jest idealny, że zwykle są jakieś brakujące wymagania, że często obsługa jakiegoś przypadku brzegowego – jeszcze – nie jest zaimplementowana, że, wreszcie, mamy testy, które są wyłączone bo powstały żeby udowodnić istnienie buga.

PDD polega więc na tym, że wszędzie gdzie coś jest nie dokończone, wstawiamy komentarz TODO (odpowiednio sformatowany). Jakie to są przypadki? Na przykład:

  1. Implementując konkretne wymaganie, widzimy że gdzieś obok fragment kodu wymaga poprawy. Aby nie mieszać niezwiązanych ze sobą zmian w jednym komicie, dajemy komentarz TODO i wracamy do niego później.
  2. Klient zgłasza buga. Robimy test, który dowodzi jego istnieniu, wyłączamy go (xit, @Ignore itp.), zamieszczamy komentarz TODO: uncomment i komitujemy zmiany.
  3. Dopisujemy coś do istniejącej już funkcji. Widzimy, że zaczyna ona się za bardzo rozrastać, ale nie mamy chwilowo pomysłu jak ją zrefaktorować. Dajemy komentarz TODO refactor

I tak dalej. Przeważnie takie rzeczy załatwia się inaczej – np. tworząc ticket w Githubie, Jirze czy innym narzędziu do zarządzania rozwojem projektu. No właśnie, i tu dochodzimy do sedna sprawy. Istnieją narzędzia, które automatycznie zakładają ticket w Githubie z chwilą, z którą w repozytorium pojawi się nowy komentarz TODO!

Więcej na temat tych narzędzi, wraz z instrukcją instalacji znajdziecie na blogu autora.

Polecam przeczytać i zastanowić się czy takie rozwiązanie pomogłoby Wam w rozwijaniu projektu.