Charakter narodowy Polaków, czyli kończ waść, programowania oszczędź

Charakter narodowy Polaków czyli kończ waść, programowania oszczędź

Ostatnio bardzo mocno mnie zastanawia, jaki wpływ na sposób tworzenia programowania mają typowe cechy Polaków. Dochodzę do wniosków, które miejscami osobiście mnie zaskakują. A chodzi o istotę programowania, projektowania i innych elementów, które szumnie nazywamy inżynierią oprogramowania.

Polak jest krnąbrny. Polak musi wszystko zrobić sam. Oczywiście po swojemu. Czyż nie przypomina nam to naszych kochanych bohaterów romantycznych, pozytywistycznych i pewnie kilku innych. Co najciekawsze odnoszę wrażenie, że dokładnie tak samo jest w świecie współczesnym. W pełnym wymiarze, moim subiektywnym zdaniem, dotyczy to również naszych ukochanych informatyków. Wprawdzie ostatnie uogólnienie może być prawdziwe dla całej rzeszy informatyków, skupię się na samym procesie programowania.

Polak programista jest twórczy ? tego nie można mu zarzucić. Potrafi stworzyć wszystko, zaprojektować system, którego jeszcze nikt nie zaprojektował, włamać się do systemu, którego jeszcze nikt nie złamał. Radzi sobie świetnie.

Jakim kosztem?

Na szczęście ma niemal wrodzoną umiejętność kombinowania na wszelkie możliwe sposoby. Przecież nie ma góry nie do zdobycia.

Ale jakim kosztem?

Kreatywność jest błogosławieństwem, ale czasami może być przekleństwem. Dlaczego? Ponieważ za każdym razem trzeba rozwiązywać problemy, które już były rozwiązane ? jeśli nie całkowicie, to przynajmniej częściowo. Spostrzeżenie: Polak programista ma tendencje do ciągłego wymyślania kół od nowa! A może to niechęć do nauki na podstawie doświadczeń innych? Może trzeba samemu się oparzyć? Zepsuć? Nie przespać kilku nocy?

Spróbuję zamodelować typowy proces poznawania biblioteki przez naszych współziomków. ?Ok, znalalazłem bibliotekę. Pewnie zrobi za mnie wszystko. Hmm? gdzie jest jakiś tutorial? O, jest! No proszę, całkiem niezła ta dokumentacja?. Tutaj następuje czytanie kilku pierwszych wierszy/akapitów (niepotrzebne skreślić). Niedługo potem następuje zniechęcenie. I pojawia się olśniewająca myśl: ?Nic sensownego nie piszą. Zabiorę się do eksperymentowania z biblioteką, pewnie szybciej dojdę do tego, o co chodzi.? I zaczyna się długotrwały proces tworzenia własnych rozwiązań. Długotrwały i żmudny ? należy podkreślić. Owszem Polak programista dojdzie do pewnych, tylko sobie znanych sposobów korzystania z nowego narzędzia, wymyśli kilkanaście pokrętnych pomysłów na realizowanie podstawowych zadań. Nie zauważy tymczasem jednej rzeczy: jego rozwiązania są bardzo dziwne i przypominają drapanie się lewą ręką za prawym uchem. I co najważniejsze ? straci mnóstwo czasu, pozostanie zaś uczucie, że ?nie dokońca wszystko rozumiem.?

Jaki płynie z tego wniosek? Polak programista ma tendencję do tworzenia własnych rozwiązań, lecz zazwyczaj nie potrafi stworzyć sobie zbioru dobrych nawyków. Jego IDE to jedno wielkie pobojowisko, nazwy klas, metod, pól to mieszanka wszystkich możliwych konwencji (stosowanych oczywiście niekonsekwentnie). Polak programista nie zdążył nauczyć się zasad dobrego, uporządkowanego programowania, bo w międzyczasie poznał tysiące niuansów języka programistycznego (niuansów tych oczywiście nigdy nie wykorzysta). Podsumowując: Polak programista jest nieekonomiczny.

Trochę wyjaśnień. Skąd ta nieekonomiczność? Przyjrzyjmy się procesowi nauki dowolnej umiejętności. Proces ten możemy podzielić na cztery etapy:
1. niekompetencja nieświadoma ? nie wiem, że nie potrafię (sześcioletnie dziecko nie wie, że nie potrafi jeździć samochodem)
2. niekompetencja świadoma ? wiem, że nie potrafię (osiemnastoletnie już dziecko chcę jeździć samochodem, ale wie, że musi się tego nauczyć)
3. kompetencja świadoma ? już potrafię, ale kosztuje mnie to mnóstwo energii (osiemnastoletnie dziecko już zrobiło kurs prawa jazdy, ale jeszcze musi się skupiać na tym, że zmieniać bieg, spoglądać w lusterka, obserwować ulicę, włączać kierunkowskaz itp.)
4. kompetencja nieświadoma ? potrafię i już nie pamiętam, że to mogło sprawiać problem

Czy przypominacie sobie waszego ulubionego muzyka, który gra na instrumencie tak, jakby to była czynność dla ludzi naturalna? To właśnie jest objaw posiadania kompetencji nieświadomej ? niezwykle skomplikowane procesy zachodzą w sposób uporządkowany i subiektywnie prosty. To jest właśnie ten element, którego brak Polakowi programiście. Upraszczając ? brak jest podstawowych dobrych nawyków. Wyobraźcie sobie, jak wielki potencjał tkwi w połączeniu dwóch cech: kreatywności i umiejętności czerpania z przemyślanych (czytaj: dobrych) nawyków. W końcu przestajemy skupiać się żmudnym tworzeniu niskopoziomowych rozwiązań (mamy nawyki), a skupiamy się na rzeczach istotnie ważnych ? jak zrealizować to, co jest unikalne dla naszego projektu. Wtedy można, a nawet należy, wykorzystać typową dla Polaków kreatywność.

Na zakończenie słów kilka o tym, skąd takie wnioski. Do zespołu Equilibrium zgłasza się wiele osób (80% studenci wyższych lat), jednym z elementów procesu rekrutacji jest zrobienie zadania. Zadanie jest nieskomplikowane, natomiast ujawnia wiele braków projektowych i programistycznych. Możemy stwierdzić, że w dużej części przypadków kod jest tworzony niechlujnie, brak jest znajomości (a na pewno wykorzystywania) metod obiektowych, istnieją duże wypaczenia na poziomie projektowym. Krótko mówiąc ? nie jest dobrze. Dla wszystkich tych, którzy chcieliby przyjrzeć się własnym poczynaniom, poniżej zamieszczamy otwartą listę umiejętności, których zastosowanie warto rozważyć:
1. uporządkowane podejście do ustrukturyzowania projektów na poziomie ich artefaktów (np. określona struktura katalogów - wsparciem może być Maven),
2. stosowanie standard kodowania (niezwykle istotny),
3. znajomość metod obiektowych (często pojawia ogromny brak wyczucia sfery odpowiedzialności obiektów),
4. używanie wzorców projektowych (celowo potraktowane osobno),
5. testowanie (jednostkowe, integracyjne i funkcjonalne),
6. refaktoring kodu,
7. korzystanie z architektur systemów oprogramowania.

Mariusz Sieraczkiewicz
Zespół Equilibrium
http://equilibrium.fpl.pl