O istocie tworzenia

Pamiętam dobrze moją pierwszą grę platformową.
Powstała w czasach kiedy Delphi było popularnym językiem do tworzenia aplikacji windowsowych. Było to także moje pierwsze podejście do języka obiektowego, poprzedzone dłuższym pisaniem w proceduralnym Pascalu. Nie rozumiałem wtedy do końca idei tworzenia obiektów, dlatego cały kod gry znajdował się w głównym obiekcie Main. Nie wiedziałem jak powinno się animować elementy gry, ale zauważyłem, że można poruszać kontrolką Image poprzez zmianę marginesów. Każdy element świata gry był obsługiwany przez osobny wątek, a do komunikacji użyłem zmiennych globalnych. Kod był w wielu miejscach powtórzony, a dopisywanie kolejnych kawałków przypominało zabawę z wieżą Hanoi. To wszystko miało jeszcze jedną ważną cechę - działało.

Gra wyglądała dokładnie tak, jak ułożyłem to sobie wcześniej w głowie. Była wykonana przy pomocy niewielkich umiejętności technicznych, a napędzana czystą ambicją i radością tworzenia. Otworzyła mi oczy na zupełnie nowe możliwości, gdzie dowolny pomysł może zostać przy pomocy komputera przeniesiony do świata rzeczywistego.

Nie ma lepszej pracy niż praca związana z tworzeniem. Nie ma lepszego uczucia po wykonanej pracy niż to, kiedy patrzymy na swoje ukończone dzieło. Setki myśli towarzyszą nam każdego dnia, z których ta jedna została wybrana i przekuta w coś co można dotknąć, obejrzeć lub posłuchać. Dzięki temu zostanie z nami na dłużej.
Ta historia wydarzyła się 12 lat temu. Jak wiele rzeczy zmieniło się od tamtego czasu? Więcej niż się spodziewałem.

Szaleństwo innowacji

Czasy kiedy do tworzenia stron HTML używało się notatnika już dawno minęły. Dzisiaj pracę zaczynamy od instalacji node.js, żeby móc w spokoju oddać się instalowaniu kolejnych pakietów NPM.
Wybieramy swój ulubiony framework i za pomocą Yeoman'a tworzymy strukturę projektu.
Dodatkowe komponenty można ściągnąć za pomocą Bowera, ale podobno został już zastąpiony innym rozwiązaniem.
Jaki zatem framework wybrać do budowania aplikacji? Backbone, Ember, Angular?
Może bardziej trendy, czyli React lub Aurelia?
Za rogiem już czyha zupełnie odrestaurowany Angular 2.0.

Mnogość opcji powala na kolana, a zasadność powstawania nowych bibliotek do tworzenia stron www jest od długiego czasu szeroko komentowana przy każdej możliwej sposobności. Co oznacza szybkie dezaktualizowanie się narzędzi? Że ciągle musimy uczyć się obsługi nowych, pomimo ich wątpliwej innowacyjności.

Rynek IT nie toleruje przerwy na złapanie oddechu, dlatego wymagane jest wymienianie skrzynki narzędziowej znacznie częściej niż wtedy, gdy zużyją się narzędzia. Częściej niż zdążymy poznać wszystkie ich tajniki i wyrobimy biegłość w ich używaniu. Raz po raz jesteśmy zmuszeni wrócić do podstaw i po raz kolejny uczyć się jak podpiąć akcję pod przycisk. Początkującym może to sprawiać radość i umożliwiać łatwiejsze wejście do świata IT. Starzy wyjadacze będą w tym widzieć jak historia po raz kolejny zatacza koło. Gdzieniegdzie na twarzach pojawi się grymas zmęczenia. Każda taka zmiana spowalnia mocno proces tworzenia. Aplikacja nie rośnie już w oczach, tylko mozolnie drepta małymi kroczkami do przodu. Aż do przyswojenia nowych informacji i zdobycia biegłości w używaniu nowych narzędzi. Do czasu...

Mędrcy i radykałowie

Nie zamierzam tutaj kwestionować zasadności użycia wzorców projektowych. Wiele z nich powstało w odpowiedzi na powtarzające się problemy i trudności napotkane przez innych programistów. Warto jednak mieć jedną rzecz na uwadze podczas ich użycia - są rozwiązaniem pewnego problemu, a niekoniecznie musi być to nasz problem. Warto zadać sobie trochę trudu i dobrze zdefiniować na czym polega nasza trudność, a następnie skonfrontować to zalecanymi przykładami użycia danego wzorca. Od rozważnego używania wzorców do radykalnego wpychania ich w każdą część aplikacji jest krótka droga.

Nietrudno spotkać wśród społeczności osoby, które swój wątpliwy autorytet zbudowały na traktowaniu utartych wzorców jako świętości i indoktrynowaniu wszystkich dookoła o niepodważalnej słuszności użycia takowych. W życiu, tak samo jak w programowaniu, nie ma miejsca na radykalizm. Nie można powiedzieć, że od każdego Singletona gdzieś na świecie umiera kotek, a od użycia ServiceLocatora usychają ręce. Przypomina to trochę dyskusję o alkoholu. To, że niektórzy go nadużywają nie oznacza, że należy wszystkim go zabronić.
Wszystko zależy od kontekstu użycia i umiejętności realnego spojrzenia na zyski i konsekwencje. Pragmatyzm w działaniu to bardzo pożądana cecha, ponieważ umożliwia podejmowanie decyzji, które przybliżą nas do osiągnięcia celu.

A co z konsekwencjami? Są oczywiście brane pod uwagę. Z jakichś powodów zostały umieszczone na dalszym planie.

To, co istotne

Z perspektywy czasu mogę przyznać, że utraciłem pewną zdolność. Zdolność do tworzenia bez oglądania się na wytyczne i nakazy. Wraz z nabieraniem doświadczenia i rozpoczęciem pracy zawodowej wręcz wskazane jest podążanie utartymi ścieżkami oraz trzymanie się rozwiązań powszechnie uznawanych za akceptowalne. To zapewnia pewien sposób na osiągnięcie produktu dobrej jakości. Natomiast nie zawsze nasza praca wiąże się z zarabianiem i nie zawsze jakość produktu jest na pierwszym miejscu.

Istotą tworzenia nie jest to jakich narzędzi użyjemy. Nie jest również to, czy nasz proces tworzenia jest efektywny i optymalny. Nie o proces tworzenia tu chodzi, a o samo dzieło. To, co powstaje na końcu.
W całym tym natłoku dobrych praktyk tworzenia oprogramowania można się zatracić i zgubić prawdziwy cel. Nauka nowych bibliotek i kolejne godziny spędzone na rozmyślaniu nad architekturą rozwiązania mogą doprowadzić do zaniechania dalszej pracy.

Motywacja maleje z czasem, a ambicja poddaje się wraz z brakiem efektów. Projekt kończy się porażką, a niespokojne myśli kłębią się w poszukiwaniu tego, co poszło nie tak. Dobrego procesu tworzenia nie pamięta nikt. Dzieło, które wieńczy ten proces, zostaje na zawsze.

Share this post

comments powered by Disqus