… na szczęście nie przez wszystkich. Intencją niniejszej serii jest przedstawienie podstaw programowania w trochę inny sposób, dlatego mówiąc najbardziej niedoceniana umiejętność w domyśle tyczy się to początkujących. Starsi albo sami dotarli do odpowiedniej wiedzy albo życie ich nauczyło.
Jak wyglądają pierwsze kroki w programowaniu? Po opanowaniu pętli for i foreach, ifów i caseów, Console.WriteLineów oraz tych wszystkich klas i obiektów i nie zapominając o polimofizmach wielu rzuca się w wir poznawania meandrów standardowo dostępnych bibliotek a potem przychodzi czas na biblioteki zewnętrzne.
Idylla trwa do czasu…
… kiedy coś trzeba zmienić a to coś to integralna część naszego Dzieła. Wtedy często okazuje się, że całość sypie się niczym domek z kart.
Dobra architektura to taka, która pozwala na przesunięcie decyzji biznesowych w czasie*
No właśnie. Dobra architektura pozwala na przesunięcie decyzji biznesowych w czasie, w dodatku możliwie jak najdłużej. A co rozumiem przez decyzje biznesowe tutaj? Są to decyzje typu czy używamy takiej czy innej bazy danych – a może nie użyjemy bazy danych. Czy użyjemy tej czy innej biblioteki do logowania. Czy nasza aplikacja ma byś dostępna przez www czy jako aplikacja desktopowa. Tego typu decyzji trzeba podejmować bardzo dużo w czasie tworzenia aplikacji, architektura, która pozwoli odwlec tą decyzję w czasie to dobra architektura.
Ale dlaczego odwlekanie w czasie jest dobre?
Odwlekanie w czasie jest dobre ponieważ wiele aplikacji, szczególnie tych dużych buduje się bardzo długo. Może się okazać, że np. biblioteka prezentacji danych, której używamy na początku pod koniec budowania aplikacji nie będzie już modna nie będzie już rozwijana. Nie znaczy oczywiście, że należy tworzyć aplikacje zupełnie bez bazy danych, bez logowania, bez interfejsu – znaczy to tyle, że należy tworzyć aplikację tak, aby te elementy były łatwo wymienialne.
Rober C. Martin, na którego się często powołuję i który jest moją inspiracją między innymi również do tego cyklu, popełnił (pośród wielu) aplikację FitNesse. Podczas jej tworzenia stwierdzili, że ponieważ jest to projekt webowy to muszą użyć MySql-a. Jednak zamiast natychmiast implementować na hura zapisywanie danych w MySql-u na początek stworzyli zapisywanie danych w formie tablicy haszującej zapisywanej do plików (w dużym uproszczeniu). Implementacja zapisu do bazy danych miało nastąpić później. Jednak z czasem okazało się, że zapis do bazy danych jest niepotrzebny a zapis do plików w zupełności wystarcza.
Co więcej, pojawił się po jakimś czasie człowiek, który potrzebował zapisu do bazy danych i architektura jaką stworzyli była tak elastyczna, że stworzenie kodu do zapisu do bazy danych wymagało jedynie jednego dnia pracy. Wyobraźcie sobie, że Wasze aplikacje można przepisać na inną bazę w jeden dzień… dla wielu, którzy nie zwracali uwagi na architekturę odpowiednio wcześnie dzisiaj nie mogą tego zrobić. Dodanie wsparcia dla nowej bazy wymaga u “Nich” dość często przepisanie całej aplikacji. Nie idźmy tą drogą. Coraz częściej klienci chcą aby aplikacją współpracowała z inną bazą niż tą z której my korzystamy (powodów mogą być dziesiątki). I choć baza danych nie jest tu wyjątkiem to jest to chyba jedno z częstszych ograniczeń z jakim muszą walczyć programiści.
*) podobnej treści tekst powiedział Robert C. Martin, niestety nie pamiętam dosłownego brzmienia – jednak to On jest inspiracją.
