Każdy jest motylem na własną skalę ale każdy huragan kiedyś ucichnie...

W tym artykule nie znajdziecie cytatów ani odniesień do procedur (treść nie będzie porównawcza). Natomiast chcę dla czytelników większej ilości moich tekstów, przedstawić ciągłość mojego rozwoju – czyli pewną myśl która implikuje z marzenia „chcę programować” do rzeczywistości „programuję i żyję z programowania”.

Chcę tym tekstem ogłosić „koniec twórczości w mojej pracy i początek pracy rzemieślniczej” - co przez to rozumiem?:

Otóż w jednym ze swoich wcześniejszych tekstów zasygnalizowałem, że wyżej cenię sobie „programistę rzemieślnika” niż „programistę twórcę”. Rozumiem to teraz tak, że programista rzemieślnik ma ustalone (sprawdzone) metody pracy i oprócz nowych technologii programistycznych, porusza się po znanej sobie „przestrzeni biznesowej” rozumianej jako procedury, według których powstają Jego aplikacje.

Gdy czytałem artykuł Rogera Zacharczyka, rozpoznawałem w jego treści (częściach i poszczególnych zdaniach) znane mi z moich (nielicznych jak na razie) realizacji projektów etapy, według których tworzyłem aplikacje. Mimo, że tekst odnosi się w szczegółach do urządzeń mobilnych uznałem, że uogólnienie jego treści na projekty, które podejmuję do realizacji, będzie dobrym etapem zbierania moich deweloperskich doświadczeń programistycznych.

Autor przypomniał mi pojęcie „inżynieria programowania” i zasygnalizował, intuicyjnie (trochę) przeze mnie rozumiane elementy warsztatu programistycznego jako składniki tego terminu. Już wcześniej wspominałem o swoich próbach UML-owych i treść publikowana przez Linux+ utwierdziła mnie w tej drodze, oraz zachęciła do dalszego rozwoju tych umiejętności. Pozostanę w swojej pracy przy „eksperymentach” w tworzeniu kodu aplikacji, tym bardziej, że czytając ostatnio komentarze na temat szybkości działania i wymaganiach pamięciowych programów napisanych w języku Java uznałem, że mam pewne pomysły, które stosując rozwiązania znane z aplikacji pisanych w PHP w aplikacjach desktopowych (Java SWT) pozwoliły mi uratować wydajność (przy ograniczonej szybkości „maszyny Javy”) programu który napisałem dla swojego klienta. Po szczegółowy opis tego rozwiązania odsyłam do następnego mojego artykułu (pod tytułem: "Wydajność i wielkość obiektów interfejsu programów napisanych w Java (SWT) ").

„Inżynieria programowania” to tylko część tego co cenię w treści artykułu, pozostaje jeszcze dodać, że tekst wskazał mi drogę do uporządkowania swojej „pracy z klientem”. Jak dotąd po wyjaśnienia odnośnie szczegółów zadań, które ma realizować program „nękałem” klientów telefonami i krótkimi (mało treściwymi) spotkaniami – było to w moim przekonaniu nieprofesjonalne. Dlatego wskazanie mi kilku punktów w pracy koncepcyjnej i realizacji projektów, uporządkowało moje sposoby komunikacji i etapy pisania programów. Moja praca nie będzie już polegała na angażowaniu swojego czasu w rozmowy i oczekiwanie na konsultacje, tylko konkretnym pisaniu projektu, który posiada swoje założenia, zalety i wady oraz na koniec dostosowaniu programu maksymalnie do wyobrażeń i życzeń zleceniodawcy.

Jedno na razie jest mi obce – wymyślanie pomysłu, uznane przez autora jako podstawowy etap tworzenia programu bez zlecenia z zewnątrz. Napisze dlaczego:

jak na razie pracuję nad jednym programem „bez zamówienia”, który w przyszłości wprowadzę na rynek, ale... Ten projekt powstaje na podstawie mojej znajomości specyfiki pracy w sklepie internetowym – po prostu pracowałem kiedyś jako administrator takiego sklepu. I tu właśnie ważny szczegół - „pracowałem” - czyli znam czynności, zapotrzebowanie i specyfikę środowiska, które informatyzuję. Możliwe, że kiedyś „wymyślę” jakiś temat, ale przypuszczam, że jeżeli nie mamy (co najmniej) kontaktu bezpośredniego z potencjalnym przyszłym użytkownikiem, nie napiszemy mimo swojego doświadczenia w programowaniu aplikacji, która będzie konkurencyjna. Program, który powstaje bez kontaktu z „użytkownikiem końcowym” w przyszłości posłuży co najwyżej innym projektantom do zapytania: „czemu ten system dla klienta źle działa i co w nowym rozwiązaniu poprawić...”. Według mnie musimy pracować we współpracy z kimś, kto wyjawi nam jakie procedury są wydajne w jego biznesie i które błędy ma rozwiązać system informatyczny.