Ze względu na to można także podzielić samo programowanie na kilka obszarów zainteresowań wymagających znajomości nieco innych zagadnień. Ktoś, kto tworzy interfejs użytkownika, nie musi koniecznie znać skomplikowanych algorytmów zamiany kartofla w płytę chodnikową, za to powinien dobrze orientować się w ergonomii, umieć wymyślać intuicyjne rozwiązania nawigacyjne, oprogramować je i nadać estetyczny wygląd, jeżeli zachodzi taka potrzeba. Z drugiej strony programista odpowiedzialny za silnik musi umieć udostępniać zasoby pozostałym elementom programu oraz wiedzieć, jak prawidłowo rozdzielać między nimi zasoby. Poniekąd to od niego zależy też ogólna wizja funkcjonowania całej aplikacji, ponieważ to, co program będzie w stanie zrobić i jak daleko będzie można go rozbudować bez utraty spójności, wynika z podjętych przez niego decyzji projektowych. Jeszcze inne zadanie czeka na osobę zajmującą się przetwarzaniem danych. Musi ona przemyśleć, gdzie i w jakim formacie będzie najwygodniej przechowywać informacje. Jak zaprojektować mechanizmy ich udostępniania, aby pozostałe części otrzymywały to, czego potrzebują w rozsądnym czasie. Jest to jeden z możliwych sposobów rozdziału zadań w czasie tworzenia programu.

Czasem spotyka się także inny podział, który jednak moim zdaniem nie sprawdza się, jeżeli nie jest wsparty czymś jeszcze. Mówię tu o sytuacji, gdy spotyka się grupa ludzi zamierzających np. zrobić stronę internetową i dzielą się oni zadaniami: "Ty robisz newsy i artykuły, ty forum, ty panel administracyjny". Zaletą takiego podejścia jest z pewnością czas - wszystkie elementy, które użytkownik końcowy jest w stanie zobaczyć, powstają równocześnie. Jednak zauważmy, że aby projekt był spójny, każda z osób musi przestrzegać pewnych jednolitych wytycznych dotyczących interfejsu, metod przekazywania informacji itd., a te nie zawsze powstają. Ostatecznie także jeden z nich i tak powinien przygotować silnik, na którym reszta oprze swój kod, gdyż inaczej wszystko się rozjedzie. Zatem bez zastosowania przynajmniej w pewnym stopniu poprzedniej metody podziału zadań takie podejście nie zdaje egzaminu.

Zespoły programistyczne rzadko kiedy są tak duże albo tak zróżnicowane, aby sprostać tym wszystkim zadaniom. Inna sprawa, że opracowywanie za każdym razem wszystkiego od zera to robota głupiego. W światku PHP i nie tylko obchodzi się ten problem, budując aplikacje na gotowych zestawach bibliotek i innego kodu - frameworkach. Ponadto, jeżeli dany framework czegoś nie obsługuje, często jest szansa, że można wspomóc się niezależną biblioteką, a cały koszt ograniczy się jedynie do jej zintegrowania z resztą projektu, co jest jeszcze akceptowalne. Otrzymujemy w zamian rozwiązania i jednolite wytyczne, które zostały przez wielu już sprawdzone w praktyce i (mamy taką nadzieję) dobrze zaprojektowane oraz stabilne. Nam pozostaje napisać już tylko to, czego nasz klient potrzebuje i podać to w ładnym opakowaniu. Sytuacja, gdy jeden programista pracuje nad dwoma diametralnie różnymi częściami i musi nagle przerzucić się, by napisać brakującą klasę do silnika, w większych projektach ma poważne konsekwencje. Aby zdążyć z terminami, powstaje często nieprzemyślana prowizorka. Fakt, takie często trzymają się najdłużej (czego przykładem jest ten blog :D), ale gdy gra idzie o duże pieniądze, jest to sytuacja nie do zaakceptowania.

