Tutorial Driven Development – kiedy stwierdzasz, że masz za mało motywacji, żeby się nauczyć kompletnie nowej technologii tak po prostu. Angażujesz się jednak w projekt, który wymaga jej użycia.

Jesteś kompletnie zielony, więc cykl pracy wygląda mniej więcej tak:

1. nowy problem
2. google
3. znajdujesz tutorial (lub odpowiedź na stack-overflow), który go (lub wystarczająco podobny) rozwiązuje
4. implementujesz rozwiązanie zgodnie z tekstem
5. dostosowujesz do swoich potrzeb
6. powtarzasz cykl

Po pewnym czasie listę można zredukować o punkt 4 – od razu przystępujemy do modyfikacji. Po kolejnych cyklach pomijamy punkt 2 i wiemy, że analogie są w napisanym przez nas kodzie- musimy sobie przypomnieć “jak to się robiło”. Coraz mniej też jest problemów, które w ten sposób potrzebujemy rozwiązać aż w końcu sięgamy po tą technikę tak rzadko, że już nie można mówić o Tutorial Driven Development. Czujemy się swobodnie z nową technologią, a z tąd już prosta (choć długa) droga do zostania ekspertem.

foto: Sigurd R

Ps. Ten wpis miał być humorystyczny, ale w trakcie pisania uświadomiłem sobie, że opisuję koncepcję Shu-ha-ri).

I nie chodzi mi o to, że można członków zespołu traktować jak trybiki i dowolnie wymieniać. Chyba, że wyobrazisz sobie ręcznie robiony, szwajcarski zegarek, w którym każdy trybik jest długo i dokładnie szlifowany, aby pasował do reszty (wymiana go jest możliwa, ale zdajesz sobie sprawę z kosztów).

Ale wróćmy do głównego wątku. Jeśli nie byłeś nigdy członkiem takiego zespołu, a chciałbyś takim zarządzać, to czytaj uważnie.

Z natury jestem leniwy. Ale jestem dość specyficznym leniem, który nie lubi nic nie robić. Dlatego w ogóle zostałem programistą – lubię automatyzować i ulepszać rzeczy, które są nudne i żmudne do ręcznego wykonywania.

Zatem zaczął mi doskwierać pewien proces. Przy pewnym projekcie dość często musimy aktualizować utrzymywane systemy, które mają kilka instancji(w tej chwili 3, a ma być więcej). Wygląda to mniej więcej tak:

1. zaloguj się na serwer
2. cd instancja#1
3. git pull
4. wpisz hasło
5. odpal migrację
6. cd ../instancja#2
7. git pull
8. wpisz hasło
9. odpal migrację
10. cd ../instancja#3
11. git pull
12. wpisz hasło
13. odpal migrację
14. TADA!

Serio. Pierwszym krokiem było napisanie skryptu, które te kroki odpala samodzielnie. Zaczęło to wyglądać tak:

1. zaloguj się na serwer
2. ./update-me.sh
3. wpisz hasło
4. wpisz hasło
5. wpisz hasło

Drugim krokiem było skonfigurowanie GITa tak, aby nie wymagał hasła na niektórych maszynach (przy pomocy kluczy rsa) Proces uprościł się do

1. zaloguj się na serwer
2. ./update-me.sh

Jaki jest efekt? Pierwszy, który się narzuca to oszczędność czasu. Zakładając, że taki update odbywał się 3 razy dziennie to zaoszczędziliśmy jakąś minutę. Nie wydaje się to rozsądne, gdyż oba zadania zajęły mi kilka godzin. Z księgowego punktu widzenia mamy stratę.

Jednak uważny obserwator mógł stwierdzić, że mamy w tym projekcie instancję główną i “towarzyszące”. W pierwotnym, ręcznym, procesie pozostałe dwie często zostawały w tyle. Rodziło to problemy przy testowaniu i mergowaniu zmian.

Dodatkowo prosty update to częsty update, zatem i testerzy nie muszą się dopraszać, żeby zaktualizować wersje, bo zwyczajnie są w najnowszej wersji.

Wracając do mojej tezy: Zespół to maszyna, programiści to (nie tak łatwo wymienialne) trybiki, procesy to miejsca, gdzie trybiki i inne części się ścierają. Niedoświadczonemu operatorowi może się wydawać, że przestoje spowodowane oliwieniem maszynerii to stracone pieniądze. W końcu przez te X godzin mogła wyprodukować Y $$$.

Refaktoring, automatyzacja i inne usprawnienia oliwią procesy w zespole programistów. Gdy nie ma niepotrzebnych tarć można rozwinąć optymalną prędkość, a awarie są mniej prawdopodobne.