poniedziałek, maja 18

gnije ale dlaczego

witam;

no to startujemy, pora opowiedzieć sobie co powoduje gnicie systemu;


Changing Requirements
Główna przyczyna degeneracji systemu jest bardzo dobrze znana. Wymagania które się zmieniają w taki sposób, że nie można ich w prosty sposób zaimplementować do pierwotnego projektu. Bardzo często zmiany muszą być bardzo szybko wykonane, często są wykonywane przez programistów nie będących przy tworzeniu pierwotnej wersji softu. Nie są oni wstanie wykonać poprawnie zmian ponieważ nie znają architektury. Zmiany do systemu nie są wprowadzane w czysty sposób dlatego też powodują akumulowania się kodu nie psującego do pierwotnej formy systemu.

Jednakże nie można obwiniać zmieniających się wymagać, o taki obrót sprawy. Każdy programista powinien być świadomy zmienności wymagań względem systemu.


Dependency Management
Jakie zmiany w projekcie powodują gnicie się systemu? Często zmiany wymuszają wprowadzanie nowych niezaplanowanych zależności pomiędzy klasami. Cztery symptomy wymienione w poście wcześniej wpływają bezpośrednio lub pośrednio, na to w jaki sposób są wprowadzane zależności pomiędzy klasami. Największym problemem w programowaniu obiektowym jest odpowiednie wprowadzanie zależności pomiędzy klasami, oraz odpowiednie zarządzanie tymi zależnościami. Programowanie obiektowe samo w sobie nie wspomaga tego mechanizmu, lecz istnieje kilka praktyk które pozwalają na dalszym etapie projektu wprowadzać zmian bez szkody dla niego.


… w kolejny postach przedstawię te mechanizmy, oraz na koniec pokażę zależność pomiędzy tymi praktykami.


ps. miłego czytania.

niedziela, maja 17

Symptoms of Rotting Design

solid czas rozpocząć;

Architecture and Dependencies
Aplikacja swoje życie rozpoczyna w umysłach programistów. Na początku posiada bardzo dobrą architekturę, prostotę, oraz zbudowana jest w oparciu o najlepsze wzorce programowania obiektowego.
Z systemem tak tworzonym zaczyna się coś dziać. Oprogramowanie zaczyna gnić. Początki nie są takie straszne, w jednym miejscu zastosuje się jakieś nie ładne rozwiązanie, w innym robi się jakiegoś sprytnego hacka, ale i tak nadal mówimy, że widać piękno pierwotnego projektu. Upływający czas powoduje, że ilość hacków w systemie wzrasta, a nasza prostota systemu zaczyna zanikać. System zaczyna posiadać coraz większy nieład w kodzie, a programiści uświadamiają sobie fakt, że zarządzanie kodem staje się coraz trudniejsze. Z każdą kolejną zmianą w kodzie trzeba zmieniać coraz więcej elementów systemu.


Symptoms of Rotting Design
Są cztery podstawowe symptomy po których można rozpoznać, że system zaczyna gnić. Nie są to zagadnienia przecinające się, ale powiązania między nimi są oczywiste. Podstawowe symptomy to rigidity (sztywność), fragility (kruchość), immobility (nie przenośność), viscosity (lepkość).

Ridigity (sztywność). System w którym jest bardzo trudno wprowadzać zmiany, nawet te łatwe. Każda zmiana pociąga za sobą dużą ilość zmian kaskadowych wynikających z zależności pomiędzy modułami. Zaczyna się to od tego, że zmiana które powinna zająć 2h, przeciąga się do 2 dni i powoduje zmiany w kilkunastu kalach w projekcie;
Kiedy system posiada takie symptomy programiści nie chętnie coś zmieniają i ograniczają się tylko do wprowadzania krytycznych zmian.

Fragility (kruchość). Blisko spokrewniona z sztywnością. Kruchość prowadzi do tego, że gdy dokonamy zmiany w jednym miejscu, system rozpada się w wielu miejscach. Często miejsca jakie ulegają uszkodzeniu nie mają bezpośredniego związku z miejscem zmiany. Sam problem nie pojawia się na etapie kompilacji, ale na etapie wykonania. Jeżeli problem ten zaczyna narastać to po pewnym czasie programistom towarzyszy strach. Wprowadzenie zmiany w jednym miejscu systemu może zepsuć każde inne bliżej nieokreślone miejsce. Jeżeli kruchość wzrasta może powodować wydłużanie się czasu wprowadzania zmian, ponieważ programiści zaczynają wykonywać nadmiarowe testy tylko, dlatego by uchronić się przed ewentualnymi problemami jakie zmiana mogła spowodować. Po pewnym czasie dbanie o system przestaje być opłacalne ponieważ nie wiadomo ile problemów może wprowadzić zmiana.

Immobility (nie przenośność)Immobility (nie przenośność). Pojawia się wtedy, gdy chce się wykorzystać projekt lub jego część w innym miejscu. Często zdarza się, że programista odkrywa to, że inni zrobili już coś podobnego i teraz można by wykorzystać gotowy kod. Ale gdy zaczyna się brać elementy które nas interesują okazuje się, że razem z nimi musimy wziąć bardzo dużo innych nie potrzebnych nam klas. Elementy dodatkowe nie są nam potrzebne, ale bez nich moduł nam potrzebny nie zadziała. Sytuacja ta powoduje, że dany fragment oprogramowania zamiast zostać użytym zostaje przepisany od nowa.

