Clean Code

Witam,

dziś chciałem napisać kilka słów o książce Clean Code - Robert C. Martin. Nie będę się rozpisywał o książce, należy ją po prostu przeczytać.

Książkę podzielił bym z ważywszy na doświadczenie czytelnika w programowaniu. Osoby które to programują poniżej 1,5 roku lub bawią się tylko w programowaniem, niech potraktują książkę jako pozycje obowiązkową. Osoby programujące zawodowo mogły się spotkać z większością zagadnień w pracy codziennej.

Może nieskromnie, ale pozwolę sobie zaliczyć się do 2 grupy i większość zagadnień była mi znana ale czytanie książki to tylko przyjemność i bardzo fajnie było sobie odświeżyć informacje, poznawać nowe elementy pożądanego programowania i uporządkować zamglone elementy wiedzy.

Niektóre problemy dokuczają tylko pracującym w dużych projektach(30 > osób), dlatego też niektóre elementy przez osoby nie pracujące w takich projektach mogą zostać niedocenione.

The Differences Between Good Designers and Great Designers

Witam;

Zajęty pracą, oraz sprawami dnia codziennego nie mam czasu na nic twórczego(poza pracą ;p), ale dzisiaj w południe było mi dane przeczytać bardzo dobry wpis na stronie www.drawar.com. Wpis był interpretacją prezentacji 9 skills that separate good designers zrobioną przez Cameron Moll.

Prezentacja nie miała za wiele wspólnego z java, ale bez większych problemów można ją przenieść na nasze podwórko.

Pozdrawiam,
Arkadiusz Borek

ps. Ze strony prezentacje pobierzcie ją w wersji pdf, mnie design tej prezentacji bardzo zaciekawił.

KISS

Inżynierowie są perfekcjonistami. Interesują nas zawsze szczegóły rozwiązania, oraz schludność. Opracowując rozwiązanie musimy być pewni, że coś działa tak jak powinno. Często bywa tak, że posiadamy gotowe rozwiązanie, ale cały czas mamy niedosyt. Przecież każde rozwiązanie może być jeszcze szybsze, ładniejsze, wydajniejsze.

Posiadamy duża wiedzę która to umożliwi zoptymalizowanie naszego rozwiązania. Znamy np. wzorce programistyczne i umiemy je zaimplementować, przerabiamy nasza działając funkcjonalność zgodnie z wzorcem, przecież kiedyś może zostać rozszerzona, a nas wzorzec tak upraszcza proces rozszerzenia. Ale czy tak powinno być ??

Oprogramowanie jakie tworzymy ma spełniać wymagania klienta, jak często zdarza się nam zaimplementować jakieś wymaganie, ale przy okazji robimy pewne 'zbędę' rzeczy by nasze rozwiązanie było ładniejsze. Rozwiązywanie problemów prowadzi do poświęcenia 60% czasu implementacji wymagania biznesowego, a 40% zostaje zużytych zastosowania nowego wzorca, technologi.

Z pomocą przychodzi nam zasada KISS z wiki możemy się dowiedzieć, że:
KISS(ang. Keep It Simple, Stupid, czyli nie komplikuj, głupku) jest często wspominana przy dyskusji architektury lub szczegółów budowy projektów. Jej istotą jest dążenie do utrzymania eleganckiej i przejrzystej struktury, bez dodawania niepotrzebnych elementów. Doczekała się polskiego odpowiednika: BUZI (Bez Udziwnień Zapisu, Idioto), atrakcyjnego przez to, że nie tylko oddaje sens akronimu, ale i sam kojarzy się z angielskim pierwowzorem.

Spotyka się inne rozwinięcia KISS:
"Keep it Simple and Stupid" (to ma być proste i głupie),
"Keep It Small and Simple" (to ma być małe i proste),
"Keep It Short and Simple" (to ma być krótkie i proste),
"Keep It Sophisticatedly Simple" (upraszczaj, ale nie posuwaj się do prostactwa).


Chciałbym by zasada ta w oryginale prześwietlała nam zawsze, jak że to ułatwi późniejsze otrzymanie kodu.



ps. Albert Einstein miał swoją wersję zasady KISS: "Wszystko powinno być tak proste, jak to tylko możliwe, ale nie prostsze."
— (1879-1955)

Refaktoryzacja to...

witam;

Postawiłem sobie osobiście cel pisania o JavaFX, nawet rozpocząłem jakieś przymiarki, ostatecznie miałem napisać kilka słów o JSF + Seam, ale pewnego dnia udało mi się przeczytać książkę o czymś innym ...

Refaktoryzacja to zmiany wewnętrznej struktury kodu programu, które mają za zadanie zwiększyć czytelność oraz obniżyć koszt wprowadzania zmian. Mówi się że, poprawnie przeprowadzona refaktoryzacja nie zmienia sposobu działania aplikacji od strony użytkownika.

Ta prosta definicja pozwala zapoznać się terminem refaktoryzacji, ale formalna definicja podana przez D.Roberts'a w 1998 ma postać:

