Zastanawiacie się co to takiego ten tunel kodu? Otóż chodzi tutaj o specyficzny stan świadomości, z dużym skupieniem i widzeniem tunelowym, w który mogą wejść programiści tworzący kod. Można o nim przeczytać np. w książce autorstwa Roberta C. Martina Mistrz czystego kodu. Kodeks postępowania profesjonalnych programistów, choć tam nosi on nazwę strefy lub przepływu (flow). Zgodnie z opisem we wspomnianej książce, stan ów charakteryzuje się tym, że znajdujący się w nim programiści czują się naprawdę produktywni i całkowicie nieomylni. W efekcie starają się jak najdłużej w nim pozostawać, a miarą ich wartości staje się spędzony w nim czas.

Zdaniem Roberta C. Martina nie jest to pożądany stan. Będąc w tunelu, na pewno napisze się więcej kodu. W przypadku stosowania podejścia TDD, bezsprzecznie szybciej przejdzie się przez pętlę czerwone – zielone – refaktoryzacja. Z pewnością bonusem z przebywania w tunelu jest poczucie lekkiej euforii. Problem polega na tym, że w tym stanie traci się szerszy pogląd na zagadnienie, przez co można podejmować decyzje, które później będzie trzeba zmieniać. Kod napisany w tunelu kodu na pewno powstaje szybciej, ale później trzeba go częściej poprawiać. Słowem – tunel wprowadza w niepożądany stan oszołomienia i może dać nieoczekiwane rezultaty. To trochę jak w poniższej scenie:

http://www.youtube.com/watch?feature=player_detailpage&v=49GPB2tTVqg#t=94

Czy jest zatem coś gorszego dla programisty niż tunel kodu? Otóż jest – to chroniczny brak tego tunelu. Paradoks? Otóż nie, jeśli ktoś pracował w Open Space i to takim, który nie ogranicza się do członków zespołu pracującego wspólnie nad tą samą aplikacją, ale zawierającego także inne zespoły i dość swobodnie dostępnego dla różnych przeszkadzaczy, może wręcz chronicznie pożądać znalezienia się w takowym tunelu, byle tylko doprowadzić swój kod do stanu używalności. Możliwość odcięcia się od otoczenia, jakie daje tunel, zdaje się w takim przypadku Świętym Gralem Programowania.

Czyżby więc nie było nadziei dla znękanych wszechobecnym harmidrem programistów? Czy muszą wybierać pomiędzy złem i złem? Otóż nie. Na wszystko znajdzie się sposób – także na tunel. I nie przypadkiem przywołałem powyżej scenę z pociągiem metra i szalonym motorniczym. Sposobem na tunel jest plan – najlepiej taki, który będzie przypominał jedyną, funkcjonującą obecnie linię metra w Polsce. To jest linia prosta – żadnych odnóg (och, za chwilę się to zmieni, ale przecież dla tak inteligentnych ludzi, jak programiści, dwie skrzyżowane linie, to nie droga krzyżowa ;)). I posiada przystanki. Szaleniec wyżej kompletnie je ignorował, ale my nie będziemy. Na każdym się zatrzymamy i sprawdzimy czy wysiedli ci co nie chcieli jechać dalej, a wsiedli, ci co chcieli rozpocząć podróż. Zachowamy środki bezpieczeństwa. Punkt po punkcie będziemy weryfikować czy to co programujemy, jest rzeczywiście tym co zaprogramować powinniśmy. Żadnych niepotrzebnych działań, żadnych przeskoków. W ten sposób nie damy się ponieść tunelowi, będziemy go przemierzać na własnych zasadach. Spokojnie, nie pędząc i nie wpadając ani w euforie, ani w szaleństwo, ani na ścianę na końcu tunelu. Dojedziemy do swojej bocznicy. Jedyne co trzeba zrobić, to przygotować sobie plan tego, co mamy zaprogramować. Jaki ma być tego programowania efekt końcowy – rezultat i jakich metod oraz algorytmów użyć. Jeśli mamy dobrego analityka, a może jeszcze architekta, to właściwie będziemy mogli skorzystać z gotowca. A wtedy to my rządzimy w tunelu, a nie tunel nami.

Jak na razie to oswojenie tunelu mi się sprawdza. Nie od razu tunel opanowałem, ale opanowałem. Zresztą zdecydowanie wolę napisać kod, który będę musiał zrefaktoryzować, niż nie napisać kodu w ogóle. A może ja w ogóle nie wpadam w ten stan, o którym pisze Martin?