Mam malować?

Mając możliwość osobistej weryfikacji kandydata na stanowisko programisty, warto przyglądać się bezpośrednio stylowi jego pracy, czyli pospolicie rzecz ujmując patrzeć mu na ręce. Ta część ''wywiadu'' bardzo dużo mówi o jego umiejętnościach i wprawie warsztatowej.

Mając możliwość osobistej weryfikacji kandydata na stanowisko programisty, warto przyglądać się bezpośrednio stylowi jego pracy, czyli pospolicie rzecz ujmując patrzeć mu na ręce. Ta część ''wywiadu'' bardzo dużo mówi o jego umiejętnościach i wprawie warsztatowej.

Niedawno w poszukiwaniu programistów zamieściłem ogłoszenie w Internecie. Oprócz niezbyt obszernego wyliczenia pożądanych umiejętności kandydata w zakresie określonych technologii - niespecjalnie skomplikowanych i dobrze znanych - bardzo sztywno obwarowałem minimalną długość stażu zawodowego na pięć lat. Podobnie rygorystycznie zastrzegłem, że potencjalny pracodawca sprawdzi na miejscu rzeczywiste umiejętności pretendentów na stanowiska programistów. Muszę wyznać, że nie było nawału ofert, co mnie szczerze zdziwiło w dobie ogólnego kryzysu na rynku pracy. Przypuszczam, że ludzie wystraszyli się tego sprawdzianu, który miał być przeprowadzony przez specjalistów dziedzinowych, a nie przez dział kadr. I chyba nie bez racji. W tak bezpośrednim kontakcie merytorycznym bardzo łatwo ustalić możliwości kandydatów.

Znasz li podstawy?

Prof. Donald Knuth, autor biblii dla programistów noszącej w oryginale tytuł "The Art of Computer Programming", przyznaje, że w jego książkach nie języki programowania są głównym tematem, ale to co można wykonać używając praktycznie dowolnego języka. W celu demonstrowania technik programistycznych używa hipotetycznego języka asemblera o nazwie MIX, przez co jego nauki ukierunkowane są na ponadczasowe prawdy związane z dziedziną programowania. Uogólniając jego słowa, można powiedzieć: nieważne za pomocą jakiej technologii to robisz, pokaż co potrafisz za jej pomocą zrobić.

