Czy zastanawiałeś się już jak to się dzieje, że na początku projektu jesteś maksymalnie zmotywowany, piszesz wspaniałe testy (wszystkie są oczywiście green-bar), używasz swojego najpiękniejszego stylu kodowania, klasy, interfejsy metody, ba! nawet pola mają swoją własną, niepowtarzalną odpowiedzialność. Rysujesz piękne diagramy, używasz wzorców projektowych w rozsądnej ilości, a Twój kod czyta się jak najbardziej przejrzystego ebooka. A potem...potem pojawia się niewielki, ledwo zauważalny zgrzyt, mała rysa na wspaniałym krysztale projektu. Ignorujesz to, bo przecież nic się nie stało. Rysa rośnie, a przez nią wsączają się kolejne niedociągnięcia i niedoróbki, aż po jakimś czasie nie poznajesz już tego wspaniałego projektu, siadasz do niego z największym obrzydzeniem i myślisz tylko kiedy to się skończy? Lecz projekt się nie kończy, wciąż są nowe wymagania, wciąż trzeba go utrzymywać. I to, mój przyjacielu, jest Programistyczne Piekło!
Jako przestrogę podam Ci kilka prostych wskazówek jak się tam znaleźć. Ścieżka prowadząca wprost do Programistycznego Piekła jest szeroka, gładka i bardzo prosta. Wystarczy siedem kroków.
- Bądź obojętny
Czy to ja powinienem zająć się tym //FIXME? Nieee, to nie ja pisałem, niech ktoś inny to zrobi.
Czy często zdarza ci się rozumować w ten sposób? Jeśli tak, to gratuluję! Osiągnąłeś pierwszy poziom wtajemniczenia. Obojętność wobec niewielkich rys na projekcie to początek drogi w dół. Być może pomyślisz: oj, jeśli w jednej klasie będzie niewielki bałagan, to przecież nic się nie stanie. Pamiętaj, że małe rzeczy się kumulują. Nie zauważysz od razu różnicy pomiędzy metodą nazwaną divideByTwo(), a div2()
, bo łatwo umyka wśród reszty kodu. Lecz z pewnością dostrzeżesz różnicę za pół roku, gdy tego typu nazewnictwo będzie obecne w całym projekcie. Ziarnko do ziarnka... - Bądź w miarę wierny swoim ideałom
Cóż, w zasadzie stosuję wzorce projektowe...to znaczy w niektórych projektach. Tych w domu. Piszę też testy...prawie wszystkie przechodzą. Piszę zgodnie ze standardem kodowania...właściwe to w 30%, bo reszta jest niepotrzebna. Odpowiedzialność? Taa, fajny koncept, ale moim zdaniem....
Znasz to? Czy uważasz, że techniki programowania obiektowego teoretycznie są bardzo dobre ale faktycznie się nie sprawdzają? Jak wyrobiłeś sobie takie zdanie? Acha, przetestowałeś to, rozumiem. Wiesz, to że nie działają, to tylko jedna możliwość. Druga to taka, że używasz ich niewłaściwie. Co wybierasz? - Postępuj zgodnie z procedurami
Pokrycie kodu ma być co najmniej 90% więc w tym tygodniu już nie muszę pisać żadnego testu! Ta metoda jest nieczytelna...no, ale CheckStyle się nie czepia. Diagramy muszą być tylko do istotnych elementów systemu...moja jest chyba nieistotna?
Procedury, reguły, zasady są dobre. Precyzują sposób pracy i optymalizują sposób wytwórczy. Często jednak, niemal automatycznie, uważa się, że stosowanie procedur w zupełności wystarczy, zatem można zwolnić się z myślenia. Kłopot w tym, że nawet najbardziej wyrafinowane zasady nie przewidują wszystkich sytuacji, które mogą wystąpić w życiu. Bardzo wiele problemów, z którymi się spotkasz, nie da się rozwiązać za pomocą Księgi Procedur używanej w twoim zespole. Jednak z każdym z nich można sobie poradzić przy użyciu zdrowego rozsądku. - Graj dla zespołu
Nie wychylaj się. Bezkrytycznie akceptuj opinie bardziej doświadczonych kolegów. Postaw cele zespołu nad swoimi własnymi
Przede wszystkim: dlaczego pracujesz w tym zespole? Wymień dziesięć przyczyn. Zrób to teraz!
Jeśli praca, która wykonujesz nie jest zgodna z twoimi osobistymi celami, nie prowadzi cię do jakiegoś wyżej postawionego celu, to prędzej czy później, zaczniesz sabotować to, co robisz. Krok po kroku, niepostrzeżenie, zaczniesz wprowadzać w życie misterny plan obniżania jakości swojej pracy. Być może już teraz warto wybrać się na rozmowę z samym sobą. - Dziel się odpowiedzialnością
Jest błąd w mojej części kodu? ...ale Paweł kazał mi tak napisać...powiedział, że będzie działać...
Zadziwiające, że jeśli chodzi o sukces, to chętnie podpisujemy się pod nim sami. Jeśli chodzi o wzięcie odpowiedzialności za błąd i niepowodzenie chętnie dzielimy się odpowiedzialnością z innymi. - Ceń ludzi takich jak ty
MY programiści i ONI analitycy. MY javowcy i ONI .NETowcy. MY od kluczowego projektu i ONI od maintenance. MY starzy pracownicy i ONI nowi...
Dzieląc swoich i innych sprawia, że nadajemy grupie osób wspólne cechy odróżniające ich od nas samych, czyniących w jakimś stopniu gorszymi. Etykietowanie zapewnia poczucie bezpieczeństwa i porządkuje świat. Daje złudzenie, że nie zginiemy w zespole jako indywidualność. Jak na ironię, takie postępowanie likwiduje indywidualność członków zespołu i blokuje efekt synergii, obejmującą ludzi nic nie znaczącą etykietą oni. - Wierz w najlepsze rozwiązanie
Ok, pracujemy w Agile, teraz już będzie dobrze. JEE rozwiąże wszystkie problemy. Nowy framework sprawi, że praktycznie kod będzie pisał się sam.
Gdyby istniało rozwiązanie/technologia/framework rozwiązująca wszystkie problemy to już dawno by zostało wymyślone i żylibyśmy w świecie, w którym nie byłoby wojen, nikt nie przekraczałby prędkości, a programy by się nie zawieszały. Nie istnieje najlepsze rozwiązanie (w ogóle). Co najwyżej może istnieć rozwiązanie najlepsze, w sensie: najbardziej odpowiednie i optymalne, w danej chwili, dla danego problemu, w danym zespole. Jedyne co może zrobić nowa technologia, framework, biblioteka, czy język to przenieść ciężar problemu w inne miejsce. To coś jak dźwignia pozwalająca zużyć mniej energii do uzyskania tego samego efektu. Pamiętaj jednak, że zawsze istnieją dwie strony medalu. Coś co rozwiązuje jedne problemy zazwyczaj generuje nowe.
Tekst powstał z inspiracji artykułem Philipa Zimbardio Evil's Seven Step Seduction Scenario opublikowanym w Charaktery 9/2008
