Teraz będę nudził. Niemiłosiernie. Dobija mnie sposób, w jaki dzisiaj tworzy się oprogramowanie. Nudne jak flaki z olejem, naprawdę nie wiem, jak Wy to wytrzymujecie (tak tak, to do Was programiści). Jak długo można powielać ten sam kawałek kodu?? Czy tylko ja mam ochotę pokazać publicznie jakiego kotleta jadłem wczoraj? Czym to jest powodowane (nie mam na myśli kotleta)? Nie wiem … Ale chyba znalazłem przepis jak to zmienić. Wpis ten jest początkiem serii notek, które będą opisywały alternatywne podejście do programowania czegokolwiek, bez względu na specyfikę aplikacji oraz jej wymagania biznesowe/inne. No ale pod początku …

Wstępniak

Było już dużo:

• programowanie imperatywne – program podzielony jest na bloki, funkcje, które są wykonywane w tej a nie innej kolejności (…)
• programowanie obiektowe – program podzielony jest na klasy, interfejsy i relacje między nimi
• programowanie komponentowe – obiekty są elementami większych tworów i są pozornie reużywalne
• programowanie zorientowane na testy (Test Driven Development) – kod programu prawie że generowany jest przez fragmenty testów jednostkowych (ble)
• programowanie aspektowe (Aspect Oriented Programming) – galimatias z kodu powodowany modyfikacją tegoż poprzez twory nazywane aspektami, nierzadko w trakcie działania aplikacji (Runtime – i jak to debuggować?)

Powstało kilka paradygmatów, które doczekały się implementacji. Wszystko to było w miarę rewolucyjne i wystarczające aby sprostać wymaganiom stawianym przez rynki takie a nie inne. Wszyscy sie cieszyli, kasa się kręciła i nadal się kręci. Nadal używa się rozwiązań, które ktoś wymyślił wieki temu i jest pozornie OK. Pozornie.

Kwestia nr 1

Przeszedłem przez 6 różnych firm “z branży” i nie znalazlem różnic w postępowaniu. Każdy, ale to każdy, tworzy oprogramowanie dokładnie w ten sam sposób:

• wybór szkieletu aplikacyjnego – dzięki niemu mamy z głowy większość pracy już na starcie
• jeżeli aplikacja ma korzystać z jakiegoś źródła danych – wybór narzędzi(a), które ułatwią przełożenie obiektów biznesowych na relacyjną bazę danych (no cóż, chyba wszędzie obraca się relacyjnymi bazami)
• jeżeli planujemy wykorzystanie jakieś warstwy prezentacji – wybór odpowiedniego medium

Tak szczerze – wszystko mi się już znudziło. Przez 4 bite lata klepałem aplikacje WWW, szablon, formularz, obsługa żądania, odpowiedź, bla bla bla. I tak w kółko. Wszędzie tak samo.

Bardzo zastanawia mnie jeden fakt: dlaczego nikt jeszcze nie opracowal generatora takich aplikacji?? Tak wiem, istnieje pojęcie Model Driven Development, ale nie oszukujmy się – strasznie jest to biedne. Czy nie chodzi o to, żeby jak najbardziej uprościć sobię pracę? Czy programista jest skazany z góry na masochizm?

Kwestia numer 2

Buzz words. Strasznie dużo namnożyło się tego dziadostwa ostatnimi czasy. AJAX, Web 2.0, [tutaj ciąg innych, których nazw chwilowo nie pamiętam], SOA.

SOA.

SOA (Service Oriented Architecture) było okej do czasu gdy zajęli się nim marketoidzi. Bardzo fajny pomysł został sprowadzony do szeregu głupowato brzmiących definicji, jednak definicje te bardzo fajnie się sprzedają. “Nasz produkt jest świetny bo ma SOA”. Nieważne, że nie wie o czym gada, istotne, że ktoś inny to łyka bez pytania.
Czym tak naprawdę jest SOA? Jestem leń, więc przekleję kawałek własnej pracy dyplomowej, w której conieco o SOA napisałem:

Nie istnieje jedno spójne wyjaśnienie tego terminu, które było by akceptowane
przez producentów systemów i specjalistów SOA na całym świecie. Pojęcie
“zorientowany na usługi” istnieje już od jakiegoś czasu, tłumaczone było
zazwyczaj pod kątem przydatności przy rozwiązywaniu konkretnego problemu. Można
więc się domyślić, że definicji jest wiele. Jednak pewną niezmienną prawdą
dotyczącą SOA (która powtarza się w każdej definicji) jest przedstawienie SOA
jako paradygmatu sformułowanego w oparciu o pojęcie dekompozycji – system jest
lepiej skonstruowany oraz zarządzalny jeżeli jest zbudowany w postaci szeregu
modułów tworzących całość. SOA jest terminem opisującym model, w którym logika
biznesowa jest podzielona na mniejsze jednostki. Każda taka jednostka
funckjonuje w systemie rozproszonym, tak więc istnieje możliwość umieszczenia
jej gdziekolwiek, z dala od serca platformy, np. na zdalnej maszynie. Części
składowe są od siebie całkiem niezależne, co pozwala im ewoluować bez
negatywnego wpływu na pozostałe moduły.

Spróbujmy porównać podejście SOA do pozostałych, wymienionych we wstępniaku. Odrzucimy jednak rozwiązania archaiczne takie jak programowie imperatywne – sorry, to już chyba w ogóle nie wchodzi w grę. Skupmy się na różnicach pomiędzy programowaniem komponentowym, które to jest “rozwinięciem” pospolitego OOP, oraz architekturze SOA, której pojawienie się zapoczątkowało serię powstawania “odkrywczych” rozwiązań.

część druga wkrótce

A w części drugiej:

• różnice pomiędzy komponentami a elementami architektury SOA
• komponenty i usługi – dwa różne podejścia do projektowania
• cykl życia w środowisku rozproszonym dla obu przypadków