Między programowaniem a pisaniem programów

Dzisiejszy wpis sponsorowany jest przez idee różnych rozmów na forach oraz najróżniejszych blogów poświęconych programowaniu i projektowaniu aplikacji. Jest to głównie moje własne podejście do rozróżnienia pomiędzy początkującym a zaawansowanym programistą - odzwierciedlone zwłaszcza w chwili, gdy wspomniany programista pracuje.

W karierze niemal każdego programisty występują dwa etapy podejścia do problemu, jakim jest pisanie kodu. Pierwszy etap, dotyczący zwłaszcza młodych programistów-pasjonatów, piszących dla siebie, uczących się i rozwijających, to koncentracja na fakcie programowania, pisania kodu. Wynikowy efekt ma mniejsze znaczenie, niż metoda czy sposób wykonania planowanego zadania. Często też, po napisaniu tego, co ciekawe i interesujące, programujący porzuca projekt, ponieważ nic ciekawego już w nim nie widzi.

Z drugiej zaś strony, po pewnym czasie i nabraniu doświadczenia, programowanie samo w sobie zaczyna być nudne. Jaka jest w końcu przyjemność z pisania super-wypas-wydajnego algorytmu łączenia strumieni wideo, skoro i tak nikt nigdy go nie użyje? Programista taki stwierdza, że programowanie jako takie nie ma żadnego sensu i zaczyna pisać programy. Czyli: jedyne, co się liczy to efekt - metoda, sposób wykonania zadania stają się kompletnie nieważne, ważne są wyłącznie rezultaty.

Jaka jest różnica pomiędzy tymi dwoma podejściami? W pierwszym przypadku liczy się metoda, sposób wykonania, droga. Programming-oriented programista koncentruje się przede wszystkim na tym, by jedna, konkretna część programu była wykonana perfekcyjnie. Przechwytuje i analizuje każdy wyjątek, sprawdza każdy rezultat funkcji, optymalizuje kod znak po znaku. Takie rozwiązanie sprawdza się świetnie przy pracy naukowej (opracowywanie nowych algorytmów) czy przy tworzeniu bibliotek - tak stworzone funkcje/metody są niezawodne, stabilne i szybkie. Programistę koncentrującego się na wykonaniu trudno jednak przekonać do rzetelnego, solidnego napisania prostych elementów aplikacji (UI, podstawowa funkcjonalność). Jeszcze trudniej przekonać go, aby zrezygnował z szlifowania kodu i przygotował coś szybko, co po prostu będzie działać.

Zupełnie inaczej ma się sprawa z program-oriented programistą. Dla niego ważne jest tylko i wyłącznie to, żeby tworzona aplikacja działała tak, jak ma działać. Nic mniej, nic więcej - jeśli specyfikacja mówi, że dla operacji zajmujących mniej niż 10 sekund aplikacja nie pokazuje paska postępu, to nie ma potrzeby męczyć się z obsługą wspomnianego paska w przypadku procesu zajmującego 9.3-9.92 sekundy. Jeśli program ma działać na jednej maszynie i korzystać z danych zapisanych w /var/ourapp/settings.xml - nie ma sensu męczyć się z szukaniem pliku z settingami, dodawać opcji zdefiniowania go przez parametr - zwykły hardkodowany string ze ścieżką wystarczy. Wspomniany typ programisty przygotuje dobrą i niezawodną aplikację, natomiast można się spodziewać, że żaden z jej elementów nie będzie dopieszczony w 100%.

Rzecz oczywista - te dwa podejścia są skrajne i każdy programista oscyluje gdzieś pomiędzy nimi. Co ciekawe - często konkretne podejście zależy od tematu czy dziedziny, której program dotyczy. Jak to dokładnie działa?

Steve jest programistą, pracującym dla małej firmy tworzącej aplikacje przeznaczone na komputery osobiste. Marzeniem Steve'a od zawsze była praca w Google - przy tworzeniu wyszukiwarki. Dnia pewnego, po urlopie, Steve otrzymał specyfikację aplikacji do zrealizowania. Program ma służyć do wygodnego przeglądania wszystkich zapisanych w komputerze elementów, wliczając w to indeksowanie i przeszukiwanie.

Po przygotowaniu projektu Steve zaczyna pracę - od wyszukiwarki i indeksera plików. Dokładnie, skrupulatnie przygotowuje najdrobniejsze szczegóły. Ponieważ jednak czas goni, zabiera się za zrobienie reszty - edytora, przeglądarki plików i instalatora - z nadzieją, że do wyszukiwania i indeksowania jeszcze wróci.

Po roku pracy Steve prezentuje skończony produkt - każdy z komponentów działa poprawnie, zgodnie z założeniami. W całym produkcie najbardziej wyróżnia się jednak wyszukiwarka i indekser - ponieważ pisząc tą część aplikacji Steve programował zamiast pisać program.

Prosty przykład, pokazujący też, jak powinno wyglądać podejście programisty do tworzenia aplikacji. Nieważne, czy piszesz program "do szuflady", na zaliczenie czy dla milionów użytkowników - zasada jest jedna. Program musi działać; program może być idealny. W trakcie tworzenia programu konieczna jest kocentracja na celu, na samym fakcie ukończenia go, zrealizowania planowego minimum. Jeśli jest czas, środki i możliwość, wtedy można pozwolić sobie na zabawę i szczegółową pracę nad jednym szczegółem implementacyjnym. Nieważne, co to jest - jeden świetnie przygotowany element znacznie poprawi wartość programu jako całości.

Gdyby tak nie było, Android nigdy by się nie wybił jako system mobilny. Jako całość, system zdecydowanie się nie wyróżnia - ot, kolejna platforma mobilna. To, co odróżniło Androida od innych mobile OS, to znakomita przeglądarka, obsługująca poprawnie zdecydowaną większość stron internetowych. Coś, co u konkurencji po prostu działało, tu działa dobrze. Podobnie było z DirectX (mowa o antycznych czasach, gdy do 3D kupowało się osobny akcelerator) - konkurencyjny OpenGL wtedy działał, robiąc wszystko, co robić powinien. DirectX został dopracowany, doszlifowany i działał lepiej - przynajmniej według użytkowników, którzy nie musieli nic doinstalowywać. Podobnych przykładów są setki, jeśli nie tysiące.

Wniosek stąd jest prosty: jeśli tworzysz jakiś program, pamiętaj, że kiedyś należałoby go skończyć. To jest priorytetem. Jeśli masz jednak czas i możliwość, żeby bardziej się przyłożyć do programu, zajmij się tą jego częścią, którą lubisz - efekt będzie lepszy, niż gdybyś starał się po kawałku poprawić każdy jego element. Przypominając jedną z zasad XP: 1. Niech to działa. 2. Niech to działa dobrze. 3. Niech to, co działa dobrze, działa szybko. Stosuj te punkty w podanej kolejności, póki masz czas.