R = (pre; T; P)

gdzie:
- pre - asercja która musi być spełniona by przekształcenie R było prawdziwe;
- T - transformacja kodu programu;
- P - funkcja przekształcająca warunki początkowe na warunki końcowe, określa warunki końcowe, które są prawdziwe po przeprowadzeniu transformacji T;

Refaktoryzacja ma za zadanie wprowadzić zmiany w nasz kod, ale zmiana struktury programu może stanowić dla niego ogromne zagrożenie, jeżeli by po jej zakończeniu program miał działać inaczej. Dlatego najważniejszym warunkiem poprawnie przeprowadzonej refaktoryzacji, jest zapewnienie, że nie wprowadzi ona żadnych zmian do działa aplikacji;


Ale jak można zweryfikować poprawności wprowadzanych zmian, istnieją dwie metody weryfikacji poprawności przekształceń:

• analityczna - wykorzystanie statycznych informacji; metoda nie wymaga uruchomienia programu
• dynamiczna - weryfikacja przeprowadzana przy pomocy testów; wymaga uruchomienia aplikacji

Podział metod weryfikacji poprowadził do powstania podziały przekształceń na:

• proste - najczęściej zautomatyzowana weryfikacja przy pomocy IDE
• trudne - weryfikacja wymaga testowania przy pomocy własnoręcznie napisanych testów

Oczywiście w prawdziwym świecie nie jest łatwo i dlatego liczba przekształceń trudnych jest o wiele większa niż występowanie przekształceń prostych;


Dalsza część posta będzie parta o publikację Martin Fowler Refactoring: Improving the Design of Existing Code w swojej książce przedstawił podział przekształceń ze względu na sposoby weryfikacji:

• proste (ok. 22) - można zweryfikować analitycznie
• trudne (ok.50)
• testowalne (ok. 25) - wymagają z góry znanych testów
• nieokreślone (ok. 25) - wymagają dedykowanych testów

Fowler zdefiniował pojęcie bad smell czyli jeżeli coś źle pachnie należy to zmienić. Pojęcie jest luźną definicją dlatego też obejmuje najróżniejesze problemy związane ze strukturą kodu. Dlatego też lista bad smells obejmuje wiele niespokrewnionych ze sobą problemów.

Problemów takich jak:

• Dublicate Code (Z duplikowany kod)
• Long Method (Długa metoda)
• Large Class (Nadmiernie rozbudowana klasa)
• Long Parameter List (Długa lista parametrów)
• Comments (Nadmierne komentarze)
• Incomplet Library Class (Niekompletna klasa biblioteki)
• Switch Statements (Skomplikowane instrukcje warunkowe)
• Message Chains (Łańcuch wywołań przez delegację)
• Data Class (Klasa z danymi)
• Data Clumps (Zbitka danych)
• Refused Bequest (Odrzucony spadek)
• Inappropriate Intimacy (Niewłaściwa hermetyzacja)
• Lazy Class (Bezużyteczna klasa)
• Feature Envy (Zazdrość o funkcje)
• Paraller Inheritance Hierarchies (Równoległe hierarchiczne dziedziczenie)
• Middle Man (Pośrednik)
• Divergent Change (Zmiany z wielu przyczyn)
• Shotgun Surgery (Odpryskowa modyfikacja)
• Speculative Generality (Spekulacyjne uogulnienie)
• ... obiecuje, że za jakiś czas pojawi się opis wszystkich bad smells

Po tak 'pięknej' liście należy się zastanowić jak znajdować bad smell. Z tym problemem nie pozostajemy sami istnieje kilka źródeł, które mogą dostarczyć danych o ich obecności:

• intuicja programisty, która jest niemierzalna i trudna do zdefiniowania, a jednak pełni bardzo ważną rolę w identyfikacji złych praktyk obiektowych


• metryki, które są podstawowym mechanizmem ilościowej oceny jekości projektu. Metryki dostarczają liczbowej i łatwej do zinterpretowania informacji o wielu aspektach jakości projektu


• analiza Abstrakcyjnego Drzewa Składowego AST, które jest graficzną reprezentacją rozbioru gramatycznego programu. Obecność lub brak określonych elementów w drzewie AST wskazuje na obecność lub wyklucza obecność niektórych zapachów


• informacja o innych zapachach pozwala wykorzystać znane już fakty o innych przykrych zapachach


• analiza dynamiczna, która pozwala określić atrybuty programu nie dające zidentyfikować wyłącznie poprzez analizę statyczną. Przykładem analizy dynamicznej może być wykonanie przypadków testowych


• historia zmian kodu pochodząca z repozytorium zarzadzania konfiguracją pozwala ocenić wpływ niektórych zmian na program

Słowem podsumowania...
może post jest przydługi, ale mam nadzieję, że zawarte informacje w nim komuś się przydadzą. Mi pozwolił nazwać rzeczy które od dawna robiłem.