16
Maj
07

Document Oriented Programming, wprowadzenie

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
Reklamy

15 Responses to “Document Oriented Programming, wprowadzenie”


  1. 1 Yacoos^
    Maj 16, 2007 o 5:57 pm

    Z niecierpliwoscią czekam na cz II 🙂 Tez mam czasem problem z kotletem 😛

  2. 2 activey
    Maj 16, 2007 o 6:00 pm

    Postaram się coś jutro naskrobać, no, najpóźniej do końca tygodnia 😛
    PS
    będą kotlety 😉

  3. 3 Yacoos^
    Maj 16, 2007 o 6:01 pm

    o ja! ale czas reakcji na komentarz 🙂
    /me is pod wrażeniem 😛

  4. 4 RG7
    Maj 16, 2007 o 6:36 pm

    A czy w poprzednich pracach teamy developerow stosowaly jakies meotdy wytwarzania oprogramowania? Np Extreme Prorgamming, SCRUM, etc? Ciekaw jestem.

  5. 5 activey
    Maj 16, 2007 o 6:45 pm

    Podane przez Ciebie metodyki nie mają tutaj niestety nic do gadania. Zarówno SCRUM i XP opisują jedynie iteracyjne modele cyklu życia projektu – innymi słowy: mówią w jaki sposób zarządzać projektem. Racja, to osoba odpowiedzialna za wykonanie projektu powinna zaproponować tą a nie inna architekturę ale …

  6. 6 prozz
    Maj 16, 2007 o 8:54 pm

    programowanie imperatywne != programowanie funkcyjne

    funkcje to haskell, imperatywne to pascal, c itp 🙂

    pozdro, moze wpadne na irca 🙂

  7. 7 activey
    Maj 17, 2007 o 6:46 am

    widzisz, plotę trzy po trzy 😛
    a jeżeli chodzi o irca – to mnie już tam nie ma od jakiegoś czasu, ale wpadaj, spoko 🙂

  8. 8 mkuczara
    Maj 17, 2007 o 7:14 am

    Wcale nie dziwie sie twoim znudzeniem, po paru latach developerki kazdego zdrowego i normalnego czlowieka dopada choroba zwana nuda. Jakkolwiek bys nie zmienial podejscia do problemu i tak skonczysz (jesli jestes klepaczem) w przewaznie nudnej (po kilku latach 99% roboty to nuda) implementacji. Mozna uciekac w ajaxy, sraksy etc ale i tak trzeba sie grzebac w gownie po uszy, szczegolnie ze przewaznei obecni absolwenci nie maja zielonego pojecia (sorry za generalizacje) o takim shicie jak js/client side yadda yadda.

    Sprawa imho jest prosta, programowanie zawsze bedzie mozolne jak praca na budowie, jedyna rekompensata jest otoczenie sie zespolem dziwnych ludzi , wtedy latwiej przetrwac 8h 🙂

    Jedyne wyjscie to zminic branze na bardziej pasjonujaca, tylko jak to zrobic jak sie dziecko planuje i kredyt?.

    PS. Wybaczcie gorzki ton postu, az tak zle mi nie jest, ale… hm, troche prawdy w tym jest

  9. 9 prozz
    Maj 17, 2007 o 7:18 am

    jo, zycie jest do dupy, howgh!

  10. 10 mkuczara
    Maj 17, 2007 o 7:20 am

    praca jest do dupy, zycie jest ok 🙂

  11. 11 activey
    Maj 17, 2007 o 7:21 am

    mró, owszem
    zamieszkać na tropikalnej wyspie i pokazywać turystom krajobraz z okna awionetki 😛

  12. 12 mkuczara
    Maj 17, 2007 o 7:42 am

    http://ask.slashdot.org/article.pl?sid=07/05/09/1728252 – dobry artykul,(a raczej komentarze)

  13. Maj 17, 2007 o 8:16 am

    moze nie zmieniac branzy a podejscie do pracy? ‚rich dad poor dad’ radze przeczytac nie zrazajac sie na amerykanski styl. jakis startupik wykombinowac i juz 🙂

  14. 14 tasman
    Maj 17, 2007 o 8:57 am

    wg mnie najważniejszy jest entuzjazm i zapał we wszystkim co robisz, przyznaję też go tracę m. in. poprzez powtarzalność wykonywanych zadań (jak zaczynałem chciałem przenosić góry i siedziałem kilkanaście godzin nad daną rzeczą, nie bo musiałam a chciałem) , najgorsze że takie odbębnianie 8 h dziennie pracy odbija się potem – człowiek się zniechęca czy to robiąc n-ty raz to samo, czy to patrząc na fatalny kod, któy trzeba poprawić, rozwiązanie: łatwego nie ma ale trzeba szukać, próbować nowych rzeczy, zmieniać, ulepszać, tchnąć w sobie choć odrobinę entuzjazmu i optymizmu i nie mam tutaj na myśli tylko rzeczy typowo programistycznych

    PS Bardzo ciekawy wpis, czekam na kolejne części

  15. 15 TOughman
    Styczeń 11, 2008 o 11:18 am

    Zycie….. no coz, obserwuje tu typowy kryzys wieku przedsreniego (25-30 lat) – rozwiazanie: plodzic dzieciaki…. ;-).

    Mozliwosci sa 2:
    1. Polubisz dzieci i robota przestanie Cie irytyowac jako zajecie o charakterze drugorzednym.
    2. Polubisz dzieci czesciowo…. i w robocie odnajdziesz nowe mozliwosci i spokoj ducha ;-).

    Dla nieplodnych lub nieprokreatywnych:
    1. Awans, zmiana firmy na wieksza, odejscie od kodu. Praca zwana koncepcyjna na poziome projektanta, architekta, mentora, itp. Czyli – fascynujace telekonferencje o niczym, spotkania z ludzmi ‚byznesu’, lepsze, choc zdecydowanie mniej wygodne odzienie, czasem kilka politycznych gierek z konkurentami w drodze na szczyt, mniej kodu = wiecej papieru do odbierania z drukarki, ogolnie….. jeeeeeeeeeszcze wieksza nuda.
    2. Po kilku latach, w wyniku narastajacej frustracji…. powrot do kodu ;-))).


Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

w

Connecting to %s


Reklamy

%d blogerów lubi to: