Niniejszy post jest 200-tną notatką na blogu. Aż dziw bierze, że tak długo już prowadzę tego bloga (pierwszy wpis 26.01.2008). Wprawdzie 200 wpisów  na 4 lata to niewiele, to nie sądziłem, że tak długo będę to robić. Co bardziej ciekawscy pewnie i znajdą moje pierwsze podejście do blogowania z pierwszym wpisem z 7/14/2005 09:09:00 AM (wtedy nawet Visty nie było na świecie). Linka nie zamieszczam bo wiele z tamtego nie wyszło ;-).

Tak zacna i okrągła okazja zostaje niniejszym wykorzystana jako pierwszy z cyklu postów o podstawach programowania. Jednak nie mam zamiaru opisywać poszczególnych konstrukcji językowych ani też kolejnych bibliotek, nie będę również mówił o efektywnych algorytmach. Pisał będę o tym jak pisać aplikacje aby można było je długo i efektywnie rozwijać. Przejdę po zasadach SOLID (ale nie tylko tych 5 podstawowych), przejdę po TDD oraz kilku innych aspektach, które dadzą Ci szansę uniknąć błędów jakie doprowadziły niejedną firmę na skraj bankructwa.

Natchnieniem do napisania tej serii jest fakt, że na żadnej z trzech uczelni na jakich miałem przyjemność studiować nie usłyszałem słowa o tym o czym będę pisał. Usłyszałem natomiast o wskaźnikach, strukturach i zajebistości pięknie dziedziczenia. Nikt niestety nie mówił jak pisać programy.

W czym problem? Przecież każdy średnio rozgarnięty student potrafi pisać programy. Ci co bardziej rozgarnięci znają kilka języków, bibliotek, frameworków etc. Co więcej pracują i dostają za swoją pracę pieniądze.

Problem polega na tym, że piszą kod, który powoli ich przerasta. Z każdą dodaną linią staje się trudniejszy i bardziej zagmatwany.

“…ale przecież programowanie to trudna sztuka, było trudno napisać, musi być trudno zrozumieć”

nic bardziej mylnego. Problemy jakie rozwiązuje informatyka są wystarczająco złożone aby je jeszcze niepotrzebnie komplikować. Każdy problem jaki rozwiązujemy powinien odzwierciedlać złożoność esencjonalną czyli tą która jest istotą rozwiązywanego problemu ale nie powinien wnosić dodatkowej złożoności przypadkowej generowanej przez… uwaga, uwaga…

PROGRAMISTÓW

Spójrzmy na poniższy wykres.

image

Przedstawia on produktywność w czasie. Lewa strona to początek projektu. To ten piękny czas kiedy wybieramy File->New Project albo tworzymy nowe repozytorium lub zakładamy nowy katalog na dysku lub cokolwiek innego (bez względu na język programowania, platformę etc.). Od tego momentu zaczyna się życie naszego projektu. Pierwszą funkcjonalność zazwyczaj możemy napisać w kilka minut lub godzin, następną również, i następną i następną i….. niestety to nie rozwija się tak w nieskończoność. Po tygodniu lub miesiącu prace idą trochę wolniej. Nadal bardzo szybko ale już odrobinę wolniej. Kolejny miesiąc to kolejne spowolnienie…. itd. Z tygodnia na tydzień i miesiąca na miesiąc wprowadzanie kolejnych funkcjonalności staje się coraz trudniejsze. Ilość założeń, klas, zmiennych, funkcji, wymagań narasta do takiej ilości, że dodanie czegoś nowego staje się pracą na ugorze.

Dlaczego tak się dzieje? Bo przyszły skrzaty i zamieszały w kodzie? Bo inni członkowie zespołu to idioci nieuki. Bo klienci to idioci mają nierozsądne wymagania?

NIE !!! Bo tak to napisałem

Wracając do wykresu, na szczęście wykres nie spada do zera. Zawsze jesteśmy w stanie wprowadzić jakieś zmiany. Niestety w pewnym momencie koszt wprowadzania zmian jest tak duży, że zapada kosztowna (dla zarządu) a zarazem radosna (dla programistów) decyzja – zaczynamy nowy projekt. Wracamy do punktu wyjścia i……. ci sami idioci wspaniali programiści, którzy doprowadzili projekt nad krawędź zaczynają zabawę od początku. Niestety sporo firm nie jest wstanie wytrzymać takiej huśtawki i upada (przy ogólnej radości i aplauzie zarządu, programistów a przede wszystkim klientów)*.

Celem niniejszego cyklu jest obnażenie mechanizmów mogących prowadzić do powyższej sytuacji oraz pokazanie mechanizmów pozwalających zapobiegać temu.

 

*) sarkazm