Gdzie popełniłem błąd? Jak to możliwe, że kolega obok pisze SZYBCIEJ lepszy kod? W czym niby jest on lepszy, skoro obaj mamy podobne doświadczenie? Jeśli zawsze się nad tym zastanawiałeś to zdradzę Ci pewien sekret, który ostatnio sobie uzmysłowiłem.
Nie robić za dużo zmian na raz podczas pracy. Tajemnicą każdego superproduktywnego 10x developera jest szybki feedback loop. Rozumiem przez to, aby jak najczęściej testować nasz napisany przed chwilą kod. Wyrobienie sobie nawyku, aby po napisaniu kawałka od razu go testować. W ten sposób znacznie przyspieszamy sobie drogę do odnalezienia błędów, które w międzyczasie może przypadkiem wprowadziliśmy. Nie musimy wertować sterty diff’ów i doszukiwać się, która linijka wycięła nam numer. Ludzki umysł posiada ograniczony kontekst. Stąd takie podejście jest naturalnym wsparciem naszych słabości.
Jeśli pętla kod – test jest zbyt długa, naszym głównym celem powinno być na samym początku maksymalne jego skrócenie. W ten sposób zaoszczędzimy mnóstwo czasu, czekania, które moglibyśmy spożytkować bardziej produktywnie. Zbyt długi feedback loop sprawia, że będziemy zwlekać z testowaniem do ostatniego momentu. Czas na odnalezienie źródła problemu w wydawałoby się jasnym kodzie, który przecież przed chwilą napisaliśmy będzie się tylko wydłużał.
Według mnie właśnie to jest celem podejścia TDD. Nawet nie samo pisanie testów przed tworzeniem kodu jest tutaj najważniejsze. Najistotniejsze jest to, abyśmy stali się zdecydowanie bardziej produktywni. Aby nasz kod już od początku był wolny od oczywistych błędów.
Naturalnym rozwinięciem skracania feedback loopa jest live coding – czyli natychmiastowa wizualizacja efektów zmiany naszego kodu. I tutaj świetnie sprawdza się Lisp, ze swoją dynamiczną naturą, dzięki której kod aplikacja jest w stanie modyfikować swój własny kod.
Kolejny plus – mniejsze commity. A mniejsze commity = lepsze code review. Ave, faster feedback loop!