Rzeczywiście, programowanie obiektowo zorientowane zamąciło niektórym w głowach na tyle, że nad samą sztukę myślenia algorytmicznego przedkładają znajomość tego czy innego języka. Tymczasem prawda jest taka, że nie ma rzeczy, której nie można by wykonać za pomocą języka proceduralnego. Z drugiej strony patrząc, zupełnie zatraciła się gdzieś, dawniej tak ceniona, umiejętność operowania asemblerem dowolnego modelu komputera<sup>1</sup>. Zaglądając na strony instytucji Softpanorama - Open Source Software Educational Society (http://www.softpanorama.org ) w części poświęconej asemblerom wita nas wiele mówiące hasło: Assembler is not for Dummies<sup>2</sup>. Autor tych haseł, dr Nikolai Bezroukov, stwierdza ponadto, że bez solidnych podstaw programowania w asemblerze cała dalsza edukacja programistyczna przypomina budowanie zamków na piasku. Dalej, trochę przekornie i nieco żartobliwie komentuje, że prawdziwe to nieszczęście, iż studenci dzisiaj uczą się złożonych i nieciekawych języków (C++ i Java), a nie poznają potężnych technik programowania, jakie używane są np. w kompilatorach. Z przymrużeniem oka można potraktować jego wywody, że tylko najbardziej utalentowani studenci potrafią ogarnąć programy nauczania przeładowane programowaniem obiektowym oraz innymi wymyślnymi zagadnieniami, chociaż jak przekonamy się w dalszej części artykułu, nie jest to znowu tak odległe od prawdy.

Rzeczywiście, należałoby stwierdzić, że asembler jest fundamentalną częścią edukacji programistycznej i ta wiedza daje większe szanse na zostanie lepszym programistą. Dane mi było w życiu programować w trzech różnych językach asemblera, więc pozostaje mi jedynie przyklasnąć powyższym stwierdzeniom, potwierdzając ich prawdziwość. Dobre umiejętności asemblerowe to doskonała znajomość prawideł działania komputerów, a także programów pisanych w językach wyższego poziomu. Niestety, rzadko zdarza się znaleźć teraz życiorys zawodowy, w którym wyszczególniona byłaby ta umiejętność. Czasem zetknąć się z nią można u ludzi z dłuższą praktyką zawodową.

W asemblerze nie pisze się programów użytkowych, gdyż nie jest to język produktywny. Stąd też poszedł nieco w zapomnienie. Dla porównania - w swoim czasie produktywność programistów piszących w języku C była oceniana jako dwa razy niższa niż programistów stosujących Turbo Pascal. W dobie złożonych produktów komercyjnych trudno zbudować konkurencyjną aplikację, np. klasy CRM, używając do tego celu asemblera, czy jakiegokolwiek języka wyższego poziomu, bez wsparcia narzędzi automatyzujących projektowanie formatek i wydruków.

Ale nawet tworzony na dowolnie wysokim poziomie abstrakcji produkt programistyczny zawsze wymaga od autorów logicznego podejścia i właściwego zrozumienia idei programowania.

Co programista, to inny typ

Gdy kiedyś starałem się o przyjęcie do niezbyt dużej firmy software'owej, zadano kandydatom pisemne opracowanie pewnego algorytmu. W tym przypadku zupełnie abstrahowano od konkretnej technologii, chcąc jedynie dokonać selekcji na podstawie sposobu myślenia. I to moim zdaniem jest najlepszy sprawdzian na wydajność umysłową. Technologia zmienia się szybko, podczas gdy predyspozycje danej osoby są względnie stałe.

Lepsze wydaje się zatrudnianie pracowników z odpowiednim nastawieniem i predyspozycjami niż z perfekcyjnie opanowanym warsztatem narzędziowym. Każda techniczna umiejętność, którą kandydaci do pracy dysponują, będzie za kilka lat technologicznie przestarzała, dlatego lepiej pozyskiwać pracowników zdolnych do nauczenia się dowolnej innej technologii, niż takich, którzy akurat w danym momencie znają jakiś język programowania i środowisko narzędziowe.

Wobec ciągłych zmian w informatyce lepiej pozyskiwać pracowników radzących sobie z każdym niemal nowym problemem zawodowym, nawet jeśli są zmuszeni dopiero nauczyć się technologii.

Taki pracownik jest znacznie lepszym nabytkiem, aniżeli ograniczony specjalista wąskodziedzinowy, niezdolny do przyswojenia sobie jakiejkolwiek świeżej wiedzy.

Bywają też kandydaci zdolni, którzy nie potrafią jednak wkomponować się w istniejący układ wymogów codziennej pracy, mając często tendencje do zupełnie niepraktycznych pomysłów, nad którymi marnotrawią cenny czas, zawalając kolejny termin ukończenia projektu. Szukają dziury w całym, zastanawiają się, czy nie lepiej byłoby stawiać kropkę pod i zamiast nad, a drobne zagadnienie potrafią przeistoczyć w akademicki wywód, nikomu do niczego nieprzydatny. Łatwo ich poznać po tym, że nie potrafią "na żądanie" doprowadzić do końca żadnego problemu algorytmicznego, czy jakiegokolwiek innego praktycznego zagadnienia. Ich uwagę zaprząta z reguły to, co nie prowadzi do skutecznego rozwiązania danego problemu.

Jako przeciwny biegun tychże istnieją kandydaci bardzo pokorni w realizacji poleceń, ale z kolei pozbawieni bystrości i popełniający zbyt wiele błędów, co także czyni zaczęte przez nich projekty całkiem bezwartościowymi. Ktoś przecież będzie w przyszłości zmuszony poprawiać ich błędy. Są to programiści, którzy zamiast stworzyć funkcję wielokrotnego użycia, powielają te same fragmenty kodu. Oczywiście program także będzie działał, jednak znacznie mniej ciekawie przedstawia się sprawa jego refaktoringu<sup>3</sup>, co - jak historia dowodzi - najczęściej przypada w udziale innemu już, ale tym razem biegłemu i sprawdzonemu w boju programiście, który przeklinając poprzednika stara się wywiązać z powierzonego zadania.

Tak więc w procesie rekrutacji programistów (i chyba nie tylko ich) należałoby się szczególnie wystrzegać osobników hołdujących bardzo niebezpiecznym metodom inżynierii programowania, jak cargo cult programming, voodoo programming, czy shotgun debugging.

Programistyczne sztuki magiczne

Cargo cult programming jest stylem niekompetentnego tworzenia kodu, zdominowanym przez nawykowe umieszczanie kodu lub struktur "na wszelki wypadek", co nie powoduje żadnych pozytywnych skutków. W rozumieniu programisty tego typu pociągnięcia służą zapobieganiu nieprawidłowościom, z którymi miał już niegdyś do czynienia i poprzez próby - niewiele mające wspólnego z logiką - udało mu się jakoś owe problemy wyeliminować. Tym samym doszedł do urojonego wniosku, że dodanie odpowiednich instrukcji programowych niweluje niewłaściwe zachowanie programu. W rzeczywistości, na dłuższą metę nie poprawia to niczego, a zachwaszcza jedynie kod. Jest to przykład kultywowania magii, która w ten sposób objawia się w oprogramowaniu. W rozumieniu tego programisty jest to logika. Obiektywnie rzecz biorąc to jest niestety tylko jego własna pseudologika<sup>4</sup>.

Voodoo programming polega z kolei na posługiwaniu się właściwościami lub algorytmami na zasadzie gotowych przepisów, których zasad działania się nie rozumie. Efekt jest taki, że może to działać lub nie, a i tak nie będzie wiadomo dlaczego. Wiara w magię jest tu znowu silniejsza od logiki. Na przykład włączanie wstawek w asemblerze do programu napisanego w języku wyższego poziomu nie jest niczym nagannym, pod warunkiem że zna się asembler i rolę, jakie owe wstawione fragmenty pełnią. Jeśli jest to jednak kod zaimportowany na zasadzie pobierania przepisu z książki kucharskiej, może on w pewnych okolicznościach sprawiać problemy, z którymi trudno będzie uporać się z racji niewiedzy.

Shotgun debugging to eliminacja pojawiających się błędów przez stosowanie przypadkowej korekty kodu. Programista niepotrafiący logicznie przeanalizować przyczyn błędów w swoim programie, stosuje różnego rodzaju łatki na chybił trafił, aż wreszcie - przez zupełny przypadek i nie wiadomo dlaczego - uda mu się wyeliminować ten błąd. Niestety, metody te najczęściej generują znacznie więcej nowych błędów niż poprawiają, a program aż jeży się od niepotrzebnych dodatków.

Każdy z piętnowanych tu stylów programistycznych jest objawem braku zrozumienia wykonywanych zadań. Można określać to różnymi zabawnymi epitetami, naśmiewać się ze zjawisk i ludzi je powodujących. Jedno jest pewne - wyznawcy tego rodzaju magii nie mają w zasadzie prawa nazywać się programistami i uprawiać tego zawodu. Niestety, rzeczywistość jest zgoła inna i w wielu przypadkach odbiorcy oprogramowania cierpią m.in. z powodu złej jakości kodu, wytworzonego przez "magicznych sprawców".

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200