Doszedłem do wniosku, że warto przemyśleć, który rodzaj programowania sprawia nam najwięcej satysfakcji i w którym osiągamy najlepsze rezultaty. Sam do tej pory opracowywałem niemal cały kod projektu samodzielnie - od silnika po końcowe szlify interfejsu, nawet gdy cała reszta świata migrowała w kierunku rodzących się, jak grzyby po deszczu, frameworków. Teraz już wiem, dlaczego. Po prostu znacznie bardziej lubiłem pisanie wewnętrznych mechanizmów: silnika, bibliotek wspomagających, struktur danych, zaś interfejs robiłem, bo ktoś musiał, a poza mną byłem tylko ja. Oczywiście prowadziło to do kuriozalnych sytuacji, gdy nagle dowiadywałem się, że muszę np. zrobić do serwisu internetowego szatę graficzną, bo klient korzystając z jakiejś logiki alternatywnej doszedł do wniosku, że skoro umiem sprawić, że komputer coś sam z siebie wykona, to jestem mu też w stanie zrobić elegancką, webdwazerową szatę graficzną z oszałamiającą nawigacją, AJAX-em i szeregiem innych głupot. Tymczasem szaty graficzne umiem robić, jakie umiem. Rozwiązania nawigacyjne, które mi odpowiadają i dla mnie są intuicyjne, nie zawsze są do przełknięcia dla przeciętnego internauty. O ile w przypadku roboty na własne potrzeby jestem w stanie coś takiego zaakceptować, to nie widzę powodu, dla którego klient dający pieniądze ma nie otrzymać zaprojektowanego optymalnie pod tym względem produktu. Brak starań w tym kierunku z mojej strony wynika też z niechęci do XHTML/CSS/JavaScript wywołanej przez pewien znany i nielubiany produkt firmy Microsoft.

Wniosek jest prosty: zajmę się tym, co lubię i umiem robić. Jeżeli już ktoś mnie kojarzy, to z powodu Open Power Template'a i ewentualnie kilkudziesięciu artykułów, a nie jakiegoś serwisu, który wykonałem. Myślę, że niedługo OPT nie będzie jedyny w tej kolekcji, bo pomysłów mam tyle, że już się nie mogę końca sesji doczekać. Na PHP nie zamierzam poprzestawać. Od pewnego czasu interesuję się głębiej działaniem i budową systemów operacyjnych, interpreterów i kompilatorów. Spojrzałem przychylniejszym okiem na język C i okazało się, że jakby tak odpowiednio do niego podejść, to w tym się nawet wygodnie da programować. Skoro już od pewnego czasu nad drzwiami pokoju widnieje karteczka "Specjalista od spraw głupich i beznadziejnych", pora ostatecznie obrać właśnie taki kierunek. W końcu programistów, którzy składaliby oprogramowanie z frameworków i bibliotek dla tysięcy potrzebujących, są setki, a te frameworki itd. same się przecież pisać nie będą. Ktoś może zapytać: "Człowieku, a jak ty frameworkami cokolwiek zarobisz?" Prawda jest taka, że jak się chce, to można. Olać pracę w pojedynkę, zebrać paru zaufanych ludzi o różnych specjalizacjach i zacząć działać wspólnie. Źródłem dochodu mogą być także biblioteki i inne projekty open-source. Wiele firm funkcjonuje w oparciu o podwójne licencjonowanie oraz udzielanie szerokiego wsparcia technicznego, co dodatkowo poszerza zakres zastosowań - osoby, którym z różnych powodów licencja (L)GPL nie odpowiada, mają teraz alternatywę i nie muszą rezygnować z powodów prawnych. Wszystko jest do zrobienia, pod warunkiem odejścia od schematów, a to akurat wychodzi mi znakomicie.

Powrót

Na Zyxist.com panuje swoboda wyrażania opinii oraz krytyki pod dowolnym adresem. Jedyny warunek: musi być ona kulturalna i rzeczowa. Na chamstwo, prostactwo lub jawne obrażanie kogokolwiek nie ma tu miejsca i takie komentarze są bardzo szybko usuwane. Jeśli zamierzasz polemizować z treścią wpisu, wpierw uważnie ją przeczytaj.