Viscosity (lepkość). Mówimy o lepkości projektu oraz systemu. Lepkość projektu pojawia się wtedy gdy zmianę można wykonać na więcej niż jedne sposób. Niektóre formy zmian są dłuższe, ale łamią pierwotnej architektury systemu, inne można nazwać potocznie hack. Jeżeli programiści wybierają dłuższe i leprze sposoby rozwiązywania problemu to nic strasznego się nie dzieje, ale może się tak zdarzyć, że presja klienta spowoduje zrobienie kacka. Oczywiście programista powtarza sobie, że zrobi hacks, puści release, a następnie rozwiązanie poprawi na porządne, tak się nigdy nie dzieje. Problemem w lepkości jest to, że zmiany łatwe które powinno się łatwo wprowadzać i nie powinny one łamać naszej pierwotnej architektury systemu, robią coś zupełnie przeciwnego.


Cztery symptomy o jakich napisałem są oznaką słabej architektury. Każda aplikacja posiadająca te oznaki zaczyna się psuć od środka. Ale co powoduje psucie się aplikacji, o tym napiszę w innym poście.

start.. SOLID

Witam;

mój pierwszy post o SOLID będzie przedstawieniem treści innych postów, po wykładzie Bruno Bossoli na GeeCON zostałem zarażony tą ideą, dlatego startuję z postami na temat kilku praktyk jakie należy stosować w programowaniu obiektowym(według tej metodologii); cały artykuł będzie się składał z kilku postów o treści: jakie są znaki, że nasze oprogramowanie zaczyna się psuć; następnie kilka powodów psucia się pierwotnego projektu aplikacji; opiszę 5 praktyk w osobnych postach; opisanie tych praktyk wyjaśni etymologię słowa SOLID;


ps. zaraz dodam kolejnego posta;

GeeCON 2009

Witam;

upłynęło trochę czasu od zakończenia konferencji; udało mi się odzyskać siły po nocnych wyprawach po Krakowie i postanowiłem podzielić się z Wami moim wrażeniami z GeeCON;
nie uda mi się opisać wszystkich wykładów, ponieważ na wykładzie były dwie ścieżki, a mi się jeszcze nie udało opanować technik replikacji:P, bym mógł obejrzeć całość; dwie ścieżki spowodowały to, że byłem w stanie zobaczyć tylko połowę wykładów;

no to startujemy;

Simon Ritter - JavaFX: The Platform for Rich Internet Applications
wykład zawierał kilka informacji na temat JavaFX jakie można znaleźć na stronie sun'a; pod względem merytorycznym wykład był zrobiony bardzo dobrze, ale jak dla mnie było zbyt dużo informacji statystycznych, wykład zakończył się małym show;

Alef Arendsen - Spring 3.0
fajnie było zobaczyć osoby które mają wpływ na wygląd Spring, ale pod względem merytorycznym nie było na wykładzie nic nowego czego nie można by było się dowiedzieć ze strony twórców;

Waldemar Kot - Liberate your enterprise Java applications from the Operating System
wykładowca jak zawsze merytorycznie przygotowany znakomicie, ale sama tematyka mnie nie interesowała spodziewałem się czegoś innego; tematyka mnie nie 'ruszyła' dlatego też nic na temat wykładu nie powiem;

Jacek Laskowski: Making EJB 3.1 development a breeze with Apache OpenEJB
na wykład udało się pełen sceptycyzmu, słyszałem wiele różnych opinii o Jacku Laskowskim, od bardzo pozytywnych po te bardzo negatywne; wykład zrobiony bardzo dobrze i po raz kolejny wybrałem tematykę która mnie do końca nie wciągnęła, informacje o OpenEJB były dobrze przedstawione, ale czy jest sens poznawania OpenEJB jeżeli mamy na rynku Sun EJB, Spring, Seam ???

Szczepan Faber: Great tests, less mocks, Mockito
Szczepan zaskoczył mnie profesjonalizmem, jak i ciekawą treścią wykładu, wykład przyjemnie się słuchało, oraz zawierał bardzo wiele informacji;

Hans Docter: Gradle
Hans Docker opowiadał, o nowym maven i ant; reasumując Gradle można być bardzo dobrym rozwiązaniem jeżeli proces budowania aplikacji jest skomplikowany;


dzień drugi;

Adam Bien: Java FX For Developers Not Designers
no i zaczęło się; wykład był taki jak lubię same konkrety, pełno kodu, mnóstwo slajdów i wykładowca posiadający ogromną;

Giorgio Natili: Blaze DS connectivity framework
nie było zbyt dobrze, przemilczę formę w jakiej był prowadzony wykład;

Paweł Wrzeszcz: Seam For Spring Developers
zacznę od wielkich braw dla prowadzącego, udało mu się przeprowadzić wykład bez rzutnika; wykład miał za zadanie przekonać programistów bawiących się w Spring'iem by spróbowali pobawić się Seam'e; sam Seam to bardzo fajna rzecz, należy go polecić każdemu kto miał 'szczęście' budować aplikację webową;

Bruno Bossola: SOLID design principles
na temat wykładu nie będę się rozpisywał, ponieważ pojawi się u mnie na blogu kilka postów związanych tematycznie z tym wykładem; jak dla mnie jeden z najlepszych wykładów jakie do tej pory było dane mi usłyszeć;

Lubomir Petrik: Sun Grid Engine
jak dla mnie pomyłka, że wykład o tej tematyce znalazł się na javowej konferencji;


no nic zakończył się sam GeeCON, pozostały tylko wspomnienia, dzisiaj bez zawahania polecił bym wam GeeCON 2010;



ps. czekajcie na posty o S.O.L.I.D;

wtorek, maja 12

java; joke;

witam;

przesyłam coś dla humoru http://www.ovisual.com/4/;

po przeczytaniu proszę o wybranie swojego ulubionego;


mój faworyt to: If you get a ChuckNorrisException you’ll probably die.