Radość tworzenia oprogramowania

Właściwość złożonych systemów

2012-02-01T10:54:00.001+01:00

Dzisiaj rano jadąc samochodem do pracy natknąłem się na dużo dłuższy korek niż zwykle. "No tak, przy takim mrozie pewnie wszyscy jadą szczególnie ostrożnie" - pomyślałem i powoli się turlałem Trasą Łazienkowską. Po kilkunastu minutach, w pewnym momencie zauważyłem z daleka, że na jezdni w przeciwnym kierunku był wypadek i policja oraz pogotowie robiły, co swoje. Na moim pasie nic się szczególnego nie działo. Niby nic, a jednak... Kierowcy najzwyczajniej w świecie zwalniali, żeby zobaczyć co się dzieje na drugim pasie. Nikt się nie zatrzymywał, tylko patrzyli, co się dzieje. I z tego powodu fragment, który zazwyczaj przemierzałem w 5 minut, zajął mi tym razem 20 minut. Po przejechaniu tego punktu ruch znacząco przyspieszył i przebiegał normalnie.

Dlaczego o tym piszę? Od razu dostrzegłem analogię do projektów programistycznych :) Przedsięwzięcia programistyczne - ludzie, architektura, procesy - to złożony system. Często niewielkie zmiany, pozornie nieistotne elementy mają ogromny, kaskadowy wpływ na to co się dzieje w projektach.

Być może o jeden punkt decyzyjny za dużo, za mało, brak lub nadmiar dokumentacji, brak asertywności lub przyzwolenia o mówieniu o błędach, brak ścisłej współpracy lub zbyt swobodna współpraca bez ustalonych reguł mogą znacząco zmniejszać efektywność całego procesu. Warto o tym pamiętać!

W przypadku ruchu drogowego sytuacja jest nieco prostsza, bo łatwiej ją zmierzyć - jest to prędkość i czas przejazdu na tej samej trasie. Nie mamy tego luksusu w projektach, gdzie zazwyczaj to, co jest realizowane nie jest tak powtarzalne. Jednak możemy przybliżać się do oszacowania i porównywania. Szacując zadania oraz dodając relatywną miarę złożoności zadań (funkcjonalności).
Mniej formalną metodą są punkty (points, story points), które są jednostką względną, służącą raczej do porównania złożoności różnych funkcjonalności, niż do dokładnej analizy złożoności (która jest niezwykle pracochłonna, a i tak pozostanie tylko prognozą). Bardziej formalną metodą (gdzie dużo precyzyjniej należy argumentować podane szacowania) mogą być kilkuczynnikowe metody szacowania i pomiar zadań za pomocą punktów funkcyjnych.

Wtedy możemy obserwować czy nasza prędkość się zmienia, jak wprowadzane zmiany mają na nią wpływ.

Dlaczego Agile nie zadziała

2011-12-09T10:13:00.000+01:00

Wprowadzenie metody z rodziny Agile nie jest w ogóle łatwe. Problemem zazwyczaj jest to, że menedżment powierzchownie dowiadując się o co chodzi, odbiera nową metodę jako obietnicę - od teraz w magiczny sposób wszystko zacznie lepiej działać. Nieważne, że mamy kiepskich ludzi i hołdujemy zasadzie "każdego specjalistę można zastąpić przez skończoną liczbę studentów". Nieważne, że kompletnie nie dba się o zarządzanie wiedzą i umiejętności w zespole, bo nigdy nie ma na to czasu. Nieważne, że osoby realizujące projekty są przerzucane między projektami - bo przecież chodzi o interdyscyplinarność i każdy się powinien we wszystkim orientować. Nieważne, że terminy ustala się apriori, z do końca niejasnych przyczyn lub zakłada się, że to jedyny sposób, żeby przekonać klienta, że jesteśmy profesjonalni, a w terminie się "jakoś zmieścimy". Nieważne, że nie znajdujemy czasu na to, aby utrzymywać architekturę i kod, bo przecież nie ma czasu na tego typu zbędne czynności.
Nieważne, bo przecież Agile obiecuje, że teraz będzie już tylko pięknie. Dokleimy etykietkę to tego co robimy teraz - niech się to nazywa np. "Scrum", zrobimy trochę więcej chaosu, bo przecież chodzi o zarządzanie chaosem - zatem każdy robi co chce i jak chce, przestajemy cokolwiek dokumentować. Przecież stosujemy Agile, wszystko się samozorganizuje.

I dlatego najczęściej Agile nie działa, bo ludzie, którzy po omacku go stosują lub menedżment, który wstępnie akceptuje korzyści z danego podejścia, stosują bardzo uproszczone myślenie - "Ok. Robimy Scrum. Ale tak naprawdę 8 z 10 elementów nam nie pasuje, więc wybierzemy sobie, to co pasuje (dwa elementy), a resztę będziemy robić tak jak do tej pory (czytaj wyżej).
I tak wszystko będzie tak jak było, albo gorzej.

ZATEM UWAGA: W takim przypadku nie należny, nawet nie WOLNO zacząć stosować Agile. Agile to zmiana, ogromna zmiana, to nie etykietka, która rozwiąże wszystkie problemy (w tym przypadku prawdopodobnie lepiej się sprawdzi butelka alkoholu).

Efektywne poznawanie tematu

2011-11-26T17:07:00.001+01:00

Tym razem temat nieco wychodzący poza projekty informatyczne. Ostatnio dużo robię tzw. pracy researchowej, gdzie muszę na bazie dużej ilości źródeł wiedzy zbudować spójny ekstrakt praktycznych informacji. Po dłuższej pracy w tym temacie napiszę o kilku wskazówkach, które miałem okazję wielokrotnie wykorzystywać.

Jeśli chcesz zbudować wiedzę na pewien temat np. continuous integration, technologia X.
Cel: chcesz naprawdę dobrze zrozumieć temat.
Założenie: Nie znasz nikogo, kto mógłby Cie naprowadzić na dobrą drogę ;-)

1. Przeprowadź spike'a* (maks. kilka godzin) odnośnie źródeł informacji - gdzie co możesz znaleźć i jaki jest poziom materiałów (wiarygodność i szczegółowość):
a) sprecyzuj pytania, na które chciałbyś znaleźć odpowiedzi;
b) w pierwszej kolejności wybieraj książki - jeśli są dobre, znajdziesz tam wiarygodne i uporządkowane informacje;
c) w drugiej kolejności wybieraj materiały akademickie (prace doktorskie, prace z konferencji) - zaletą jest wiarygodność, czasem jednak są nieuporządkowane, czasami (jeśli autor jest kiepski) jest to zwykłe bicie piany;
c) blogi i artykuły wiarygodnych osób w branży (rozpoznawalnych i uznanych);
d) unikaj w miarę możliwości forów, blogów i luźnych informacji, których źródeł (osób) nie kojarzysz - dużo się naczytasz, niewiele dowiesz.
2. Kiedy już określisz listę wiarygodnych źródeł - określ minimum, które jest Ci potrzebne.
3. Jeśli zaczynasz czytać tekst (i dotyczy on Twojego minimum), czytaj go bardzo dokładnie, nie idź do przodu, jeśli nie rozumiesz, tego co przeczytałeś.
4. Wielokrotnie się przekonałem, że lepiej dowiedzieć się mniej, ale mieć wiedzę jak brzytwa, niż przeczytać "o wszystkim" po łebkach.
5. Rób notatki! To jedna z najważniejszych składowych! Wiele osób czyta dużo, ale nie robi notatek. Notatki zmuszają Cię do dokładniejszego zrozumienia tego co czytasz. Żeby zrobić notatkę (zazwyczaj) musisz coś zrozumieć. Niech notatka będzie parafrazą (czyli Twoim własnym sformułowaniem), nie cytatem.

*Spike - ograniczony czasowo, krótki okres na zbadanie tematu (maks. 2 dni), który jest Ci obcy lub mało znany.

Trzeba zrobić miejsce...

2011-10-13T18:02:00.000+02:00

Z tomiku ... Poezja dla zaangażowanych w projekty

Trzeba zrobić miejsce

Nigdy nie ma dobrego czasu na pierwsze dziecko,
Nigdy nie ma dobrego czasu na drugie dziecko,
Nigdy nie ma dobrego czasu na budowanie domu,
Nigdy nie ma dobrego czasu na remont,
Nigdy nie ma dobrego czasu na ślub,
Nigdy nie ma dobrego czasu, żeby wprowadzić refaktoryzację,
I nigdy nie ma dobrego czasu, żeby zacząć pisać testy jednostkowe,
W każdym z tych przypadków, trzeba po prostu podjąć decyzję,
Zacząć to robić, a czas i środki się znajdą,
Bo będą musiały...

Klienci chcą być zwinni...

2011-10-10T15:25:00.000+02:00

Jedno z ostatnich spotkań, gdzie ustalam (MS) sposób współpracy z klientem (szczegóły celowo nieco zmodyfikowane lub usuniętę, jednak bazujące na rzeczywistym przypadku). Klient (K) mówi:
K: To bardzo poważne przedsięwzięcie i zapowiadają się poważne koszty, prawdę mówiąc nasz sponsor ma spore wątpliwości, co to tej sumy. Nie będzie w stanie jej wydać. Projekt jest dość innowacyjny i nie wiadomo, jak odpowie rynek...
MS: To nawet dobrze się składa, ponieważ możemy zaproponować inny sposób współpracy. Cały system to rzeczywiście spora inwestycja i dość ryzykowna, gdyż produkt zwyczajnie może się nie przyjąć. Przyjrzyjmy się co jest esencją systemu... być może to będzie część, która nam podpowie co dalej zrobić.
(kilkadziesiąt minut wspólnej analizy i dyskusji)
MS: Świetnie! Zatem XYZ to jest to, co przyciągnie klientów, wszystko inne jest wtórne. To nazywamy corem biznesowym tego systemu. Zatem zróbmy tak: zakontraktujmy tę pierwszą część, co do pozostałych części przedstawiliśmy zgrubne szacunki, po tych pracach okaże się, na ile są trafne. Ale co najważniejsze po wdrożeniu core przekonamy się, jak rynek reaguje i czy reaguje, zbierzemy informację zwrotną. Wtedy podejmiemy dalsze decyzje.
K: Ok. To wygląda całkiem obiecująco. Zaryzykujemy tylko 1/4 całej początkowej sumy. Ciekawa sprawa, muszę o tym porozmawiać ze sponsorem.
(... klient zarażony, a konkurencja bez szans, bo ofertująca w tradycyjnym modelu - a tymczasem koncept klienta się zmienił :)

Czas na szkolenie z asertywności!

2011-09-25T00:35:00.001+02:00

Tak się składa, że w poprzednim poście pisałem o asertywności w kontekście zarządzania czasem, natomiast analizując różne przypadki, z którymi miałem do czynienia, mogę z dużym przekonaniem stwierdzić, że brak asertywności (wliczam w to odpowiedni sposób komunikacji) jest przyczyną (źródłem) dużej części innych problemów w projekcie.
Weźmy za przykład presję. Zazwyczaj presja idzie z tak zwanej góry. Górą może być klient lub jakiś istotny dyrektor lub prezes (jakby mógł być jakiś nieistotny!). Presja ta jest zazwyczaj przenoszona na kolejne poziomy w dół aż dochodzi do zespołu projektowego (w typowym uogólnionym przypadku: klient/dyrektor=>kierownik projektu=>zespół projektowy).
I teraz uwaga powiem coś co może się niektórym nie spodobać, ale

TA PRESJA JEST POTRZEBNA!

Tak. Nie ma co psioczyć, że ktoś każe zrobić pracę w krótszym terminie. Z ekonomicznego punktu widzenia jest to bardzo rozsądne. Zresztą zgodnie z prawem Parkinsona , którego doświadczyłem wielokrotnie osobiście zarówno jako wykonawca jak i odbiorca czy obserwator, krótkie terminy są wskazane.
Nierozsądne jest poddawanie się tej presji. Jeśli masz przekonanie, że dany termin jest nierealny, powiedz to (asertywnie). Przygotuj się dobrze, przygotuj argumenty (pamiętaj o uwzględnieniu perspektywy swojego rozmówcy, a nie tylko Twojej) i przedyskutuj dlaczego to jest nierealne.
Bardzo często się przekonują, że kierownicy (czy inne osoby decyzyjne) są bardzo skłonni zaakceptować inne szacowanie, jeśli tylko jest ono dobrze uzasadnione. Choć również są i tacy, którzy nie są skłonni (ale nie oszukujmy się - jest ich może z 5%, więc jeśli myślisz, że to na pewno dotyczy Ciebie, to jest duże prawdopodobieństwo, że się mylisz!)

Jeśli więc zastanawiasz się, z czego się przeszkolić, to Twój typ powinien zmierzać w stronę asertywności ;-)

Klucz do zarządzania czasem

2011-09-23T00:24:00.000+02:00

Jest kilka tematów, które cały czas pojawiają się w mojej głowie i wraz z kolejnymi odkryciami przechodzę do kolejnego poziomu jego zrozumienia. Tak jest z "zarządzaniem czasem".
Moje obecne doświadczenie jest takie, że możesz doświadczyć owego "zarządzania czasem" na kilku poziomach głębokości:

1) Znajomość technik - tutaj masz do dyspozycji GTD, czy też tzw. klasyczne zarządzanie czasem. Po prostu technicznie jesteś w stanie zapanować nad tym co robisz, być może używasz jakiegoś narzędzia, jakiejś metody, potrafisz porozdzielać i poukładać swoją zadania w kalendarzu lub na liście TODO.

2) Świadomy wybór rzeczy ważnych i rezygnowanie z "szumu zadaniowego" czyli spraw mało istotnych - większość osób robi to co mają do zrobienia, tak jak leci, często robią to z przyzwyczajenia, bezrefleksyjnie. Nawet jeśli świetnie opanowałeś techniki, to niewiele Ci to pomoże. (więcej: http://msieraczkiewicz.blogspot.com/2010/08/hiperoptymalizator-czasu.html)

3) Kluczem do zarządzania czasem jest asertywność i komunikacja - to trzeci (najwyższy) w mojej typologii poziom. Nigdy nie pozbędziesz się wrażenia, ze masz zbyt mało czasu, jeśli nie jesteś odpowiednio asertywny - wobec szefa, znajomych, rodziny, siebie (sic!) i nie potrafisz tego odpowiednio zakomunikować, nie będąc ani agresywnym ani uległym. Tak to lakoniczne stwierdzenie. Ale niech to będzie koan, dla tych bardziej zainteresowanych :)

Czy będzie czwarty poziom? Niewykluczone ;-)

Dotrzymywanie terminów za wszelką cenę to błąd!

2011-08-04T12:17:00.001+02:00

Terminy są potrzebne. Nie ważne czy pracujesz w Scrumie (Agile) czy w metodyce wodospadopodobnej - jedno jest pewne - bez terminów brak mobilizacji. Mówi o tym tzw. prawo Parkinsona (nie wiem czy ma on coś wspólnego z chorobą wieku starczego).

Problem pojawia się w sytuacji, kiedy widać, że nie uda się dotrzymać terminu. Klasyczny sposób postępowania polega na brutalnym dotrzymaniu terminu za wszelką cenę! I to jest błąd!

Dlaczego? Zadaj sobie trud i poświęć kilka minut, że znaleźć ciemne strony dotrzymywania terminów za wszelką cenę ...

(Czas na znalezienie...Ci co nie lubią myśleć sami, mogą przejść natychmiast to następnego punktu ;-))

Oczywiście roztrząsane dookoła konsekwencje to:
- nadgodziny (szkodliwe dla psychiki i niewydajne - można się spierać),
- dług techniczny.

Jednak konsekwencje są straszniejsze:

Zespoły, które dotrzymują terminów za wszelką cenę nie uczą się!

Tzn. uczą się tego, że można pozwolić sobie na kiepskie praktyki, nieefektywny sposób pracy, brak asertywności, jeśli w okolicy terminu ponagina się czas pracy oraz przymknie (a w zasadzie zamknie) się oczy na jakość.
Od dziś będę nazywać to Stress-Driven Development :-)

Dotrzymywanie terminów utrwala złe praktyki realizowania projektów.

Oczywiście naiwnym byłoby twierdzić, że niedotrzymywanie terminu jest rozwiązaniem. Nie jest! Bo samo w sobie nic nie da! Potrzeba jeszcze narzędzi wyciągania wniosków i wprowadzania ich w życie.

Kiedy musisz stwierdzić, że nie zdążysz na umówiony termin: będziesz musiał o tym teamleada jeśli jesteś programistą, jeśli jesteś teamleadem - kierownika projektu, jeśli kierownikiem - klienta i/lub kierownika/dyrektora wyższego szczebla, jauććć to może boleć. Dlatego najczęściej tego nie robisz, wolisz być nieasertywny lub nagiąć swój czas lub swoje zasady, aby dotrzymać terminu. Ot cały mechanizm.
Jak zaboli (choć istnieją również mniej bolesne/bezbolesne metody) wtedy będziesz miał okazję rzeczywiście się czegoś nauczyć. Wtedy będziesz mógł się rzeczywiście rozwijać, wtedy będziesz miał motywację, aby zmienić proces, zamiast utrwalać jego nieefektywność.

O nazewnictwie słów kilka – metody (in progress)

2011-07-12T01:22:00.000+02:00

(Uwaga! Artykuł w trakcie rozwoju!)
Może temat wydaje się banalny i wyświechtany, bo któż nie wie, że trzeba tworzyć jednoznaczne, czytelne nazwy. Natomiast ciągle jest obszar bardzo zaniedbany. Ciągle zespoły są dalekie od zrozumienia, że to właśnie od nazewnictwa zależy najwięcej. Żadna refaktoryzacja nie ma takiej mocy, jak zmiana nazwy. To przede wszystkim nazwy, jeśli stosowane odpowiednio, tworzą tzw. samodokumentujący się kod, kreują jednoznaczny język w źródłach systemu, który tworzysz.
Temat opisany wprawdzie w Clean Code, ale nie tak konkretnie jak ja to widzę, nieco po wierzchu i z innej perspektywy.

Dzisiaj kilka słów o anatomii metody (funkcji). Każda metoda ma tzw. sygnaturę czyli nazwę, parametry oraz zwracany typ, kluczowe składowe z punktu widzenia refaktoryzacji, gdyż na czytelność składają się wszystkie trzy elementy – nie tylko nazwa.
Ponadto można powiedzieć, że są dwa rodzaje metod:
• zwracające wynik;
• niezwracające wynik.
Metody zwracające wynik
(Uwaga! Poniższe zasady nie dotyczą tzw. interfejsów typu fluent)

 
double computeSomeResult(int parameter1, double parameter2, int parameter3 …)

• nazwa metody zawsze konkretnie i jednoznacznie musi określać, czym dana metoda się zajmuje i musi z niej wynikać, co będzie jej wynikiem;
• sygnaturę metody twórz zawsze w kontekście klasy, w której się znajduje (nie powtarzaj nazwy klasy w nazwie metody);
• tym samym metody zwracające informacje o błędach powstałych podczas jej wykonania są antywzorcem (choć oczywiście jest śladowa liczba przypadków, kiedy taka strategia może być uzasadniona – zazwyczaj gdy pracujemy z kodem odziedziczonym); tej chorobie ulega wiele frameworków;
• wysoce karalne jest traktowanie parametrów wejściowych jako sposób na zwracanie wyniku, co najczęściej dzieje się w przypadku opisanym w punkcie powyżej;
• parametry metody współtworzą znaczenie z nazwą – muszą ją uzupełniać i być z nią zgodne.
Przykłady i komentarze
1)

 
List<Content> retrieveChildren(Content parentContent)

Ok! Nazwa sugeruje, że będą wyszukiwane dzieci parametru i taki też jest zwrócony typ.
Bardziej fluentowe wersje (TBD wyjaśnić co to):

 
List<Content> retrieveChildrenOf(Content parentContent)  
List<Content> childrenOf(Content parentContent)

Lub jeśli byłoby to adekwatne do kontekstu, metoda childrenOf mogłaby być składową klasy Content i wtedy jej sygnatura wyglądałaby:

 
class Content {
   List<Content> retrieveChildren() // ..
   // lub bardziej fluentowo
   List<Content> children() // ..
}

 
interface ContentProcessorResolver {
   //…
   /* @return zwraca listę treści dostosowaną do danego resolwera */
   public List<? extends Content> resolve(Content content);
   //…
}

Zła nazwa – sugerowałaby (w kontekście interfejsu, w którym się znajduje), że wynikiem będzie obiekt klasy ContentProcessor.

TBC…

Przypadek przekroczenia zakresu - Proste wprowadzenie do BDD cz. 4

2011-07-06T13:36:00.000+02:00

I na deser z JBehave, Behaviour-Driven Developement oraz kalkulatorem (jeee) ostatnia część.

Implementacja - Proste wprowadzenie do BDD cz. 3

2011-07-05T09:29:00.000+02:00

JBehave, Behaviour-Driven Development (BDD) ciąg dalszy, tym razem już implementujemy... i kilka ciekawych ficzerów narzędzia...

Have fun!

Pierwsza historyjka - Proste wprowadzenie do BDD cz. 2

2011-07-04T11:36:00.001+02:00

Odpalamy mózg... Odpalamy JBehave i jedziemy...

Proste wprowadzenie do BDD cz. 1

2011-06-29T09:34:00.000+02:00

Dzisiaj premiera screencasta, a w zasadzie pierwsze koty za płoty - eksperymentalne próby z blogowaniem wideo i taką formą dzielenia się spostrzeżeniami.

Na pierwszy ogień idzie Behaviour-Driven Development i JBehave. Narzędzie pozwalające bardzo poukładać sobie w głowie, jaką ścieżką przejść od wymagań do implementacji. W rolach głównych występują :) User Stories, Testy akceptacyjne, Test-Driven Development i JBehave. Razem będzie 5 filmów, teraz pierwsze dwa!

Oglądaj koniecznie w rozdzielczości 720p i na pełnym ekranie

Naturalny porządek refaktoryzacji pod lupą cz. 5 Ewolucja architektury

2011-06-29T01:28:00.000+02:00

Dalszym krokiem, na dużo wyższym poziomie abstrakcji i wymagającym dogłębnego zrozumienia systemu. Na bazie pojawiających się wzorców, rozwijających się obiektów dziedzinowych po pewnym czasie dostrzegamy konieczność modyfikacji architektury. Z pomocą mogą nam przyjść wzorce architektoniczne lub wprowadzenie innych mechanizmów architektonicznych. Na tego typu przekształcenia może się składać m. in.:

● wprowadzanie warstw;

● wprowadzenie lub zmiana O/RM;

● zmiana organizacji logiki biznesowej;

● wprowadzenie lub zmiana szkieletu aplikacji.

Często w systemach przyjmuje się, że stworzona raz architektura będzie doskonale spełniać swoje zadanie przez cały cykl życia produktu. Tymczasem zmienność wymagań oraz trudność stworzenia optymalnej architektury od samego początku powoduje, że założenia architektoniczne należy cały czas monitorować oraz wprowadzać ewolucyjne zmiany, tak aby powstające rozwiązania były proste. Sztywna, nie zmieniana architektura najczęściej prowadzi do powstawania rozwiązań trudnych w zrozumieniu, naszpikowanych obejściami.

Ciągła refaktoryzacja

Przedstawiony proces przedstawia koncepcję ciągłej refaktoryzacji, w której jest ona częścią prac projektowych na każdym poziomie – architektury, projektu, kodu. Nie jest wydzieloną fazą, samodzielną częścią – jest częścią integralną prac. Chcę zaznaczyć, że powyższy proces (mimo, że tak został przedstawiony) nie jest całkowicie liniowy. Często realizując jeden z późniejszych kroków należy wielokrotnie wracać do kroków wcześniejszych. Przedstawiona strategia przedstawia bardziej kierunek działań niż sztywny algorytm.

Naturalny porządek refaktoryzacji pod lupą cz. 4 Refaktoryzacja do wzorców

2011-06-29T01:24:00.001+02:00

Stosując dotychczasowe kroki zaczynamy mieć coraz bardziej kształtne rozwiązanie, jednak głównie to co otrzymujemy to metody pogrupowane w klasy. Nadszedł czas na zastosowanie zasad obiektowych (np. zebranych w SOLID). Analizujemy kod pod kątem powtarzalności, potrzeby elastyczności, zapachów kodu i wprowadzamy wzorce projektowe. Często tam gdzie mamy wiele metod o zbliżonym schemacie będzie można zastosować Template Method lub Strategy. Tam gdzie tworzymy złożone struktury, tam stosujemy wzorzec Builder. Tam gdzie mamy do czynienia z nieskomplikowaną maszyną stanową wprowadzamy State. Tam gdzie potrzebujemy polimorficznego tworzenia obiektów używamy Abstract Factory lub jej zdegenerowanej postaci Simple Factory.
Jeśli przyjrzymy się klasie TextObfuscatorMethods z przykładu, możemy zauważyć, że większość metod przyjmuje jako parametr przetwarzany tekst. Jest to sygnał, że te metody powinny być w klasie, która ma pole zawierające przetwarzany tekst. W zasadzie możemy odwrócić sytuację i w klasie TextObfuscatorMethods umieścić pole typu przetwarzany tekst, wtedy metody staną się praktycznie bezparametrowe. Tym samym klasa nabiera charakteru wzorca Builder.
Inną opcją, pod warunkiem, że chcielibyśmy uzyskać możliwość dowolnego składania przekształceń zaciemniających tekst (stosować je wybiórczo, w dowolnej kolejności, o czym chcielibyśmy decydować w czasie wykonania), wtedy można by zastosować wzorzec Decorator.
Wersja z Budowniczym wyglądałaby jak poniżej.

public class TextObfuscator
{
    private ObfuscatedTextBuilder builder = null;
    // ...
    public string Obfuscate(string text)
    {
        builder.NewText(text);

        builder.ChangeWordsOrderRandomly();
        builder.AddMeaninglessWordsRandomly();
        builder.RemoveSeparators();
        builder.AddSeparatorsRandomly();
        builder.RemoveSpaces();
        builder.ReplacePolishCharactersWithNonPolish();
        builder.ReplaceUpperAndLowercase();

        return builder.ToString();
    }
}
public class ObfuscatedTextBuilder
{
    // ...
    private List textParts = new List();
    public virtual void NewText(string text)
    {
        this.textParts = ParseTextForWordsAndNonWords(text);
    }
    // ...
    public virtual void RemoveSpaces()
    {
        for (int i = 0; i < textParts.Count; i++)
        {
            RemoveSpacesFromTextPart(textParts, i);
            RemoveTextPartIfEmpty(textParts, i);
        }
    }

    public virtual void AddMeaninglessWordsRandomly()
    {
        for (int i = 0; i < textParts.Count; i++)
        {
            if (ShouldAddMeaninglessWords())
            {
                textParts.Insert(i, TextPart.SpaceSeparator); i++;
                textParts.Insert(i, new TextPart(DrawMeaninglessWord(), TextPartType.WORD)); i++;
                textParts.Insert(i, TextPart.SpaceSeparator);
            }
        }
    }
    // ...
}

Naturalny porządek refaktoryzacji pod lupą cz. 3 Extract Method

2011-06-11T01:55:00.017+02:00

W następnym kroku przyglądamy się odpowiedzialnościom poszczególnych klas oraz metodom, pod kątem dopasowania do odpowiedzialności klasy. Najlepiej przeanalizuj wszystkie metody oraz pogrupuj je pod kątem wykonywania podobnych operacji. Szukamy dla nich miejsca w innych klasach lub w nowej klasie. Pamiętaj: jeśli w danej klasie istnieje znacząca metoda prywatna (dłuższa niż 3-4 wiersze), to metoda ta powinna znaleźć się w innej klasie.

W naszym przykładzie metody głównie skupiają wokół pojedynczych operacji mających na celu zaciemnianie tekstu oraz zapewniającym wykonanie operacji z pewnym prawdopobieństwem. Możemy wyodrębnić odpowiadające tym operacjom klasy TextObfuscatorMethods oraz Probability.

Kod po tej zmianie mógłby wyglądać tak:

public class TextObfuscator
{
    // ...
    public string Obfuscate(string text)
    {
        List<TextPart> parts = methods.ParseTextForWordsAndNonWords(text);
        methods.ChangeWordsOrderRandomly(parts);
        methods.AddMeaninglessWordsRandomly(parts);
        methods.RemoveSeparators(parts);
        methods.AddSeparatorsRandomly(parts);
        methods.RemoveSpaces(parts);
        // ...
    }
}

public class TextObfuscatorMethods
{
    // ...
    public virtual void RemoveSpaces(List<TextPart> parts)
    {
        for (int i = 0; i < parts.Count; i++)
        {
            RemoveSpacesFromTextPart(parts, i);
            RemoveTextPartIfEmpty(parts, i);
        }
    }

    private static void RemoveSpacesFromTextPart(List<TextPart> parts, int i)
    {
        parts[i] = parts[i].ReplaceContents(" ", "");
    }

    public virtual void RemoveSeparators(List<TextPart> parts)
    {
        for(int i = 0; i < parts.Count; i++)
        {
            RemoveSeparatorsFromTextPart(parts, i);
            RemoveTextPartIfEmpty(parts, i);
        }
    }

    public virtual void AddSeparatorsRandomly(List<TextPart> parts)
    {
        for (int i = 0; i < parts.Count; i++)
        {
            if (ShouldAddSeparator())
            {
                parts.Insert(i, TextPart.NewSeparator(DrawSeparator())); i++;
            }
        }
    }

    private bool ShouldAddSeparator()
    {
        return probability.ShouldBeDone(ADDING_SEPARATOR_PROBABILITY);
    }
    // ...
}

public class Probability
{
    private Random random = new Random();

    public bool ShouldBeDone(double probability)
    {
        if (probability < 0.0 || probability > 1.0)
        {
            throw new ProbabilityException("Probability should be in range [0.0, 0.1]");
        }

        return random.NextDouble() < probability;
    }
}

Czy myślałeś kiedyś o karierze trenera/konsultanta?

2011-06-07T11:02:00.001+02:00

Jako że nasza działalność (BNS IT http://www.bnsit.pl) nabiera coraz większego rozmachu, pojawia się miejsce dla osób, które są chętne, aby pracować z innymi w celu dzielenia się wiedzą i doświadczeniem oraz chcą wspierać zespoły w zwiększaniu efektywności pracy.
Zatem jeśli masz doświadczenie praktyczne w pracy na projektami programistycznymi, jesteś kompetentny w PRZYNAJMNIEJ W JEDNYM z następujących obszarów:
- wzorce projektowe
- dobre praktyki pracy z kodem (refaktoryzacja, czysty kod, obiektowość (SOLID, GRASP, interfejsy))
- test-driven development
- domain-driven design
- scrum (agile)
- komunikacja w zespole (w kontekście projektów programistycznych),
- zarządzanie czasem dla programistów,
- zarządzanie projektami,
- zarządzanie wymaganiami, analiza.

Ważna jest wiedza i doświadczenie projektowe, co do warsztatu trenera, jesteśmy w stanie odpowiednio do tego przygotować.

Jesteśmy głównie zainteresowani stałą współpracą. Aczkolwiek ewentualnie opcja współpracy od czasu do czasu też wchodzi w grę.

Pisz śmiało: m [kroppka] sieraczkiewicz [mauppa] bnsit [kropkka] pl

Naturalny porządek refaktoryzacji pod lupą cz. 2 Compose Method

2011-06-07T10:43:00.004+02:00

Compose Method

Analiza metod takich jak przedstawiona w części 1. najczęściej prowadzi nas do zrozumienia, jakie są główne punkty algorytmu zawartego w metodzie. I to jest właśnie kolejny krok – postaraj się podzielić dużą metodę na mniejsze kroki wyodrębniając je do osobnym metod (refaktoryzacja Extract Method). Tym samym pierwotna metoda będzie się składać z sekwencji wywołań metod składowych. Przy odpowiedniej konwencji nazewniczej uzyskamy kod, który czyta się jak książkę.

Przy okazji warto co nieco posprzątać – głównie wprowadzić zmiany w mało intuicyjnych nazwach. Przykład znajdziesz poniżej.

public class TextObfuscator
{
    // ...
    public string Obfuscate(string text)
    {
        String result = ChangeWordsOrderRandomly(text);
        result = AddMeaninglessWordsRandomly(result);
        result = RemoveSeparators(result);
        result = AddSeparatorsRandomly(result);
        result = ReplacePolishCharactersWithNonPolishCharacters(result);
        result = ReplaceUpperAndLowerCharactersRandomly(result);
        result = RemoveSpaces(result);
        return result;
    }
    public String RemoveSpaces(String text)
    {
        return text.Replace(" ", "");
    }

    public String RemoveSeparators(String text)
    {
        return Regex.Replace(text, SEPARATORS_REGEX, "", RegexOptions.CultureInvariant);
    }


    public String ReplacePolishCharactersWithNonPolishCharacters(String text)
    {
        return text
                .Replace("ą", "a")
                .Replace("ł", "l")
                .Replace("ę", "e")
                .Replace("ń", "n")
                .Replace("ż", "z")
                .Replace("ź", "z")
                .Replace("ó", "o")
                .Replace("ś", "s")
                .Replace("ć", "c")
                .Replace("Ą", "A")
                .Replace("Ł", "L")
                .Replace("Ę", "E")
                .Replace("Ń", "N")
                .Replace("Ż", "Z")
                .Replace("Ź", "Z")
                .Replace("Ó", "O")
                .Replace("Ś", "S");
    }

    public String ReplaceUpperAndLowerCharactersRandomly(String text)
    {
        String result = "";
        char[] textArray = text.ToCharArray();

        foreach (char currentCharacter in textArray)
        {
            if (ShouldBeUpperAndLowerReplaced())
            {
                result += ReplaceLowerAndUpper(currentCharacter);
            }
            else
            {
                result += currentCharacter;
            }
        }

        return result;
    }
    // ...
}

Naturalny porządek refaktoryzacji pod lupą cz. 1

2011-05-27T00:26:00.003+02:00

(Rozwinięcie tego wpisu powinno pojawić się w najbliższym SDJ http://sdjournal.pl/)

Refaktoryzacja to odwieczny (to chyba nie najlepsze słowo jak na krótki czas funkcjonowania dyscypliny inżynierii oprogramowania ;-)) problem - bo wszyscy wiedzą, że powinno się to robić, a nikt nie ma na to czasu.

Jak już zaczniesz refaktoryzować, najczęściej nie wystarczy po prostu refaktoryzać, bo łatwo wpaść w szał refaktoryzacji, który polega na refaktoryzowaniu wszystkiego i za wszelką cenę. Przedstawię poniżej strategię refaktoryzacji, która w sposób systemowy pozwala podejść do tego często niewdzięcznego zadania, jednocześnie przyczyniając się do ewolucyjnego rozwoju projektu i architektury. Podpowiada też, jak się zabrać za kod odziedziczony i zacząć go refaktoryzować. Oto magiczne punkty:

1. Zacznij od prostego rozwiązania, zgodnie zasadą Keep it simple stupid. Nie myśl zbyt dużo o wzorcach, o wprowadzaniu wszelkiej możliwej elastyczności.

2. Z dużych metod zaczynaj wyodrębniać mniejsze składowe metody (refaktoryzacja Extract Method). Dąż do realizacji wzorca Compose Method – niech Twoja główna metoda składa się z serii wywołań mniejszych metod.

3. Kiedy Twoje klasy będą składały się z dużej ilości małych metod, zacznij analizować odpowiedzialność klasy. Przesuń metody, które realizują inne odpowiedzialności do bardziej odpowiednich dla nich klas.

4. Z czasem zaczynasz dostrzegać, że w Twoich rozwiązaniach potrzeba elastyczności – zacznij wprowadzać wzorce projektowe, tam gdzie potrzeba.

5. Raz na jakiś czas (raz na kilka miesięcy przy większych projektach), analizuj to, co dzieje się z Twoim projektem. Architektura wymaga regularnego odświeżania i wprowadzania zmian, aby przystawała do pojawiających się wymagań.

Idea rysunkowa została zawarta we wpisie http://msieraczkiewicz.blogspot.com/2011/02/naturalny-porzadek-refaktoryzacji-idea.html

Załóżmy, że mamy napisaną klasę udostępniającą metodą służącą do zaciemniania tekstu, będącego parametrem metody. Przykładowy kod znajdziesz na poniżej.

public class TextManager
{
    private TextManagerHelper _hlp = null;
    // ...
    public TextManager(TextManagerHelper _helper)
    {
        this._hlp = _helper;
    }

    private Random rnd = new Random();

    public string Convert(string text)
    {
        String result = "";
        List<TextPart> prts = _hlp.Convert(text);

        for (int i = 0; i < prts.Count; i++)
        {
            if (prts[i].Type.Equals(TextPartType.WORD) && rnd.NextDouble() < 0.2)
            {
                if (i + 2 < prts.Count)
                {
                    TextPart t = prts[i];
                    prts[i] = prts[i + 2];
                    prts[i + 2] = t;
                }
            }
        }

        for(int i1 = 0; i1 < prts.Count; i1++)
        {
            if (rnd.NextDouble() < 0.2)
            {
                prts.Insert(i1, new TextPart(" ", TextPartType.NONWORD)); i1++;
                String[] wds = new String[] { "i", "a", "aczkolwiek", "poniekąd" };
                int ind = rnd.Next(wds.Length);
                prts.Insert(i1, new TextPart(wds[ind], TextPartType.WORD)); i1++;
                prts.Insert(i1, new TextPart(" ", TextPartType.NONWORD));
            }
        }

        String result2 = "";

        foreach (TextPart part in prts)
        {
            result2 += part.Contents;
        }

        result = result2;
        result = Regex.Replace(result, @"[\?!-\.,:;'\(\)]", "", RegexOptions.CultureInvariant);

        String result1 = "";

        for ( int i2 = 0; i2 < result.Split(' ').Length - 1; i2++)
        {
            if (rnd.NextDouble() < 0.5)
            {
                char [] chs = new char[] { '.', ',', '!' };
                int j = rnd.Next(chs.Length);
                result1 += result.Split(' ')[i2] + chs[j];
            }
            else
            {
                result1 += result.Split(' ')[i2] + " ";
            }
        }
        result1 += result.Split(' ')[result.Split(' ').Length - 1];
        result = result1;

        result = result
            .Replace("ą", "a")
            .Replace("ł", "l")
            .Replace("ę", "e")
            .Replace("ń", "n")
            .Replace("ż", "z")
            .Replace("ź", "z")
            .Replace("ó", "o")
            .Replace("ś", "s")
            .Replace("ć", "c")
            .Replace("Ą", "A")
            .Replace("Ł", "L")
            .Replace("Ę", "E")
            .Replace("Ń", "N")
            .Replace("Ż", "Z")
            .Replace("Ź", "Z")
            .Replace("Ó", "O")
            .Replace("Ś", "S");

        String result3 = "";
        char[] tArray = result.ToCharArray();

        foreach (char ch in tArray) {
            if (rnd.NextDouble() < 0.3)
            {
                char? newCh = null;
                if (Char.IsLower(ch))
                {
                    newCh = Char.ToUpper(ch);
                } else
                {
                    newCh = Char.ToLower(ch);
                }

                result3 += newCh;
            }
            else
            {
                result3 += ch;
            }
        }

        result = result3.Replace(" ", "");

        return result;
    }
}

C. D. N.

Czysty kod

2011-04-19T12:44:00.000+02:00

Toczą się filozoficzne dyskusje, czy czysty kod ma znaczenie i czy inwestować czas w jego czytanie.
Nie będę się włączał w tę dyskusję bezpośrednio. Mały przykład:

prawo!Drugie!LEHMAna..oPiSujezJAWiskO!ZNanE.w,dziedZiNachi,wiEluI!!FIzyKi!zwieKszaNieNiEuPOrzAdKOwAnia!.W,.ENtropII. ,aCzkolwIEK! PONIekAD.!mIAre..uplYwU pONieKAd..czasuAczkOLWiek,

wpROWadZAnIe.dozMian!A,!aczkolWIeK !aNazywaNyCH,opROgrAmOWaniA ,iczesto !i!!prOgreSywnyMizwyKLE.poniEkAd,!PIeRWotna.StrUkturEnarusza.a.!PRoGramU.kUMulaCja,Zmian a.TEN,I !prOcEs!,,i.Tylko,liCzba,nasiLA, ,AcZkoLwiek,powiaZaniIntErakCjI poniEkAD!!roZnymi!ponIekad!,I!pomieDzYModuLamiw,sYStemiEZWiEkSZasie!.a, co! ,a,utruDniAzRoZUmienIe!!A,!acZKolwiek!I!..go,takzE!jEgO..modYfikacje..dalsze,

a,.jeST!,I.pOniEsieNie..aLternAtyWa,i.dodatKowyCh,WtrakciE!,nAKlaDOw,PielEgnaCjI..POswiecOnycHaczkOlwiek! ,na a,czynNosCi. ,a!ANTYREGREsYWnE!upRasZczaNie,StruKTuRy!i!LepszE.wprowadzaNyChwKOmPoNowANieI,.Zmian. ,iw,IsTNIejACE.i, rOwnoWaga.a,.OPrOgrAMOwanIe!pomIedZy,CzynnoscIami.,A,,ProGRESYwnyMI,RegresywNymI.od!.zaLeZYilOscI!.i, I.,RodZaju!infoRmaCji! a,plynacEJzwrOtnEj,srodoWiska!aCzkOlwieKZe,Inaczej!aczkOlwiEK!.,sa..pOnIEkad AobSLUGiwANE,zAdanIaZwiazaNe.Z,!.aczKOlWiEk!napraWa.blEdow!.a.!a!z,.inaczej. aCzkOLWIek!rozsZerzeniamI,funKcjOnalnyMi.

Tak najczęściej wygląda nasz kod! A fe...!

Źródło: Wykład Bartosza Waltera o refaktoryzacji

Zasada 20/80 Reloaded

2011-04-19T10:46:00.001+02:00

Taki krótki wpis przyszedł mi do głowy.
Wiele osób zna i być może stosuje zasadę 20/80 (cały Agile na tym stoi!), która w uogólniona brzmi mniej więcej tak: "20% procent naszych działań generuje 80% efektów". Innymi słowy - "mniej więcej 20% tego co robimy, ma sens". Mocne, prawda? Proste?
Cholernie trudne! Bo jesteśmy przyzwyczajani i przyzwyczajeni do zapełniania czasu - żeby mieć poczucie, że cały czas robimy coś.
Ale nie o tym chciałem pisać. Chciałem zwrócić uwagę na fakt, że wiele osób (nie chcę używać słowa "większość", choć bym się nie pomylił zbyt wiele) niepoprawnie interpretuje to stwierdzenie.

Nie oznacza ono, że jak mamy 80% to już dalej nie warto poświęcać energii na dalszą pracę (projekt, release, funkcjonalność, zadanie, whatever)... ba! wtedy to już jest za późno! Właśnie zmarnowaliśmy ogromną ilość naszego cennego czasu. Bo co z tego, ze jest już 80% jeśli jest to zwykły shit, zadaniowa czy też funkcjonalna wata cukrowa!
Powyższa zasada oznacza: znajdź 20% tego czym warto się zajmować i jak to znajdziesz, to włóż w to 200% energii i zaangażowania. Resztę można olać, najlepiej renegocjując wykonanie "owej reszty".
Biznesowo: zamiast robić wielki system ze 100 ficzerami, lepiej zadać sobie pytanie, co naprawdę będzie użyteczne i co będzie używane i zrobić właśnie te 20 ficzerów.

P.S.
W DDD nazywamy to Core Domain! Zawsze bądź świadomy co jest Twoim corem! :) Zawsze zadawaj sobie pytanie, co jest Core w systemie, module, który robisz czy nawet funkcjonalności, którą realizujesz.

Jaka nazwa dla tej metody?

2011-02-25T01:28:00.005+01:00

public class OptionsAwareObject {  
    private Options options;  
      
    public void updateOptions(String fontName, int fontSize) {  
       options.setFontName(fontName);  
       options.setFontSize(fontSize);  
    }  
 }  
   
 class Options {  
   
    private int foregroundColor;  
      
    private int backgroundColor;  
      
    private String fontName;  
      
    private int fontSize; 
    // ...
}

Czy updateOptions to dobra nazwa dla tej metody? Oczywiście, że nie! updateOptions jest ogólną nazwą, która sugerowałaby całościową aktualizacji opcji. Tymczasem my aktualizujemy tylko informacje nt. czcionki. Odpowiedzialnością metody jest zatem zmiana opcji związanych z czcionką. Lepszą nazwą byłaby:

public void updateFontOptions(String fontName, int fontSize) {  //...

Antylitania do programistów

2011-02-25T01:08:00.001+01:00

Nienawidzę Was za to że:

skupiacie się nad tym jakie ficzery ma Wasze IDE zamiast skupiać się na tym, jakich ficzerów potrzebuje Wasz klient/użytkownik,
klepanie w klawiaturę nazywacie myśleniem,
hektolitry czasu wyrzucacie w błoto testując manualnie swój kod,
więcej czasu spędzacie na walkę z frejmłorkami niż na dostarczaniu wartości dla końcowych użytkowników,
kodujecie wiele godzin nie zadając sobie pytania "co ja tak naprawdę robię",
naiwnie wierzycie, że technologie i narzędzia rozwiążą wasze problemy,
naiwnie wierzycie, że dobry algorytm jest ważniejszy od dobrego zrozumienia wymagań,
naiwnie wierzycie, że Wasza intuicja wystarczy w tworzeniu dobrego kodu,
naiwnie wierzycie, że jesteście w stanie ogarnąć złożoność kawałka systemu z którym pracujecie,
zgadzacie się na nierealne terminy,
że piszecie kiepski kod, znajdując na to wiele racjonalizacji (bo nie ma czasu),
w głowach tworzycie fragmenty kodu mimo że jeszcze dobrze nie wiecie co trzeba zrobić,
domyślacie się co trzeba zrobić, zamiast doprecyzować,
bezmyślnie podążacie za technologią, której używacie,
nie rozumiecie narzędzi i technologii, których używacie,
zamykacie się w swoim kawałku kodu, zrywając kontakt ze światem,
sądzicie, że to wszystko wina kierowników lub klienta i nie jesteście w stanie z tym nic zrobić.

... mimo że kocham bo sam jestem programistą.

Call for ... code samples

2011-02-19T16:55:00.002+01:00

Chętnie przedstawiłbym ideę naturalnego porządku refaktoryzacji na przykładowym kodzie. Niestety (co jest oczywiste rzecz jasna) nie mogę użyć kodu produkcyjnego klientów, a nie mam czasu przygotowywać do tego celu przykładu. Ale być może ktoś miałby chciałby na ten cel przeznaczyć swój kawałek kodu, projektu, który nie ma zbyt dużych (w zasadzie żadnych) obostrzeń co do publicznej publikacji.
Główne założenie to musi być w kodzie co refaktoryzować ;-)

W razie zainteresowania proszę o kontakt m [kropka] sieraczkiewicz [AT] bns [kropka] it.

Naturalny porządek refaktoryzacji - idea rysunkowa

2011-02-15T20:45:00.001+01:00

Młody kierowniku/team liderze! Opamiętaj się!

2011-02-15T00:17:00.006+01:00

Chyba nie napisze nic nowego... ale to tylko fakt, że historia lubi się powtarzać... bezustannie (vide: Marsz ku klęsce).

Otóż
Często powtarzanym, tragicznym w skutkach, nieprofesjonalnym działaniem drogi kierowniku/team liderze jest zobowiązywanie się do mało realnych terminów.

Naiwnie proste, można by rzec oczywiste, a jednak powtarza się. Dobrze o tym wiem, bo sam popełniałem nieraz ten błąd. Dlaczego zobowiązujemy się do mało realnych terminów:
a) bo jest presja kogoś z zewnątrz (klienta, menedżera, dyrektora),
b) bo wytwarzam presję wewnętrzną (chcę pokazać, że jesteśmy naprawdę dobrzy),
c) bo kompletnie nie mam pojęcia (albo mam pojęcie ale tylko trochę), co rzeczywiście trzeba zrobić w projekcie,
d) ??? - proszę o podpowiedzi :)

Co do pierwszych dwóch podpunktów rozwiązanie jest (wydaje się) proste - potrzeba asertywności i zwykłej szczerości wobec siebie i wobec przełożonych, tudzież klienta. Ta trudność, szczególnie jeśli się zaczyna (lub ma się niewielkie doświadczenie), wymaga często wyjście poza strefę komfortu - powiedzieć, że się nie da (w tym czasie).
I oczywiście można napotkać opór/sprzeciw, ale też najczęściej można pokazać swój profesjonalizm, który w tym przypadku zdefiniowałbym jako "Nie zobowiązuje się do niekonkretnych czy nierealnych terminów".
Często słyszę pytanie: "A jak zrealizować projekt, w którym już wiadomo, że jest za mało czasu, że za mało ludzi, że niejasne wymagania. Jakie są najlepsze praktyki". Odpowiedź jest prosta "Nie zgadzaj się na to, a raczej - negocjuj". Pokaż dlaczego termin jest nierealny. Podziel pracę i oszacuj. Pokaż ryzyka. Nie zgadzaj się na obniżenie jakości ("Jakoś damy radę - zrobimy bez testów, bez definiowania kryteriów akceptacyjnych, byle działało").
Ustalony termin to nie jest koniec świata i najczęściej można go negocjować, tylko uzbrój się w argumenty, które Ciebie przekonują.
Sam jestem szefem. Nieraz zdarzało mi się chlapnąć jakiś termin, bez większego przemyślenia. Moi pracownicy często się do niego przywiązują - czasami nikomu nie przychodzi do głowy, żeby negocjować przesunięcie terminu. Czasami wystarczy krótka dyskusja i sprawa załatwiona. W tym świecie niemal wszystko jest negocjowalne! Ale często wymaga to odwagi! :) Sprawdźcie - jedną z głównych wartości związanych z Agile'em jest Odwaga. Wiecie dlaczego? :)

Co do trzeciego podpunktu - zacznij używać jakiejś metodyki :) Skorzystaj z pomocy doświadczonego mentora.

Kilka nowych koncepcji - Mantra architektoniczna, Design Retrospective, Współdzielony kontekst, Naturalny porządek refaktoryzacji

2011-02-09T23:16:00.009+01:00

Ostatnio wyewoluowało mi się w głowie kilka nazwanych koncepcji, a w zasadzie może po prostu je dobrze zrozumiałem :) Kilka notatek poniżej, które traktuje jako alpha draft ;-)

Mantra architektoniczna (ang. architectonic mantra)
To co dzieje się praktycznie w każdym projekcie to dryfowanie architektury, tak że po kilku (nastu) miesiącach trwania projektu mało kto w zespole jest w stanie dobrze określić, jakie operacje powinny być wykonywane np. przez kontroller (lub managedbean lub whatever), jakie przez obiekty dziedzinowe, jakie przez fasady, usługi. Z czasem mieszane są odpowiedzialności tychże klas i coraz trudniej z rozwojem systemu. Jedyną opcją w tym przypadku jest tzw. mantra architektoniczna, która jest wariacją nt. techniki zdartej płyty znanej z psychologii komunikacji. Polega ona na tym, że należy w prace zespołu włączyć ciągłe przypominanie jakie mamy w architekturze główne bloki i jakie są też ich odpowiedzialności. W tym przypadku również sugeruję zespołom, aby wprowadziły regularne spotkania (raz/mc, raz/sprint), które nazywam Design Retrospective podczas których zespół:
a) przypomina mantrę architektoniczną;
b) analizuje sytuacje, w których niejasne jest, gdzie powinny się znaleźć konkretne klasy, operacje, pola - na bazie tego co się działo ostatnio w projekcie
c) zbiera przypadki zdryfowania architektury i tworzy "program naprawczy"
d) podejmuje decyzję o świadomej restrukturyzacji architektury (to akurat rzadziej).

Współdzielony kontekst (ang. shared context)
Nie, nie, nie... bynajmniej nie chodzi tu o żadne wzorce projektowe czy architektoniczne. A o komunikację... Jak to powiedział Kent Beck gdzieś kiedyś "Większość problemów w projektach wynika z tego, że ktoś komuś czegoś nie powiedział". Zwolennicy Agile'a źródło problemów widzą w tzw. relay race, czyli przekazywaniu pracy między ludźmi (pewnie to znacie m. in. w takiej metaforze www.projectcartoon.com/).
Problem polega w tym, że w sytuacji przekazywania produktów (dokumentacji, kodu, wymagań itp.) pracy jednej osoby (grupy osób) innej, nie jest przekazywany kontekst informacji, który doprowadził do powstania tego produktu, często mylnie zakładając, że jest on nieistotny. Ja twierdzę, że jest kluczowy.
Ostatnio uczestniczyłem w takiej sytuacji. Jedna z osób dokonała wstępnej analizy wymagań i stworzyła podstawowy model systemu (model dziedzinowy). Mieliśmy przeanalizować ten model. Jednak nie posiadając kontekstu (pewne przymyślenia, wnioski, informacje, mikrodecyzje), który powstał w głowie osoby, która go stworzyła dość trudno na głębszym poziomie niż tylko poprawność UMLowa, ocenić poprawność modelu. Taką sytuację nazywam brakiem współdzielonego kontekstu.
Dopiero zaczęliśmy wspólnie analizować wymagania w projekcie (User stories) i wspólnie budować model od nowa. Doszliśmy do podobnego modelu (z kilkoma subtelnymi różnicami), jednak w czasie "wspólnej pracy" powstał współdzielony kontekst (czyli uspójnione przemyślenia i rozumienie tematu). Współdzielony kontekst umożliwia trafniejsze podejmowanie decyzji oraz efektywniejszą kontynuację prac. To dlatego w Agile'u tak duży nacisk kładzie się na ścisłą współpracę - aby budować współdzielony kontekst.
I stąd jedna przestroga: Nie zarzucaj nikogo produktem swojej pracy, będącej efektem wielu godzin działań i/lub przemyśleń, oczekując, że go dobrze zrozumie. Przynajmniej pójdź i razem z nim go (ten produkt) przeanalizuj i wytłumacz jak do tego doszedłeś. A najlepiej wypracowuj to wspólnie :) Oszczędzisz wiele pracy sobie i tej osobie, a w szczególności unikniesz wielu zniekształceń komunikacyjnych (które to właśnie generują bardzo dużo dodatkowej, niepotrzebnej pracy).

Naturalny porządek refaktoryzacji (ang. natural order of refactoring) albo inaczej co to naprawdę znaczy ewolucyjny design lub architektura.
Jest to temat na osobny artykuł, tutaj więc pokrótce.
Od pewnego czasu krystalizuje mi się koncept systematyzacji procesu refaktoryzacji od najniższego poziomu abstrakcji do najwyższego - naturalny sposób na ewolucyjny rozwój designu (projektu systemu).
Idea jest taka - zaczynasz od najprostszego rozwiązania, które następnie refaktoryzujesz (jeśli potrzeba) na różnych poziomach abstrakcji (w pewnym ustalonym porządku). Oto porządek przekształceń (rozpoczynamy od niskopoziomowych).

0. Transformacje (triangulizacje) - jeśli używasz TDD (http://cleancoder.posterous.com/the-transformation-priority-premise)
1. Refaktoryzacje typu Compose method (http://www.industriallogic.com/xp/refactoring/composeMethod.html) (czyli seria refaktoryzacji typu Extract method)
Czyli pierwszą implementację złożonej metody rozbijam na serię wywołań kilku metod składowych na tym samym poziomie abstrakcji. Z jednego bloku kodu powstaje kilka metod.
2. Refaktoryzacje typu Extract class, Extract interface, Move method, Move field na podstawie analizy odpowiedzialności klasy.
Z czasem wyodrębnionych metod w powyższym kroku jest coraz więcej, więc klasa zaczyna być zbyt duża i często przestaje spełniać regułę SRP (pojedynczej odpowiedzialności). Zatem zaczynasz myśleć o przeniesieniu tychże metod gdzieś indziej. Do innej klasy, do nowej klasy, być może temu będzie towarzyszyć wyodrębnienie się interfejsu, być może będzie trzeba poprzesuwać pola w klasie.
3. Refaktoryzacje do wzorców projektowych (http://www.industriallogic.com/xp/refactoring/)
W sytuacjach, kiedy musisz przygotować się na zmienność w projekcie (np. różne wersje algorytmów, przetwarzanie zdarzeń, adaptowanie struktur czy zachowania), wprowadzasz w projekcie wzorce projektowe.
4. Refaktoryzacja do wzorców architektonicznych (podstawowy opis wzorców http://martinfowler.com/eaaCatalog/)
Z czasem jeśli obecna architektura nie radzi sobie ze zmieniającymi się wymaganiami systemu albo potrzeba innej koncepcji, to modyfikujemy założenia architektoniczne - a zatem również musi ulec zmianie Mantra architektoniczna. Może to być: dodatnie warstwy, usunięcie warstwy, zmiana architektury dziedziny (Domain Model, Active Record, Exposed Domain Model) itp.

Heurystyka zwinnego modelowania systemu (czyli jak zacząć i mieć pewien zgrubny koncept)
Jak dojść zwinnie do wstępnego modelu, który pozwoli ruszyć z implementacją, a jednocześnie pozwoli uniknąć podstawowych błędów związanych z nieprzemyślaną architekturą? Jak i kiedy zaplanować architekturę? Zrobić wstępny projekt w podejściu zwinnym?
Oto propozycja zwinnej "drogi" :) Jest to miks praktyk Scrumowych/Agilowych, ICONIXa i naszych doświadczeń BNSowych.
1. Zdefiniuj (jeśli jeszcze nie masz) User Stories/Epics.
Zazwyczaj wystarczy pokrycie 80% systemu. Pamiętaj, żeby nie przesadzać ze szczegółami. Jeśli twój system ma UI - koniecznie korzystaj z draftów ekranów. Jeśli nie ma przydadzą się uproszczone diagramy określające interakcje systemu. Jakie diagramy? To już zależy od Twojej dziedziny :)
2. Przeanalizuj interakcje z systemami zewnętrznymi. Z nich też będą wynikać US. W efekcie usługi czy elementy modelu.
3. Określ priorytety i zgrubnie określ co wejdzie do Realeasu (wersji wdrożeniowej - czyli zazwyczaj efekt kilku miesięcy prac).
Pamiętaj, najbardziej będą interesować Cię rzeczy o wyższych priorytetach. Te o niższych nie są warte zbyt dużej uwagi.
4. Analizując po kolei User Stories, buduj model dziedziny (docelowo diagram klas dziedzinowych).
Skupiaj się przede wszystkim na nazwach klas i powiązaniach. Jest to najbardziej naturalny słownik dziedzinowy (bardziej definicja nazw).
5. Analizując po kolei User Stories (US), wyodrębniaj usługi (operacje) systemu.
Najlepiej, żeby były sformułowane w języku biznesowym. Na początku nie dziel ich specjalnie. Nawet wrzucaj do wspólnego worka. Dla ułatwienia możesz powiązać je z odpowiednimi US.
6. Określ złożoność operacji.
Określ, które operacje są bardziej złożone (wychodzą poza klasyczny CRUD). Będzie to podstawa do określenia kierunku architektury.
7. Wybierz kierunek architektury (w oparciu o model dziedzinowy)
(m. in. Domain Model, Anemic Domain Model, Active Record, Exposed Domain Model). Uwzględnij technologie, jeśli jest już wybrana lub ją wybierz.
8. Z wyróżnionych usług wybierz te o największym poziomie złożoności i ryzyku w celu analizy.
Zrób proste szkice klas, interakcji, które pozwolą przeanalizować złożoność. Wybieraj tylko te usługi do analizy, które przynależą do US o wysokich priorytetach lub też mogą znacząco wpłynąć na wykonalność projektu.
9. Osadź architekturę w technologii. Spartycjonuj usługi.
Rozrysuj bloki architektury i typowe klasy. Na bazie listy usług - podziel je grupując wg zbliżonych odpowiedzialności (spójnych dziedzinowo).
10. Przeanalizuj 1-2 US (koncept implementacji), które pozwolą zweryfikować założenia koncepcji.
Jeśli weryfikacja się nie powiedzie, wróć do 7 lub 8.
11. Zaimplementuj wybrane 1-2 US, aby zweryfikować koncepcje.
Może to wymagać wstępnego setupu projektu, środowiska. Może to być podstawa to tzw. Iteracji 0, Sprintu 0, Elaboration phase (?? nie jestem ekspertem RUPa).
Jeśli weryfikacja się nie powiedzie lub koncept ma luki przejdź do 7 lub 8.
12. Zdefiniuj Mantrę architektoniczną.
13. Realizuj inkrementacyjnie projekt (to dalej definiuje metodyka).

Powiązany OFFTOPIC:
Zapodam pewną mądra myśl, która może kogoś natchnie do myślenia:
"W architekturze nie chodzi o rysunki, diagramy, powiązania z innymi systemami, ale o głębokie zrozumienie dziedziny i kontekstu systemu, z którym pracujesz. Zapomnij o UMLu, zapomnij o supernarzędziach wspierających Cię w projektowaniu, włącz myślenie. Włóż najwięcej energii w zrozumienie dziedziny. Ta wiedza już po nitce poprowadzi Cię do odpowiednich konstrukcji projektowych".
Tak, tak, to niewiele mówi. Na razie mogę odesłać do koncepcji Domain Driven Design oraz Lean Architecture (vide: Google).

Nie powinieneś biegać ze złamaną nogą!

2011-02-06T11:32:00.006+01:00

Jasne? Oczywiste? Niby tak się wydaje a jednak cały czas biegamy ze złamaną nogą...

Jedną z najczęściej oczekiwanych odpowiedzi, którą chcą usłyszeć osoby(w trakcie szkoleń lub projektów doradczych) - to odpowiedź na pytanie: "Jak mam sobie poradzić z pewnymi problemami w mojej sytuacji" (w moim projekcie, z moim klientem, menedżerem analitykiem whatever...). Jest to oczywiście naturalne pytanie, ale dużo ważniejsze jest pytanie: "Czy sytuacja, w której się znajduję jest zdrowa?". A najczęściej nie jest!
W takiej sytuacji, pierwotne pytanie można porównać do pytania: "Jak mogę szybko i efektywnie biegać ze złamaną nogą?". Chętnie poznam odpowiedzi...

Przykłady:
* Nie mamy dobrego kontaktu z osobą, która definiuje wymagania (bo między nami a klientem jest jeszcze firma pośrednia i dostajemy informacje z drugiej ręki, często nie mamy możliwości bezpośrednio skontaktowania się z taką osobą/osobami).

* Biznes/kierownicy projektu nie uwzględniają technicznych potrzeb podczas ustalania priorytetów (biznesowe priorytety są najważniejsze, ale techniczne nie mogą być ignorowane, gdyż spowoduję nadmierny wzrost kosztów implementacji).

* Nie ma nikogo, kto jest jednoznacznie odpowiedzialny za wymagania, definiuje je i odpowiada za zmiany (ponosi odpowiedzialność za ich koszt). Zazwyczaj odpowiedzialność ta jest rozmyta i wymagania pochodzą z nieskoordynowanych źródeł.

* Brak aktywnego udziału i wsparcia osób biznesowych podczas prac implementacyjnych (trudność w uzyskaniu konkretnych informacji wyjaśniających, jak to dokładnie ma działać).

* Brak refaktoryzacji, bo to kosztuje (za dużo i nikt za to nie zapłaci), bo to nie ma sensu (komu się uda posprzątać ten cały syf?).

* I wiele innych... chyba na każdy z tych tematów można poświęcić osobny artykuł.

Jak w takich sytuacjach zastosować coś rozsądnego? Jak w takim przypadku na przykład zastosować Scrum? (bo w takich sytuacjach najczęściej słyszę tego typu pytanie). Przypomnij sobie podstawowe pytanie: "Jak biegać ze złamaną nogą?"

Zanim zaczniesz dopasowywać się do zaistniałej sytuacji postaraj się wyeliminować z niej patologie! Zazwyczaj tego nie robimy bo:
* jest to trudne,
* często wymaga konfrontacji obecnej rzeczywistości,
* może doprowadzić początkowo do konfliktów i oporu,
* wymaga często dość sporych umiejętności komunikacyjnych (w tym negocjacyjnych),
* często będzie musiało to doprowadzić do zburzenia istniejącego status quo - a tego boi się prawie każdy ...
* zwyczajnie wymaga odwagi!

Więc zazwyczaj uczymy się biegać ze złamaną nogą. Jeeeeeeeeeee.... I like it. Na poziomie lokalnym udaje się wszystko poukładać (jakoś można z tym żyć), na poziomie globalnym jest to bez sensu. A jednak, tak zazwyczaj to funkcjonuje... Ciekawe, nieprawdaż? Niczym w amoku...

Zanim zaczniesz dopasowywać do obecnej sytuacji, krytycznie ją zweryfikuj! Jest pewna mądrość: "Automatyzacja nieprawidłowego procesu (czyli potencjalne jego przyspieszenie) zazwyczaj zwiększa jego nieefektywność". Jeśli sytuacja, w której się znajdujesz jest niezdrowa, czy można znaleźć w tej sytuacji najlepsze praktyki...? Jakie będą najlepsze praktyki biegania ze złamaną nogą? :)

Co zatem robić? To długa odpowiedź, często zależąca od subtelnych niuansów danego kontekstu. Tutaj nawet nie podejmę próby jej sformułowania. Ten post ma sprowokować do myślenia! Jest spora szansa, że jak zaczniesz analizować sytuację (sam/z osobami współpracownikami) - znajdziecie odpowiedzi. Pod warunkiem, że nie będziecie szukać czarodziejskiej różdżki, która bezszelestnie, bezinwazyjnie, bezproblemowo wszystko załatwi. Jeszcze raz przypomnę - próba rozpoczęcia zmian w tym kierunku wymaga ODWAGI i z pewnością wykroczenie poza własną STREFĘ KOMFORTU.

Mały hint. Jeśli w dużym przybliżeniu założymy taki łańcuch (pozwól, że pominę uzasadnienie tego pogrupowania, żeby nie wydłużać posta, może kiedyś będzie okazja...):

programista/tester/grafik... => analityk/kierownik => menedżer/klient/kierownik po stronie klienta

Największą moc sprawczą mają oczywiście ostatnie elementy łańcucha, ale też zazwyczaj im najtrudniej dostrzec patologie, albo też bardzo często są ich źródłem (jako osoby decyzyjne). Tej grupie najłatwiej będzie doprowadzić do potrzebnych zmian.
Najtrudniej mają osoby z początku tego łańcucha (gdyż są najmniej decyzyjne, przez to inicjowane zmiany wymagają często najwięcej odwagi!). Dla nich jedną ze skuteczniejszych (choć często żmudnych i długotrwałych) technik jest technika zdartej płyty :) (czyli ciągłe wskazywanie patologii, pokazywanie ich konsekwencji i upierdliwe o tym przypominanie... niestrudzenie, bez przerwy). Jeśli przy tym uda się zbudować koalicję w naszym łańcuchu, tym większa szansa na zmiany.

Jest jedna opcja - można poszukać pomocy z zewnątrz. Analiza, rekomendacje zewnętrznej niezależnej, obiektywnej osoby/firmy mogą skatalizować proces zmian.

Pamiętaj! Złożenie złamanej nogi może boleć!

Hiperoptymalizator czasu

2010-08-10T17:10:00.002+02:00

21 maja 2009 - ostatni wpis ... sporo piasku w klepsydrach upłynęło. Pojawienie się pewnej małej istotki w moim życiu wiele zmieniło, ale powoli :) wracam do świata żywych. Na dobry początek pierwszy po przerwie wpis.

Wydaje się, że zarządzanie czasem to wyeksploatowany temat, gdzie niewiele można już dodać, gdyż wszystko zostało powiedziane lub napisane. O ile rzeczywiście trudno dodać coś nowego, to dużo ważniejsze jest pytanie – co można ująć, w myśl zasady „Twórz rozwiązania najprostsze jak to możliwe, ale nie prostsze”.

Jedną z głównych przypadłości cywilizacyjnych jest ogromny wybór, mnogość opcji, konkurencja, dziesiątki źródeł informacji. Jaki mamy z tego efekt? Przeciążenie informacjami, przeciążenie wyborami, co powoduje, że wartość informacji zaczyna się zacierać:

• co warto czytać?
• co warto poznać?
• czego warto się nauczyć?
• czemu warto poświęcić choć tak dużo czasu jak jedna sekunda naszego życia?

Kiedyś (dziesięć lat temu) w ciągu roku byłem w stanie dotrzeć do kilku płyt. Świetnie je znałem, teksty znałem na pamięć i miały dla mnie autentyczną wartość. Niedługo później stać było mnie na to, aby kupować kilkanaście płyt w miesiącu i jaki był efekt? Osiemdziesięciu procent z nich w ogóle nie przesłuchałem i chyba nie było żadnej takiej, z którą bym się zżył tak mocno, jak kiedyś.
Jesteśmy bombardowani informacjami i zadaniami do wykonania, a odłamki niszczą nasze zasoby wolnego czasu. Dlatego właśnie głównym wyzwaniem nie jest wcale

• optymalizacja posiadanego czasu,
• większa kontrola nad zadaniami i ich przewidywalność,
• świadomość wykorzystywanego czasu,
• i inne atrybuty dobrze zarządzanego czasu,

ale umiejętność znalezienia tego, co z tych wszystkich potencjalnych informacji i zadań jest naprawdę istotne. I powiem szczerzenie, że wielokrotnie słyszałem o zasadzie Pareto 80/20 (Czyli to że 20% naszych działań generuje 80% efektów), nawet – jak mi się wydawało – stosowałem ją w życiu. Ba! Nawet sam jej uczyłem, ale teraz widzę, że moje zrozumienie tej zasady nie było głębokie. Polegało na powierzchownym stosowaniu techniki do porządkowania zadań. Teraz jednak zaczyna docierać do mnie jej dużo głębszy sens. Zasada Pareto ma nauczyć nas sztuki wyboru poprzez umiejętną rezygnację. Zarządzanie czasem nie polega na idealnym upchaniu jak największej ilości zadań w jak najkrótszym czasie. Zarządzanie czasem powinno polegać na tym, aby robić rzeczy ważne!

Niezły banał, nieprawdaż? Ale spójrzmy na to z innej strony. Jak często się zastanawiasz, czy to co zrobiłeś w ostatnim czasie (dniu, tygodniu, miesiącu) było istotne? Z czego mógłbyś zrezygnować i nic by się nie stało? Czego mógłbyś zrobić mniej? Czy to co zrobiłeś, musiałeś lub powinieneś robić właśnie Ty? Tak, to tutaj jest ukryty sekret traconego czasu. Od kilku tygodni przeprowadzam taką analizę i z ogromnym zadziwieniem stwierdzam, że 30-50% rzeczy, które wykonałem nie zasługiwały na ilość energii im poświęconej. Niektóre sprawy mogłem sobie zwyczajnie odpuścić, przełożyć na później, zamiast na 130% zrobić na 105% ;-), większość zadań mogłem zrobić dużo prościej, dużo mniej czasu spędzić na spotkaniach. Wyciąganie tego typu wniosków, to prawdziwe hiperuczenie się. Powiem Wam coś więcej, mimo tej świadomości – cały czas co tydzień, stwierdzam że 30-50% nie musiałem wykonywać w taki sposób. Ogromna wiedza i doświadczenie z obszaru zarządzania czasem, stosowanie technik organizowania zadań, planowania, używania kalendarza, przypominaczy nie wystarcza. Najważniejszą, a jednocześnie najtrudniejszą umiejętnością jest sztuka eliminacji. Żeby się jej nauczyć, należy sobie jednak zadać niebanalne pytanie: „Co jest dla mnie naprawdę ważne” … Ale to już inna historia …

Działaj tak, jakbyś miał nieskończenie wiele czasu…

2009-05-21T23:39:00.000+02:00

Tik, tak, tik, tak ... Zegar tyka nieuchronnie, czas płynie, deadline blisko, a zadań nie ubywa. Im bardziej się spieszysz, im bardziej idziesz na skróty tym więcej problemów się pojawia. Tymczasem odpowiedź jest prosta: Działaj tak, jakbyś miał nieskończenie wiele czasu!

No dobra, nie jest wcale taka prosta, przynajmniej nie jest prosta w realizacji. Zazwyczaj kierownik, klient, project manager lub analityk, stoi Ci nad głową i bezlitośnie przypomina o zbliżającym się terminie. Z pewnością nie oczekują po Tobie, że zaczniesz pracować jakbyś miał nieskończenie wiele czasu. W końcu zapewne znają prawo Parkinsona, że praca zajmuje tyle, ile jest na nią przeznaczonego czasu! I nie pozwolą Ci, abyś tego czasu miał zbyt dużo. Stąd taki nacisk na terminy, deadliney i zobowiązania.

Tymczasem programowanie to bardzo wrażliwa materia ... wiele zmiennych, dużo informacji, założona architektura, struktura projektu, wielość technologii i narzędzi, to wszystko nie sprzyja programiście, kiedy nie ma czasu. Parametrów jest bardzo wiele i łatwo o błędy, a pośpiech je mnoży. Kroki na skróty powodują więcej szkód niż pożytku, a paradoksalnie tymczasowe rozwiązania powstałe wskutek pośpiechu, stają się fundamentami produkcyjnego systemu.

Dlatego właśnie działaj tak, jakbyś miał nieskończenie wiele czasu! W takich momentach wmawiaj to sobie bez opamiętania i możesz mi wierzyć, że nie rozleniwisz się z tego powodu! Twój kierownik, klient, project manager lub analityk nie pozwolą Ci na to. Ważne jednak, żebyś zwolnił mentalnie, aby uchronić się przed autodestrukcją, zarwanymi nocami, zerwanymi kontaktami z rodziną czy znajomymi ... no może przesadzam! Ale czasami trzeba postraszyć ;-)

Rozmowa z klientem

2009-04-22T01:44:00.002+02:00

Pierwsza rozmowa z klientem

Dzisiaj rozpoczyna się nowy projekt. Jak zawsze w takich przypadkach w zespole panuje nutka podniecenia i próby zgadywania, co będzie jego przedmiotem. Już są pewne informacje, ale to ciągle jeszcze nic pewnego.

Rozmowa z klientem zaczyna się. Po kilku minutach wstępnej rozmowy, przechodzimy do konkretów. (K - Klient, Z - Zespół).

Z: Jak moglibyśmy zdefiniować wizję projektu? Taką główną, nadrzędną myśl, ideę, która będzie mu przyświecać. Czemu ma służyć? Jest to o tyle ważne, że ta wizja, którą teraz zdefiniujemy, będzie głównym wyznacznikiem celowości podejmowanych działań. I oczywiście definiuje cel samego projektu. Motywuje do działania. Pozwala stworzyć końcowy obraz.

K: Chciałbym stworzyć system internetowy, który pozwoli w inteligentny sposób wyszukiwać przepisy kucharskie.

Z: To ciekawy pomysł i świetnie zdefiniowana wizja. Czy możemy mu się bliżej przyjrzeć?

K: Oczywiście. Istnieje wiele stron z przepisami kucharskimi i to nawet bardzo dobrych stron. Jednak mają one kilka wad. Są dość statyczne – nie pozwalają na bardziej zaawansowane przeszukiwanie przepisów. Zazwyczaj nie ma możliwości wybrania przepisów na bazie własnych upodobań czy wyszukania ich na bazie posiadanych składników. Brakuje swoistej inteligencji, która uprościłaby życiu użytkownikom portalu.

Z: Powoli zaczyna mi się to wszystko układać. Może spróbujemy wyodrębnić najważniejsze funkcje systemu?

K: Mam sporo pomysłów, ale nieduży budżet. Dlatego na początek chciałbym, aby była możliwość wyszukania przepisu, bazując na liście składników, które posiadam w danym momencie. Załóżmy, że jest środa wieczór, mam jajka, mąkę, bakłażan, mleko, trochę masła i chciałbym zrobić coś z tego do jedzenia. Nie mam pomysłu na to, co to może być. Więc otwieram portal do wyszukiwania przepisów, wpisuję składniki, które posiadam oraz ewentualnie preferencje np. rodzaj potrawy – zupa, ciasto, zakąska, rodzaj kuchni – polska, azjatycka, francuska, włoska … W efekcie dostaję kilka przepisów, które mogę zrealizować z posiadanymi składnikami. I to wszystko.

Z: A w jaki sposób użytkownik będzie wpisywał dane?

K: Wszystko musi być jak najprostsze z punktu widzenia użytkownika. Użytkownik powinien jak najmniej myśleć i podejmować wysiłku. Dlatego wyobrażam sobie, że będą dwa pola tekstowe – jedno do wpisywania składników, wiersz po wierszu, drugie do wpisania preferencji, to drugie będzie opcjonalne. Minimum wpisywania i konfiguracji. Oczywiście mogą być dodatkowe opcje, ale dostępne pod przyciskiem „Zaawansowane”. W domyślnej formie musi do być uproszczone do minimum. Pewnie przydawałaby się jakaś forma podpowiadania, żeby użytkownik nie musiał zbyt wiele pisać.

Z: Interesujące. Jak w tym polu tekstowym będzie użytkownik wpisywał składniki? W jakim formacie. Może tutaj napisze pan przykład na kartce.

K: Na przykład tak:
1/2 kg mąki
pół kostki masła
1/3 litr mleka
5 jaj

Z: Muszę przyznać, że to spore wyzwanie. Będzie wymagać analizy tego typu zapisu. Czy nie możemy zrobić tego w inny sposób, np. przez odpowiednie pola wyboru?

K: Nie, zdecydowanie nie. Komu by się chciało to robić w taki sposób. Musi to być zrealizowane w taki sposób. Kiedy w przypadku wizji użyłem słowo inteligentny, to właśnie to miałem na myśli. Rozumiem, że będzie to dość pracochłonne.

Z: Tak, bardzo pracochłonne. Ale jeśli jest to warunek konieczny, to oczywiście możemy to zrealizować w taki sposób. Przedstawimy później wstępne oszacowaniu złożoności problemu i zdecyduje Pan, czy chce realizować to w ten sposób.

K: Jeśli się zdecyduję, to tylko w ten sposób!

Z: Widzę zatem, że zapis składników może być dość dowolny – mogą to być takie jednostki jak kilogramy pisane w całości lub skrótowo, a nawet bardziej umowne jednostki jak pół kostki.

K: Tak, to też jest warunek konieczny.

No cóż, zapowiada się niebanalny projekt - myślę. Robi się coraz bardziej skomplikowany. Ciekawe co jeszcze wymyśli nasz Klient.

Z: Czy coś jeszcze może być wpisywane do tego pola? Może w jakiejś innej formie?

K: Wydaje mi się, że nie.

Z: A co zatem z drugim polem – Preferencje? Też powiedział Pan, że ma to być pole tekstowe.

K: Tak, zdecydowanie. Również tutaj chciałbym, aby była możliwość swobodnego wpisania swoich preferencji np. zupa, kuchnia azjatycka.

Z: Czyli poszczególne elementy rozdzielane przecinkami?

K: Tak, mogą być przecinki albo nowy wiersz.

Z: Jakiego typu preferencje przychodzą panu do głowy?

K: Rodzaj kuchni – region, typ potrawy – np. zupa, ciasto, może rodzaj diety, w której jest dozwolona, czas wykonania.

Z: Czy coś jeszcze można wpisać w to pole?

K: Wydaje mi się, że nie.

Z: Dobrze, zatem mamy dwa pola tekstowe – w jednym wpisujemy składniki, które mamy do dyspozycji, w drugim preferencje oraz przycisk wyszukiwania.

K: Dokładnie! Powinno się to odbywać tak jak w typowych wyszukiwarkach internetowych – minimalny, ale inteligentny interfejs.

Z: Dobrze, zatem przypuśćmy, że użytkownik wpisuje dane oraz wciska przycisk szukaj. I co dalej się dzieje?

K: Następnie jest strona z wynikami! Zupełnie jak w klasycznej wyszukiwarce. Dobrze by było, gdyby lista wyników pokazywała się w dwóch formach: w postaci skróconej – tylko nazwa potrawy oraz informacje związane z preferencjami czyli rodzaj kuchni, rodzaj potrawy; w postaci rozszerzonej – to co w postaci skróconej i dodatkowo jeszcze lista składników. W jednym i drugim przypadku, nazwa potrawy to link, do strony, na której znajdują się szczegóły przepisu.

Z: Jeszcze wrócę na chwilę do wspomnianych list – jak użytkownik będzie wybierał rodzaj listy?

K: Hmm… Domyślnie niech będzie wersja skrócona, ale na liście wyników będzie do dyspozycji przycisk do zmiany formy wyników. A… i jeszcze wyniki powinny być stronicowane tak jak w przeglądarce i uszeregowane od najlepszego do najsłabszego.

Z: A co będzie decydować o tym, że jeden przepis jest lepszy od drugiego?

K: H… dobre pytanie. Może niech to będzie minimalne lub maksymalne zużycie produktów.

Z: Czyli jaka część produktów zostanie zużyta?

K: Tak?

Z: A co będzie domyślną opcją?

K: … Niech będzie minimalne zużycie. No i jakiś przycisk do zmiany tego sortowania.

Z: Świetnie! A czy coś jeszcze ma być na tej stronie wyników?

K: Chyba nie..

Z: A jeszcze wspomniał Pan o przycisku „Zaawansowane”…

K: Tak, ale jeszcze nie mam pomysłu, co tam miało by być. No w zasadzie jeden. Otóż można by wprowadzić taki parametr, który określałby jakie elementy miałyby nie być brane pod uwagę. Na przykład sól i pieprz, woda czy inne tego typu rzeczy, które każdy ma, nie powinno się wpisywać. Dlatego ustawienia zaawansowane mogłyby określać, co jest, a co nie jest brane pod uwagę.

Z: A jak miałoby to wyglądać? Myślę, że byłaby to lista z odhaczeniami, gdzie można by zaznaczać, to co nie jest brane pod uwagę.

K: A co to mogłoby być?

Z: Na obecną chwilę, to co mi przychodzi do głowy to: woda, sól, pieprz, inne przyprawy. Ale ta lista może ulec rozszerzeniu.

K: Czy coś jeszcze powinno się znaleźć w sekcji zaawansowane?

Z: Chyba nie…

Potem podsumowaliśmy rozmowę oraz kluczowe informacje, które z niej wyniknęły. Jest zatem zarys wymagań. Teraz czas uporządkowanie tychże wymagań.

Kilka wskazówek związanych z rozmową z klientem

Klientem może być każdy: kierownik, szef, wykładowca, kolega, reprezentant klienta. Początek projektu to przede wszystkim czas na określenie wizji – oświadczeniu czemu system ma służyć. Jest to nadrzędny cel projektu. Na nim będziemy bazować, określając z klientem, które działania mają sens.

Następnie staramy się zebrać kluczowe wymagania na ogólnym poziomie – jakie konkretne funkcje system ma realizować. Kiedy już je mamy, rozkładamy na czynniki pierwsze. Bardzo przydatne będą pytania:

Czy coś jeszcze powinno się tu znaleźć …

Co jest ważne w następnej kolejności …

oraz pytania za pomocą, które przechodzimy od ogólnych stwierdzeń do stwierdzeń konkretnych:

Co konkretnie musi zajść/jak to ma działać/jak to ma być zorganizowane, aby wymaganie X zostało spełnione…

Co musi być spełnione, aby można było stwierdzić, że dana funkcja została zrealizowana…

Oczywiście powyższy scenariusz jest mocno uproszczony, ale daje pewien pogląd na przebieg tego typu rozmowy.

Jak odmienić sposób programowania używając refaktoryzacji

2009-01-23T13:09:00.003+01:00

Z przyjemnością informuję, że BNS IT wydało swoją pierwszą książkę, mojego autorstwa.
Nosi tytuł "Jak całkowicie odmienić sposób programowania używając REFAKTORYZACJI".

Szczegóły na stronie mistrzprogramowania.pl

Możesz pobrać wersję bezpłatną (jest to ok. połowa książki i zawiera trochę reklam BNS IT).

Poniżej zamieszczam krótki fragment - wstęp ...

Na płycie nagrobnej pewnego anglikańskiego biskupa (ok. 1100 r.)
spoczywającego w krypcie Opactwa Westminsterskiego widnieją następujące słowa:

Kiedy byłem młody i wolny, a moja wyobraźnia nie znała granic, marzyłem o tym, by zmienić świat.

Gdy wzrosłem w latach i mądrości, zrozumiałem, że świata nie da się zmienić.

Więc przykróciłem nieco swe zamiary, i postanowiłem zmienić jedynie swój kraj.

Lecz i on także pozostał niezmienny.

Gdy dożyłem swego zmierzchu, w ostatnim, rozpaczliwym zrywie zdecydowałem zmienić choć swoją rodzinę, istoty mi najbliższe.

Lecz niestety! Na nic się to zdało!

Teraz zaś, gdy spoczywam na łożu śmierci, nagle zdałem sobie sprawę, że
jeślibym zmienił najpierw tylko samego siebie, to być może swym przykładem
zmieniłbym i swą rodzinę. Przy jej inspiracji i wsparciu byłbym w stanie ulepszyć swój kraj, i kto wie, może zmieniłbym wówczas cały świat.

Zacząć od siebie

Rzeczywistość projektowa jest złożona.

Zazwyczaj brakuje czasu
Trzeba pracować na starym kodzie, który pozostawia wiele do życzenia
Koledzy z biurka obok nie kwapią się do tego, żeby zacząć lepiej pisać programy
Klienci nie widzą czego chcą
Szefowi zależy tylko i wyłącznie na najszybszym wykonywaniu zadań
Biblioteki są źle udokumentowane i zawierają błędy
Narzędzia nie działają do końca tak jak powinny

Jest wiele przeszkód, które utrudniają tworzenie oprogramowania i niestety
zawsze tak będzie. Chcielibyśmy, żeby wszystko dookoła nas się
zmieniło, żebyśmy mogli w końcu zacząć programować w przyzwoity sposób. Czy
nie przypomina to trochę sytuacji biskupa z Opactwa Westminster?

Czego można się spodziewać?

Ta książka jest inna. Nie
będzie tu kwiecistych wyjaśnień wszystkich możliwych refaktoryzacji, nie
będzie przykładów wyrwanych z kontekstu. W zamian za to poznasz wiele rzeczy,
o których nikt nawet nie wspomina w innych książkach --- dowiesz się, jak
używać omawiane techniki w praktyce i jak zastosować je od zaraz. Poznasz
te, które są najbardziej użyteczne. Jeśli podążysz za autorem, twój sposób programowania całkowicie się odmieni.

Pierwsze trzy rozdziały stanowią wstęp do refaktoryzacji i absolutne minimum,
które musisz wiedzieć na jej temat. Kolejne rozdziały, to już techniki mistrzów.

Chcesz przeczytać więcej? mistrzprogramowania.pl

Weekendowe warsztaty Wzorce projektowe

2008-11-05T21:20:00.003+01:00

Serdecznie zapraszamy na „Warsztaty weekendowe poświęcone wzorcom projektowym”. Jest to oferta specjalna dla użytkowników portalu Goldenline.pl i czytelników mojego Bloga i Michała. Tej oferty nie znajdziesz na stronie BNS IT!

Warsztaty umożliwiają nabycie praktycznych umiejętności tworzenia aplikacji z użyciem wzorców projektowych w języku Java.

Zobacz program
http://www.bnsit.pl/files/Wzorce_projektowe_java_i_refaktoring.pdf

Czego potrzebujesz?
• Notebook z kartą wi-fi
• Zapału, chęci i otwartego umysłu

Twoja inwestycja to jedyne: 800 zł.

Nigdzie nie znajdziesz szkolenia ani warsztatów w takiej cenie i jakości.

Powiedz znajomym.

Gdzie?
Warszawa, 13-14.12.2008
Wrocław, 13-14.12.2008
Kraków, 13-14.12.2008

Kontakt:
m.sieraczkiewicz [[[[[ MAUPA ]]]]]] bnsit.pl
+48 500 189 752
http://www.bnsit.pl

2. Spotkanie ŁJUG - podsumowanie

2008-08-10T15:20:00.001+02:00

Wczoraj, tj. 09.08.2008 odbyło się kolejne, drugie już spotkanie Łódzkiego JUGa. Mimo wakacyjnego okresu, znalazło się wielu śmiałków, którzy odważyli się poświęcić część sobotniego popołudnia, aby przyjść na spotkanie, które dotyczyło tak wspaniałego języka jak Java.
Temat był dość nietypowy, ponieważ Wzorce implementacyjne, nie są szerzej znanym terminem, a jak się okazuje, wielu z nas ma na co dzień do czynienia z tematami przez nie podejmowanymi. Zagadnienia te często zahaczają o zagadnienia podstawowe takie jak sposoby nazywania, wydzielania klas, tworzenia wyjątków itp.

To taka magia, którą prędzej czy później włada doświadczony programista. Lecz czasami można do tej magii zbliżyć się wcześniej.
Poniżej zamieszczam prezentację z tego spotkania. Nie zastąpi ona oczywiście osobistej obecności, ale może pozwolić przybliżyć się do tematu i zachęcić do dalszej eksploracji.

Tutaj możesz wersję PDF prezentacji

Łatwość dostępu ponad uporządkowaniem informacji

2008-07-17T23:08:00.003+02:00

Ostatnio eksperymentuję z różnymi sposobami informacji, tak aby mieć mieć do nich zdalny dostęp z dowolnego miejsca. Podstawowym narzędziem, którego używam jest SVN, który świetnie się sprawdza w przypadku projektów informatycznych, o tyle w przechowywaniu dokumentów w moim przypadku sprawdza się kiepsko. Z dwóch powodów:
* trzeba mieć klienta (alternatywą są interfejsy www, ale te z kolei mają IMHO kiepskie usability)
* swoista złożoność podejścia sprawia, że takie rozwiązanie skutecznie odstrasza mnie od regularnego korzystania.

Ostatnio sprawdzam w działaniu Notatnik Google, który stawia przede wszystkim na prostotę pracy z informacjami, szczególnie z takimi, które mają charakter szkiców, wolnych myśli, przemyśleń. No i jest zdalny.
Logika działania aplikacji jest zgodna z innymi narzędziami Google i samej idei Web 2.0. Przede wszystkim prostota i usability. Mamy zatem bardzo proste narzędzie, które umożliwia:
* tworzenia notatek (i nadawanie etykiet)
* notowania stron www (forma zakładek z możliwością cytowania tekstu strony)
* możliwość tworzenia sekcji w celu ewentualnego strukturyzowania notatek.
Dzięki integracji z Firefoxem poprzez odpowiedni plugin dostajemy pod prawym przyciskiem możliwość zanotowania fragmentu czytanej strony.
W zasadzie to wszystko (no dobra prawie wszystko). Najważniejsze jest jednak to, że nie jest potrzebna ogromna ilość opcji, które pozwolą zorganizować pracę z notatkami - prosta idea tagowania (wszechobecna w web 2.0) i możliwość cytowania fragmentów stron internetowych to praktycznie to, czego potrzeba w 85% przypadków (nie pytajcie skąd ta liczba ;-)).
W ten sposób mam zdalne narzędzie, w dodatku rozproszone - dokumenty można współdzielić a nawet współedytować oraz notatki mają charakter luźno ustrukturyzowany. Jak dla mnie świetnie. Jest to ciekawa alternatywa dla innych form przechowywania danych. Oczywiście jak sama nazwa wskazuje - bardziej notatek niż formalnych dokumentów, ale wtedy już warto poświęcić nieco czasu na SVN czy jakieś inne formy przechowywania plików na zdalnym serwerze (hmmm... Google Docs!?).

Przychodzi mi do głowy pewien wniosek, że w przypadku informacji, z którymi często pracujemy, które chcemy mieć pod ręką, ważniejsze staje się łatwość pracy z takimi dokumentami (patrz Google Notatnik) niż ich uporządkowanie (SVN czy serwery plików czy whatever).

Z drugiej strony to kolejne narzędzie Google, od którego można się uzależnić, co zaczyna być coraz bardziej niebezpieczne. Jeszcze przyjdzie taki dzień, kiedy Google zmonopolizuje świat - no dobra już to prawie zrobiło. Z tym że ilość danych o nas przechowywana przez Google staje się coraz bardziej niebezpieczna.

Jestem ciekaw waszych sposobów pracy ze zdalnymi dokumentami/plikami/notatkami, szczególnie takimi dokumentami, które wymagają częstej edycji, zaglądania do nich.

Strategie doskonałości. Najprostsze możliwe środowisko.

2008-07-16T12:56:00.006+02:00

Tutaj możesz pobrać pełną wersję PDF artykułu

Kto nie uwielbia tych wspaniałych chwil, kiedy projekt nabiera kształtu, kolejne funkcjonalności pojawiają się jedna za drugą i nie możemy się nacieszyć wspaniałym programistycznym dziełem. Pielęgnujemy każdy fragment, aby nasze oprogramowanie było jeszcze wspanialsze.

Jest to również moment, kiedy projekt zaczyna stawać się coraz bardziej złożony. Jeśli na przykład pracujemy nad aplikacją internetową, to przychodzi taki moment, kiedy aplikacja obsługuje logowanie, transakcje, współpracę z bazą danych, wielojęzyczność, złożone reguły bezpieczeństwa. Istnieje również pewna logika przetwarzania zdarzeń użytkownika – najczęściej korzystamy z jakiegoś frameworka MVC. System rzeczywiście jest już całkiem złożony. Restart całej aplikacji zajmuje kilkanaście a czasem kilkadziesiąt sekund, a nawet kilka minut.

Każdy dzień pracy w takim środowisku powoduje, że się przyzwyczajamy do tej całej złożoności. Co więcej, orientujemy się w niej coraz lepiej, czujemy się jak ryba w wodzie, korzystając z dobrze już znanych niuansów. Osiadamy w przyzwyczajeniu.

Rozwijamy dalej aplikację - tworzymy nową funkcjonalność. Niech będzie to ekran z wykresami tworzonymi na podstawie danych przechowywanych w systemie. Jeszcze nigdy nie mieliśmy do czynienia z wykresami, a przynajmniej nie z tą biblioteką, z której mamy skorzystać. Zatem ucząc się umiejętności związanych z tworzeniem wykresu, zaczynamy osadzać nowe rozwiązanie w złożonym systemie. W międzyczasie musimy przetestować kilka wariantów i sprawdzić, jak dokładnie działa komponent, którego chcemy użyć po raz pierwszy.

Zatem eksperymentujemy z różnymi parametrami. Zanim dokonamy testów, musimy odpowiednio skonfigurować framework MVC, odpowiednio osadzić komponent wykresu na stronie lub panelu, być może dodać elementy związane z bezpieczeństwem i wielojęzycznością. A wszystko to pojawia się tylko po to, żeby nauczyć się jak wykorzystywać komponent.

A przecież dopiero się uczymy...

Dopiero eksperymentujemy!

Nie jest nam potrzebny cały ten narzut.

Nagle jeden z parametrów nie do końca działa tak jak byśmy chcieli. W zasadzie nie wiemy o co chodzi. Jednocześnie cały system się nie uruchamia, bo na szybko oprogramowaliśmy controller (z MVC), więc przy okazji zmagamy się z jego błędami – problem z dostępem do danych.

W końcu udało się. Wracamy do naszego komponentu, ale jeszcze musimy zrestartować aplikację. Trwa to dość długo. Zbyt długo.

Czy w ogóle to całe środowisko jest potrzebne do przetestowania komponentu? Narzut ogromny – należy stworzyć wszystkie elementy potrzebne do uruchomienia testowego fragmentu, które narzuca środowisko. Czas potrzebny na efektywne badanie kolejnych parametrów jest subiektywnie oceniając wydłużony o 10-50 % z powodu złożoności systemu, w którym proces się odbywa.

A gdyby mieć pod ręką najprostsze możliwe środowisko aplikacji webowej (czasami dostarczane razem z bibliotekami jako blank application) i używać je do testowania nowych elementów lub prostych fragmentów funkcjonalności. Bez narzutu pozostałych elementów środowiska, takich jak bezpieczeństwo, wielojęzyczność, logowanie! Najprościej jak to tylko możliwe. Oczywiście, kiedy już uda się przeprowadzić próby na prostym środowisku, przenosimy rozwiązanie do złożonego systemu, w którym pracujemy.

Być może nie tworzysz aplikacji webowych, ale z pewnością znajdziesz analogie w obszarze, w którym się specjalizujesz. Ogólny schemat postępowania jest taki sam bez względu na technologię.

Być może wydaje się to bardzo oczywiste -bo jest oczywiste. Ale dlatego tak często o tym zapominamy i tak często tracimy niepotrzebnie czas i często szargamy swój system nerwowy analizując wyjątki z warstwy danych, mimo że w tym momencie zajmujemy się eksperymentowaniem z komponentem wykresu. Wiele razy byłem świadkiem (lub uczestnikiem) takiej sytuacji!

Całość powyższych rozważań można sprowadzić do zasadniczej myśli:

Pracuj w możliwie najprostszym środowisku

Bardzo łatwo ulec przekonaniu, które z pewnością w tym momentem przychodzi do głowy: „... ale w moim środowisku nie można nic uprościć! Nie można przenieść tego, co robię, w inne, prostsze środowisko...”. Mogę cię zapewnić Czytelniku, że prawie zawsze można środowisko uprościć. Główne pytanie, na które trzeba sobie odpowiedzieć, to czy rzeczywiście warto, ponieważ bywają sytuacje, w których stworzenie uproszczonego środowiska lub przygotowania środowiska, będzie mało opłacalne. Jednak w dużej części przypadków warto to robić, tym bardziej że wypracowane rozwiązanie często może zostać użyte podczas prac nad następnymi funkcjonalnościami. Zatem poniesiony wysiłek zaprocentuje jeszcze wielokrotnie.

Kilka praktycznych sposobów na upraszczanie środowiska opisałem poniżej. Jestem przekonany, mój Czytelniku, że będą stanowić inspiracje, dzięki którym będziesz pracował jeszcze efektywniej i ten wspaniały zawód programisty, stanie się jeszcze wspanialszy.

Twórz uproszczone konteksty pracy

W zasadzie przedstawiony na wstępie przykład jest ucieleśnieniem tej zasady.

Kiedy chcesz sprawdzić nowy komponent, bibliotekę, zastanów się jak możesz najprościej ją przetestować i poznać jej właściwości. Zazwyczaj złożona aplikacja, nad którą właśnie pracujemy, jest ostatnim miejscem nadającym się do tego celu.

Jeśli nigdy dotąd nie używałeś wyrażeń regularnych, a teraz będą ci potrzebne, zanim zaczniesz z nimi pracę najzwyczajniej świecie stwórz klasę z metodą main (tu mam na myśli Javę, ale każdy w to miejsce może wstawić sposób, w jaki tworzy się słynne już HelloWorld – bez narzutów technologicznych). I tam przetestuj wszystkie interesujące cię przypadki. W miejsce wyrażeń regularnych można wstawić każdą dowolną inną funkcjonalność: obiekty funkcyjne z jakarta-commons, generowanie pdf-ów, kopiowanie danych, łączenie się z serwerem SMTP i wysyłanie maili, bibliotekę do współpracy z bazą danych, funkcje statystyczne. Można wymieniać bez liku.

Kiedy już pracujesz w złożonym środowisku, np. budujesz strony internetowe z użyciem frameworka MVC, i chcesz przetestować nowy komponent graficzny, zazwyczaj lepiej zrobić to w środowisku poza projektem, a nie w aplikacji, którą właśnie tworzysz.

Jeśli chcesz przetestować działanie pola tekstowego, na który jest nałożona maska pewnego wzorca, który określa format danych przyjmowanych przez to pole, zrób to na możliwie najprostszym przykładzie, poza aplikacją. Zyskasz sporo czasu. Jeśli zrobisz to jeden raz – drugi, trzeci i kolejne będą coraz łatwiejsze.

Testuj jednostkowo i hermetyzuj logikę

Jeśli kiedyś zastanawiałeś się, do czego mogą przydać ci się testy jednostkowe, to mogę cię zapewnić, że między innymi mogą posłużyć jako świetne narzędzie do upraszczania środowiska pracy. Po pierwsze są świetnym zamiennikiem dla metody main – dają większe możliwości tworzenia bardziej złożonych przypadków testowania. Dodatkowo dzięki użyciu mock objects jesteśmy w stanie pracować z minimalnym podzbiorem logiki biznesowej.

Na przykład jeśli pracujemy nad metodą lub funkcją, która (1) przygotowuje treść maila i (2) go wysyła, nie musimy go fizycznie wysyłać. Podstawiamy mock object (bardzo uproszczoną implementację do celów testowych) i nie musimy czekać za każdym razem, żeby mail został wysłany. Oczywiście samo wysyłanie wiadomości też można przetestować. Ale można zrobić to osobno, a ewentualnie na końcu, kiedy oba mechanizmy (1) i (2) działają, przetestować je razem. Zgodnie z zasadą

W danej chwili testuj, zmieniaj lub pracuj nad jedną rzeczą

(ta zasada nie ogranicza się do programowania!)

Chciałbym zaznaczyć jedną rzecz. Stosowanie powyższych zasad nie uuchroni cię przed błędami, ale pozwoli ci zmniejszyć ilość sytuacji, w których błędy się będą pojawiać. Wyobraź sobie, że dzięki nawykowi upraszczania środowiska oszczędzisz godzinę dziennie (a możesz z pewnością więcej), w ciągu tygodnia oszczędzasz 5 godzin, w ciągu miesiąca 20 godzin. W ciągu roku ... ?

Powróćmy jednak do testów. Żeby w pełni używać testów jednostkowych musimy nauczyć się pewnej cennej umiejętności, którą nazywam tutaj hermetyzacją logiki. Tworząc oprogramowanie musimy tworzyć je modułowo, tak aby poszczególne części były jak najmniej między sobą zależne (ang. coupling ), tak aby można było ich używać niezależnie. W przypadku systemów obiektowych istnieje cała filozofia projektowania obiektowego, której celem jest osiągnięcie stanu, w którym poszczególne części systemu są od siebie jak najmniej zależne.

Jednak zarówno w przypadku systemów obiektowych jak i nieobiektowych można zastosować ogólniejszą zasadę odpowiedzialności , tzn. tak tworzyć system, aby wszystkie jego części miały jednoznacznie określoną odpowiedzialność, bez względu czy to będzie metoda, klasa, pakiet, procedura, funkcja czy formularz interfejsu użytkownika. Część taka będzie zamykać w sobie dobrze zdefiniowaną funkcjonalność, bez zbędnych powiązań z zewnętrznymi elementami.

Jeśli zatem kodujesz logikę aplikacji w interfejsie użytkownika, jesteś daleki od realizacji tej zasady. W ten sposób wyraźnie wiążesz ze sobą interfejs użytkownika i logikę, nie jesteś w stanie jej w prosty sposób rozdzielić i pracować nad nimi osobno. Jeśli tworzysz interfejs użytkownika, umieszczaj w tej części kod, który dotyczy tylko i wyłącznie interfejsu użytkownika – czyli budowania jego wyglądu, ustawiania pól i ich odczytywania. W interfejsie użytkownika nie powinniśmy tworzyć złożonych algorytmów przetwarzania danych (no chyba, że dotyczą wyświetlania elementów na ekranie), do tego celu używamy niezależnych funkcji, metod, klas.

Z pomocą w tym przypadku przychodzą między innymi wzorzec MVC oraz model architektury wielowarstwowej. Zawsze jednak można się posłużyć zdroworozsądkowym stosowaniem zasady odpowiedzialności, której konsekwencją są wymienione w poprzednim zdaniu koncepcje.

Chciałbym jeszcze raz podkreślić słowo „zdroworozsądkowym” – nie zawsze MVC czy inne koncepcje tego typu są do zastosowania w każdej sytuacji. Istnieje być może 3 % sytuacji, kiedy warto zakodować logikę w interfejsie użytkownika. Ale to jest jest tylko 3%. No może 5%, albo 10%. Ale cały czas jest to odstępstwo od reguły!

W danej chwili testuj, zmieniaj lub pracuj nad jedną rzecz

Powyższa reguła, choć już wspomniana wcześniej, jest tak istotna, że zasługuje na osobny punkt. Być może znacie odpowiedź na pytanie: „Jak zjeść słonia”. „Po kawałku”. Dokładnie ta reguła powinna towarzyszyć nam bezkompromisowo w codziennej pracy. A często nie towarzyszy. Możecie mi wierzyć, że często. Co więcej, również i mnie się zdarza czasami błądzić i jej nie stosować.

Zabierając się do realizacji większego zadania (takiego przynajmniej na 3-4 godziny), warto poświęcić kilka chwil na to, żeby zaplanować swoje działania. Zaplanować po to, by naszym słoniem, jak duży by on nie był, się nie zadławić.

Pamiętam bardzo dobrze moje doświadczenia programistyczne, kiedy podejmując się jakiegoś zadania, tworzyłem kilka godzin pełne rozwiązanie i wtedy uruchamiałem je... po raz pierwszy. No cóż, nigdy nie działało w tym momencie, bo w zasadzie nie miało prawa. Następne kilka godzin spędzałem na debugowaniu i poprawianiu kodu. Myślałem, że uda mi się zjeść całego słonia, od razu.

Zatem co warto zrobić na początku realizacji zadania? Mały plan. Tak aby ustalić przybliżony sposób tworzenia rozwiązania fragment po fragmencie. Załóżmy, że mam napisać sieć neuronową. (Jeśli nie wiesz zbyt dobrze co to takiego, nie przejmuj się, nie ma to dużego znaczenia w dalszych rozważaniach.) Nie tworzę gotowego rozwiązania. Krok po kroku zaczynam implementować najprostsze rzeczy. Na początek być może warto zaimplementować funkcję symulującą działanie neuronu. Być może później stworzyć klasę neuronu. Przetestować jego metody. Następnie być może implementować sieć. Następnie regułę propagacji wstecznej. To tylko przykładowa kolejność. Ważne, żeby w danym
momencie rozwijać, zmieniać jedną rzecz na raz . Kiedy ona zacznie działać i będzie przetestowana, brać się za następną. Oczywiście całość warto przemyśleć już na samym początku (przynajmniej na pewnym poziomie ogólności), ale implementować kawałek po kawałku, krok po kroku. Takie mikroiteracje. Ciekawą formą osiągnięcia opisanego wyżej efektu jest Test-Driven Development (aczkolwiek, nie jest to z pewnością jedyny sposób – na pewno warty uwagi).

Wiele razy widziałem sytuację, kiedy należało na przykład zaimplementować w aplikacji internetowej generowania raportu na podstawie danych przechowywanych w systemie i danych z bieżącego formularza. Programista jednocześnie rozwijał akcję (klasa obsługującej zdarzenie z interfejsu użytkownika), zmieniał interfejs użytkownika i pracował nad generowaniem raportu do pliku pdf (testując przy okazji jak generować pliki pdf). Wyobraźcie sobie, jak wiele szczegółów należy ogarniać umysłem, aby zapanować nad tym wszystkim. W takiej sytuacji zazwyczaj wszystkie elementy interferują ze sobą, a że są nie w pełni skończone, więc trudno znaleźć przyczynę popełnianych błędów.

Szukanie przyczyn błędów

Powyżej opisane sposoby mogą znacząco zmniejszyć ilość popełnianych błędów, ale bądźmy szczerzy – przyjdzie taki moment, kiedy przydarzy się sytuacja, w której nasz system lub jego fragment nie działa proprawnie. Jeśli stosujesz zasadę W danej chwili testuj, zmieniaj lub pracuj nad jedną
rzeczą , to zadanie znalezienia przyczyny błędu masz znacząco ułatwione. Ponieważ dokonujesz niewielkich kroków rozwijając kod i łatwo możesz określić zmiany, które doprowadziły do wystąpienia błędu. Ta reguła działa, kiedy kroki są wystarczająco małe. Jeśli przez ostatnią godzinę dokonałeś mniej więcej kilkunastu zmian w plikach konfiguracyjnych, kodzie i w HTML-u, to znaleźć przyczynę będzie trudniej. Jeśli natomiast najpierw dokonałeś zmiany w pierwszym pliku konfiguracyjnych i całość zadziałała, później zmiany w drugim pliku konfiguracyjnym i całość zadziałała, następnie dokonałeś zmian w kodzie i tu pojawił się błąd – to wszystko jasne.

Oczywiście w życiu nie jest tak różowo i zdarzają się sytuacje, kiedy błędy pojawiają sie po pewnym czasie (na przykład kilka dni po zmianach albo nawet po kilku miesiącach). Otóż w takich sytuacjach proponowana zasada brzmi następująco:

Uprość dany fragment rozwiązania, tak aby zaczął działać, a następnie dodawaj kolejne elementy, aż do momentu wystąpienia błędu.

Wtedy sytuacja będzie już jasna.

Załóżmy, że występuje taka sytuacja:

Aplikacja oparta o MVC – zdarzenie polega na tym, żeby pobrać odpowiednie dane i wygenerować plik pdf. Istnieje komponent, w jakiś sposób zainicjalizowany, który realizuje to zadanie:

1.pobiera dane ze źródła danych

2.na ich podstawie generuje obiekt potrzebny do wygenerowania pliku pdf

3.tworzony jest plik pdf

4.plik pdf wysyłany jest na ekran

Jak upraszczamy? Przykład postępowania (oczywiście szczegóły działania będą zależne od poszczególnego przypadku). Najpierw upewnijmy się, że komponent, którego używamy, jest poprawnie zainicjalizowany. Można na przykład podstawić za niego inny komponent (np. bardzo uproszczoną implementację komponentu) lub zainicjować go ręcznie, jeśli domyślnie jest tworzony na podstawie pliku konfiguracyjnego. Jeśli konfiguracja komponentu nie była przyczyną błędu, możemy zamiast pobierać dane ze źródła danych spreparować wyniki (badamy czy błąd zwiazany jest z wynikami pochodzącymi ze źródła danych). Następnie możemy sami wygenerować sztuczny obiekt do tworzenia pliku pdf (lub go w ogóle nie tworzyć). Zamiast tworzyć pdf (strumień binarny) można pokusić się o proste dane znakowe (strumień znakowy) i w ten sposób wykluczyć ewentualne błędy tworzenia pliku pdf i pokazywania go na ekranie. Jeśli na którymś etapie odkryjemy, że pojawia się błąd, analizujemy dany etap, stosując powyższy algorytm ograniczając go do tego etapu.

W procesie wyszukiwania błędów niezwykle przydatne są pliki logów czy systemy debugujące (choć te przy złożonych systemach, są bardzo czasochłonne). Są to jednak tylko narządzia i mogą co najwyżej wesprzeć powyżej opisany proces. Całość pracy intelektualnej musimy wykonać sami.

Oczywiście przebieg postępowania będzie inny dla innej technologii czy innej sytuacji. Jesteś ekspertem w swojej dziedzinie, więc najlepiej będziesz wiedział jak tę strategie dostosować do środowiska, w którym działasz.

Skoro jesteśmy przy wyszukiwanie błędów, to przy okazji jeszcze jedna wskazówka:

Przyczyny błędów są najczęściej ukryte tam, gdzie dalibyśmy sobie głowę uciąć, że ich tam nie ma. Najprostsza i jedna z częstszych przyczyn błędów to literówka.

Podsumowanie

Powyższe przykłady miały nieco wyraźniej nakreślić regułę upraszczania środowiska, w którym rozwiązuje się dany problem czy zadanie. Ponieważ opisane powyżej aspekty dotyczą sfery naszych nawyków i przekonań, z pewnością Czytelniku kilkakrotnie mogłeś czuć wewnętrzny opór przed zaakceptowaniem ich treści lub stwierdzić, że w twoim przypadku nie ma to zastosowania. Jest to całkiem naturalny proces, ponieważ przedstawiane powyżej tezy przynależą do świata nauk humanistycznych, a szczególniej społecznych i psychologicznych. Nie są to pewniki. Tezy te potwierdzają się w większości przypadków, ale nie muszą we wszystkich. Ale jak to się mówi... wyjątki potwierdzają regułę.

Dokładniejsze przyjrzenie się swoim nawykom i eksperymenty związane z proponowanymi strategiami na pewno mogą stanowić dobrą zabawę, czego ci Czytelniku życzę. I oczywiście zwiększania efektywności oraz wzbogacania przyjemności z tworzenia oprogramowania.

Wzorce implementacyjne cz. 1

2008-07-08T01:05:00.004+02:00

Tutaj możesz pobrać pełną wersję PDF artykułu

Tworząc oprogramowanie tworzymy wiele tysięcy wierszy kodu. Część tego kodu jest naszym kreatywnym wysiłkiem w tworzeniu Nowego, a część to powtarzalne elementy, które pojawiają się na każdym kroku. Jako programiści nie lubimy powtarzać wiele razy tych samych czynności, a jednak to robimy, gdyż nie jesteśmy w stanie tego uniknąć. W takiej sytuacji warto nabyć pewnych nawyków, które pozwolą nam jednoznacznie i świadomie podejmować decyzje, doprowadzą do czytelnego i jasnego w przesłankach kodu.

Przytoczę za Kentem Beckiem zestaw praw, który dotyczy ogromnej części pisanego oprogramowania:

kod oprogramowania częściej jest czytany niż pisany (sic!),
w programowaniu nie istnieje stwierdzenie „zrobione” (sic!) - kod ulega bezustannemu rozwojowi,
sercem oprogramowania (niskopoziomowym) jest odpowiednie zarządzanie przepływem instrukcji oraz zarządzanie jej stanem (zmiennymi),
osoba czytająca kod musi być w stanie łatwo zrozumieć ideę, koncept zawarty w kodzie oraz łatwo dotrzeć do szczegółów implementacyjnych (kod powinien umożliwiać płynne przejście od ogólnej wizji do szczegółów i od szczegółów do wizji).

Wspomniane wcześniej nawyki, które możemy inaczej nazwać wzorcami implementacyjnymi, są w dużym stopniu subiektywną decyzją, choć prawdopodobnie większość z nich jest używana i akceptowana przez profesjonalnych programistów. Warto zatem podkreślić trzy podstawowe wartości, które stoją za przedstawianymi w tym i kolejnych artykułach wzorcami:

komunikacja (komunikatywność),
prostota,
elastyczność.

Koszt oprogramowania

Każdy programista, który brał udział w większym projekcie, wie że wytworzenie oprogramowania to tylko wierzchołek góry lodowej. System stworzony w wersji 1.0 to nie koniec podróży:

z czasem rozwija się – ulega zmianom,
należy naprawiać znalezione błędy.

Koszt całkowity jest więc dużo większy niż tylko oprogramowanie zasadniczych funkcjonalności. Co więcej, z przeprowadzonych badań statystycznych wynika, że koszt utrzymania systemu jest dużo większy niż jego wytworzenia (w średniej relacji 30%/70%).

A co to takiego ten magiczny „koszt utrzymania”? Koszt zrozumienia, zmiany, przetestowania i wdrożenia. Ile razy zaglądaliśmy do własnego kodu (nie mówiąc już o czyimś kodzie), który został stworzony pół roku wcześniej i stwierdzaliśmy, że nie wiemy o co chodzi! Stosowanie wzorców – niskopoziomowych wzorców implementacyjnych, dotyczących strategii tworzenia kodu źródłowego, upraszcza nam życie – wiemy czego spodziewać się w kodzie i wiemy, że łatwo będziemy go mogli przeczytać.

Zatem o co chodzi? Co to za wzorce? Chciałbym przedstawić kilka a może kilkanaście strategii, które ułatwią podejmowanie decyzji podczas tworzenia oprogramowania. Dla uwiarygodnienia przedstawianych propozycji, podpierał się będę kodem źródłowym projektów:

Spring Framework,
Hibernate,
Struts2,
kod źródłowy JDK6.

Oczywiście nie sposób zawrzeć tychże strategii w jednym artykule, dlatego niniejszym rozpoczynam szereg artykułów poświęconych wzorcom implementacyjnym. Do dzieła!

Klasa

Klasa jest tak podstawowym elementem programowania obiektowego, że równie trudno określić oczywiste zasady, jakimi należy posługiwać się definiując i nazywając klasy. Istnieje wiele technik, które ułatwiają wyodrębnianie klas podczas analizy, takie jak karty CRC (http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card) czy diagram klas analitycznych (Robustness Diagram) (http://www.agilemodeling.com/artifacts/robustnessDiagram.htm). Jednak ciągle to do nas jako projektantów lub programistów należy decyzja, jak stworzyć nową klasę. Jest to największa sztuka związana z programowanie obiektowym.

Pokrótce można powiedzieć, że

każda klasa powinna mieć dobrze określoną odpowiedzialność

Co oznacza dobrze? Klasa powinna być odpowiedzialna zazwyczaj za jedną rzecz w systemie.

Na przykład klasa Converter powinna dokonywać tylko i wyłącznie operacji konwersji i nie zajmować się niczym innym (np. zapisywaniem wyników konwersji do bazy danych). Po czym poznać, że klasa łamie tę zasadę? Główny objaw do duża ilość metod (choć to tylko objaw ilościowy), ostatecznie należy przeanalizować nazwy metod, a w zasadzie to, co takiego one robią. Jeśli metody nie są spójne ze sobą i wychodzą poza przeznaczenie klasy, to odpowiedzialnośc nie została dobrze określona.

Nazwa klasy musi być z jednej strony zwięzła, a z drugiej strony oddająca w pełni przeznaczenie klasy.

Nadanie nazwy klasie to próba pogodzenia dwóch skrajnych sił – z jednej strony nazwa powinna być jak najkrótsza i jak najprosztsza (łatwiej ją zapamiętać, skojarzyć), a z drugiej strony musi precyzyjnie odzwierciedlać przeznaczenie klasy (co czasem wymaga dłuższych nazw). Jedna z najważeniejszych funkcji nazwy klasy to komunikatywność. W praktyce nie warto od razu szukać idealnej nazwy, tylko na początku nadać taką, która nam przychodzi do głowy, a z czasem gdy odnajdziemy dużo lepszą, zmienić ją. W dobie zaawansowanych narzędzi refaktoryzacji, zmiana nazwy klasy nie powinna być zbyt wielkim problemem.

Warto w praktyce dążyć w pierwszej kolejności do nazw klas złożonych z jednego słowa (mam tu na myśli przede wszystkim klasy, które nie są dziedziczone z innych), gdyż łatwiej je zapamiętać. Ponadto nazwa klasy powinna być jak najbliższa świata klienta (słowem z jego dziedziny), jeśli klasa odzwierciedla element świata klienta.

Jest jeszcze jedna wskazówka, którą warto się kierować:

Im mniej klas w projekcie, tym lepiej

Oczywiście kierunek jej oddziaływania jest przeciwny do kierunku oddziaływania reguły, która nakazuje wyodrębnianie jednoznacznej odpowiedzialności, gdyż ta z kolei powoduje większe rozdrobnienie klas. Tutaj jednak musimy działać zgodnie z maksymą wypowiedzianą przez Einsteina: twórzmy rzeczy najprościej jak tak tylko możliwe, ale nie prościej.Te dwie siły trzeba w praktyce zrównoważyć. Z jednej strony tworzyć klasy od jasno określonej odpowiedzialności, z drugiej starać się ograniczać ilość powstających klas. Im więcej klas, tym więcej nazw do zapamiętania, miejsc do analizowania, debugowania, testowania itp. itd.

Podsumowując powyższe rozważania:

klasa musi mieć dobrze określoną odpowiedzialność (jednoznacznie) i wszystkie metody muszą być spójne z tą odpowiedzialnością,
nazwa klasy powinna być zwięzła, ale z drugiej strony jednoznacznie wyrażająca odpowiedzialność klasy,
w pierwszej kolejności należy szukać nazw złożonych z jednego słowa,
im mniej klas w projekcie tym lepiej.

Dobrym case study są projekty open source. Jeśli nie znasz omawianej biblioteki, nie ma to większego znaczenia, gdyż zazwyczaj nie będziemy analizować funkcjonalności tychże, jakże wspaniałych narzędzi, a przyjrzymy się bliżej strukturze ich klas.

Na początek spójrzmy na klasę org.hibernate.cfg.Configuration z projektu Hibernate 3. Nazwa Configuration jest łatwa, jednoznaczna, wydaje się świetnie oddawać odpowiedzialność obiektu – jest to klasa skupiająca w sobie informacje związaną z konfiguracją Hibernate'a.
Jak się bliżej przyjrzymy zawartości klasy, to zobaczymy m. in. takie elementy:

public class Configuration implements Serializable {

  private static Logger log = LoggerFactory.getLogger( Configuration.class );

  protected Map classes;
  protected Map imports;
  protected Map collections;
.........
  public Configuration addFile(File xmlFile) throws MappingException {
.........
  public Configuration addXML(String xml) throws MappingException {
.........
  protected void parseMappingElement(Element subelement, String name) {
..........
  private void parseSecurity(Element secNode) {
..........

Oprócz metod do przechowywania i zarządzania konfiguracją, pojawiają się m. in. metody do parsowania pliku XML. Tutaj można poddać wątpliwość jednoznaczność odpowiedzialności tejże klasy, gdyż zaczyna być ona odpowiedzialna za parsowanie pliku XML. Choć można by szukać uzasadnienia tej decyzji w zasadzie im mniej klas, tym lepiej.

Inna klasa z tego samego projektu org.hibernate.cfg.Mapping, budzi mniejsze wątpliwości – do tej klasy wydzielono wszelkie elementy związane z mapowaniem ORM (http://en.wikipedia.org/wiki/Object-relational_mapping). Nazwa klasy jest prosta, jednoznaczna i ekspresyjna.

Spójrzmy jeszcze na podwórko jdk6. Klasa java.text.DateFormat ma bardzo ostro określoną odpowiedzialność – formatowanie dat w zależności od ustawień regionalnych (Locale). Jednoznaczna i prosta nazwa (potrzebne były dwa słowa do tego celu).

Takich przykładów znajdziemy tu bardzo dużo np.:

java.util.regex.Matcher – nazwa jasno wyraża odpowiedzialność – zbiór operacji związanych z dopasowywaniem wyrażeń regularnych,
java.net.Socket – nazwa jasno i jednoznacznie określa przeznaczenie klasy – reprezentacja gniazda TCP oraz zbiór operacji na tym gnieździe.

Analizując kod źródłowy projektów Hibernate i jdk6 wyraźnie widać preferencje, którymi zaznaczają się w tych projektach:

w Hibernate często zdarza się łamanie zasad odpowiedzialności na rzecz zmniejszenia ilości klas w projekcie (których i tak jest dużo), co często jednak prowadzi do powstawania trudnych do ogarnięcia klas (kilkanaście a nawet kilkadziesiąt metod),
w jdk6 (i wcześniejszych również) tendencja jest zgoła odwrotna, zdecydowanie nacisk kładzie się na ostrą, jednoznaczną odpowiedzialność, kosztem wytwarzania dużej ilości klas – np. żeby obsłużyć w pełni wyrażenie regularne potrzeba aż trzech klas (!).

Polecam analizę kodów źródłowych tychże projektów oraz pozostałych (np. spring framework), gdyż jest to jeden z najlepszych praktycznych nauczycieli naprawdę dobrego stylu pisania oprogramowania.

Już samo podjęcie decyzji jaką stworzyć klasę (jaka odpowiedzialność, jakie metody, jaka nazwa), jest nielada wyzwaniem. Dlatego warto poświęcić wieczór, aby przeanalizować za i przeciw, tak aby trafnie podejmować tę jedną z częściej podejmowanych decyzji.

Oczywiście to zaledwie początek i wierzchołek góry lodowej. Niebawem nieco rozważań na temat interfejsów.

Porządki w kodzie czyli nie tylko o refaktoringu

2008-06-19T22:13:00.000+02:00

Blogspot niestety rozczarowuje mnie pod kątem publikowania kodu źródłowego, co jest szczególnie ważne w przypadku tematów poruszających styl kodowania. Być może ktoś z was ma jakieś doświadczenia lub pomysły w tej kwestii. Ja używam narzędzia http://formatmysourcecode.blogspot.com/2006/02/paste-your-text-here.html, ale mimo wszystko blogspot raz na jakiś czas deformatuje posta :/

Poniżej zamieszczam cały artykuł poświęcony porządkom w kodzie - poprawnie sformatowany.

Tutaj możesz pobrać pełną wersję PDF artykułu

Porządki w kodzie czyli nie tylko o refaktoringu cz. 3

2008-06-19T19:42:00.000+02:00

Tutaj możesz pobrać wersję PDF artykułu

Ze względu na problemy z formatowaniem kodu w blogspot artykuł ten warto przeczytać w formie pliku PDF.

Przyjrzyjmy się teraz metodzie boolMultipy oraz zmiennej lokalnej o nazwie sum. Zmienna ta jest deklarowana na samym początku metody, uzywana jest dużo później. Jest to nawyk, który pozostał jeszcze po językach proceduralnych (takich jak wczesne C przy PL/SQL), gdzie wymaga się zadeklarowania wszystkich zmiennych używanych w metodzie na samym początku. Na szczęście większość współczesnych języków programowania (w szczególności języków obiektów) nie ma tego ograniczenia. Zamiast tego podejścia sugeruję realizację zasady leniwej deklaracji zmiennych, którą można wyrazić za pomocą zdania

Deklaruj zmienne najpóźniej jak to tylko możliwe

Warto to robić z bardzo prostego powodu – łatwiej będzie czytać kod, jeśli w zasięgu wzroku będziemy mieli operacje wykonywane na danej zmiennej. Przy bardziej złożonych metodach umieszczenie deklaracji na samym początku, może spowodować, że analizując dalszą część metody nie będziemy w stanie zorientować się czy zmienna była do tej pory przetwarzana czy nie i co wpłynęło na jej wartość.

Załóżmy, że przewinęliśmy ekran tak, że widzimy następujący kod:

        for( int i = 0; i < len; i++ ) {

if ( this.get(i) && extendedBitSet.get(i) ) {
  sum++;
}

}

return sum % 2 ;

Rodzi się we mnie natychmiast pytanie – a co to za suma? Czy działo się z nią coś wcześniej? Czy może jej wartość została pobrana z zewnątrz?

W przypadku jednej zmiennej jeszcze to nie jest duży problem, ale wyobraźmy sobie sytuację, kiedy takich zmiennych jest pięć. Śledzenie logiki takiej metody będzie bardzo trudne.

Bardzo prosta operacja przeniesienia deklaracji nieco niżej spowoduje, że kod będzie dużo bardziej czytelny:

    public int boolMultiply( ExtendedBitSet extendedBitSet ) {

int len = 0;

if( this.fixedLength < extendedBitSet.fixedLength ) {
len = this.fixedLength;
} else {
len = extendedBitSet.fixedLength;
}


int sum = 0;
for( int i = 0; i < len; i++ ) {

if ( this.get( i ) && extendedBitSet.get( i ) ) {
   sum++;
}

}

return sum % 2 ;
}

Nieco bardziej złożona sytuacja jest w metodzie toByteArray. Jest ona niesamowicie trudna w analizie. Mi zajęło około 20 minut zrozumienie zasady jej działania. Teraz sobie wyobraźmy projekt złożony z tysiąca klas, z których każda zawiera tego typu metody. Zapanowanie nad takim kodem będzie graniczyło z cudem. Spójrzmy na kod tej metody:

    public byte[] toByteArray() {
int bytesNumber = 0;

if ( fixedLength % 8 == 0 ) {
bytesNumber = fixedLength / 8;
} else {
bytesNumber = fixedLength / 8 + 1;
}

byte [] arr = new byte[ bytesNumber ];

for( int j = bytesNumber - 1, k = 0; j >= 0 ; j--, k++ ) {

for( int i = j * 8 ; i < ( j + 1 ) * 8; i++ ) {    

    if ( i == fixedLength ) {
        break;
    }

    if ( get( i ) ) {
        arr[ k ] += (byte) Math.pow( 2, i % 8 );
    }

}

}    

return arr;
}

Metoda toByteArray zwraca bajtową reprezentacje ciągów bitowych – czyli ciąg bitowy o długości 14 bitów można zaprezentować za pomocą 2 bajtów, zaś ciąg bitowy o długości 23 bity można zaprezentować za pomocą 3 bajtów.

Algrotym można opisać w następujących krokach:

określ liczbę bajtów,
dla każdej ósemki bitów (lub kilku bitów w przypadku niepełnych bajtów) wykonaj następującą operację:
- sprawdź wartość każdego bitu
- jeśli bit ma wartość 1, dodaj odpowiednią potęgę dwójki (wynikającą z pozycji bitu w bajcie) do wyniku danego bajtu.

Dlaczegóżby nie wyrazić tego algorytmu w formie programistycznej? Często o tym się zapomina. Jako programiści próbujemy w zwięzły sposób wyrazić nasze pomysły, co zazwyczaj prowadzi do bardzo nieczytelnych rozwiązań, których nie tylko inni ale i my sami nie jesteśmy w stanie zrozumieć w krótkim czasie. Ideałem jest dążenie do tego, aby jedno spojrzenie wystarczyło do odszyfrowania intencji twórcy. Nie potrzebujemy zagłębiać się w szczegóły realizacji algortmu, ważne byśmy wychwycili jego główną myśl. Spójrzmy na inną implementację metody toByteArray:

    public byte[] toByteArray() {

int bytesCount = computeBytesCount();

byte [] byteArray = new byte[ bytesCount ];

for ( int i = 0; i < bytesCount; ++i ) {

 int byteNumber = bytesCount - i - 1;
 byteArray[ byteNumber ] = computeByteValue( i );

}

return byteArray;
}

Najważniejsza zmiana, polega na bezpośrednim wyrażeniu algorytmu na ogólnym poziomie. Dzięki czemu jesteśmy w stanie w krótkim czasie zrozumieć intencję twórcy. Pomocnicza metoda computeBytesCount znajduje ilość bajtów nowej reprezentacji. W pętli dla każdego bajtu wykonywana jest operacja obliczania wartości bajtu i zapamiętywania wyniku. Czyż taki zapis nie jest dużo prostszy? Co z tego, że nie widać wszystkich elementów realizacji algorytmu. Bardziej dociekliwi zawsze mogą zajrzeć do metod computeBytesCount i computeByteValue.

Mogą one wyglądać następująco:

  private byte computeByteValue( int byteNumber ) {

int firstBitPosition = byteNumber * 8;
int lastBitPosition = ( byteNumber + 1 ) * 8 - 1;

byte byteValue = 0;

for ( int i = this.nextSetBit( firstBitPosition );
  i >= firstBitPosition &&  i <= lastBitPosition;
          i = this.nextSetBit( i + 1 ) ) {

  int currentBitPosition = i - firstBitPosition;

  if ( get( i ) == true ) {
      byteValue += (byte) Math.pow( 2, currentBitPosition % 8 );
  }

}

return byteValue;
}

private int computeBytesCount() {
int bytesCount = 0;

if ( fixedLength % 8 == 0 ) {
  bytesCount = fixedLength / 8;
} else {
  bytesCount = fixedLength / 8 + 1;
}

return bytesCount;
}

Warto zauważyć, że kod realizujący zadanie zbytnio się nie uprościł, ale dużo łatwiej jest go teraz przeanalizować i zrozumieć. Teoria refaktoringu nazywa tego typu działania wyłuskiwaniem metody (ang. extract method). Prawdę mówiąc tutaj poszliśmy nieco dalej, gdyż zmodyfikowaliśmy nieco implementację algorytmu, tak aby stała się bardziej czytelna. Zwróćmy uwagę na wiersze:

   int firstBitPosition = byteNumber * 8;

int lastBitPosition = ( byteNumber + 1 ) * 8 - 1;

Tak naprawdę są one wyodrębnieniem bardzo enigmatycznych wyrażeń z wiersza:

    for( int i = j * 8 ; i < ( j + 1 ) * 8; i++ ) {

Czyż intencja w takim przypadku nie staje się oczywista? Moje wieloletnie doświadczenia doprowadziły mnie do wniosku:

Jawnie nazywaj złożone elementy kodu

zamiast

    j * 8

napisz

    int firstBitPosition = byteNumber * 8;

Zasadę te rozszerzam do instrukcji warunkowych. Często w kodzie możemy spotkać wyrażenia, za którymi kryje się pewna logika. Warto bezpośrednio wyrazić naszą intencję. Czytelność niesamowicie wzrasta.

Zamiast

    if ( index >= 0 )

napisz

    boolean isIndexInRange = ( index >= 0 );

if ( isIndexInRange )

Kod zaczyna się czytać jak książkę! Przecież programowanie jest dla ludzi. Ułatwiajmy zatem sobie życie.

A oto najważniejsza zasada, będąca kwintesencją powyższych rozważań:

Pisz kod w taki sposób, aby czytało się go jak powieść. Używaj jednoznacznych i jednocześnie prostych nazw. Realizowane operacje dziel na logiczne części i każdą implementuj w osobnych metodach.

Myślę, że jak na jeden raz, wystarczy. Wystarczy, żeby zaostrzyć apetyty i wzbudzić ochotę na więcej. Żeby oprowadzić nieco po ogrodzie refaktoringu i jego przyległościach. Zapewniam, że to niesamowite miejsce i daje niesamowicie wiele radości i satysfakcji.

Poniżej zamieszczam ostateczną wersję kodu, który przechodzi załączone testy (oczywiście ze zmianą uwzględniającą niestatyczność metod merge i boolMultiply).

Końcowa postać przykładowej klasy (warto ją porównać z postacią początkową):

public class ExtendedBitSet extends BitSet {

 private int fixedLength = 0;

 public ExtendedBitSet( int size, String str ) {
     super( size );

     fixedLength = size;
     initializeBitSet( str );
 }

 public ExtendedBitSet( String str ) {
     this( str.length(), str );

     initializeBitSet( str );
 }

 private void initializeBitSet( String str ) {

     int strLength = str.length();

     for( int i = 0; i < strLength; ++i ) {

         if ( str.charAt( strLength - 1 - i ) == '1' ) {
             set( i );
         }

     }

 }

 public void merge( ExtendedBitSet extendedBitSet ) {

     for ( int i = extendedBitSet.nextSetBit( 0 ); i >= 0;
                     i = extendedBitSet.nextSetBit( i + 1 ) ) {

         this.set( this.fixedLength + i );
     }

     this.fixedLength = this.fixedLength + extendedBitSet.fixedLength;
 }

 public int boolMultiply( ExtendedBitSet extendedBitSet ) {
     int len = 0;

     if( this.fixedLength < extendedBitSet.fixedLength ) {
         len = this.fixedLength;
     } else {
         len = extendedBitSet.fixedLength;
     }

     int sum = 0;

     for( int i = 0; i < len; i++ ) {

         if ( this.get( i ) && extendedBitSet.get( i ) ) {
             sum++;
         }

     }

     return sum % 2 ;
 }

 public byte[] toByteArray() {

     int bytesCount = computeBytesCount();
     byte [] byteArray = new byte[ bytesCount ];
  
     for ( int i = 0; i < bytesCount; ++i ) {         

         int byteNumber = bytesCount - i - 1;
         byteArray[ byteNumber ] = computeByteValue( i );

     }

     return byteArray;
 }

 private byte computeByteValue( int byteNumber ) {
     int firstBitPosition = byteNumber * 8;
     int lastBitPosition = ( byteNumber + 1 ) * 8 - 1;

     byte byteValue = 0;

     for ( int i = this.nextSetBit( firstBitPosition );
         i >= firstBitPosition &&  i <= lastBitPosition;
                 i = this.nextSetBit( i + 1 ) ) {

         int currentBitPosition = i – firstBitPosition;

         if ( get( i ) == true ) {
             byteValue += (byte) Math.pow( 2, currentBitPosition % 8 );
         }

     }

     return byteValue;
 }


 private int computeBytesCount() {

     int bytesCount = 0;

     if ( fixedLength % 8 == 0 ) {
         bytesCount = fixedLength / 8;
     } else {
         bytesCount = fixedLength / 8 + 1;
     }

     return bytesCount;
 }

 public String convertToBitString( int size ) {

     char [] resultArray = new char[ size ];

     for ( int i = 0; i < size; ++i ) {
         resultArray[ i ] = '0';
     }

     for ( int i = this.nextSetBit( 0 ); i >= 0; i = this.nextSetBit( i + 1 ) ) {
         resultArray[ size - 1 - i ] = '1';
     }

     return new String( resultArray );
 }

 public String convertToBitString() {

     return convertToBitString( this.fixedLength );

 }

}

Dodatek. Test przykładowej klasy.

public class ExtendedBitSetTest extends TestCase {

  public void testConstructorSizeAndString() throws Exception {

      assertEquals( "{0, 2}", new ExtendedBitSet( 10, "101" ).toString() );
      assertEquals( "0000000101", new ExtendedBitSet( 10, "101" ).convertToBitString() );
      assertEquals( "0000001011", new ExtendedBitSet( 10, "1011" ).convertToBitString() );
      assertEquals( "0010001011", new ExtendedBitSet( 10, "10001011" ).convertToBitString() );
      assertEquals( "{0, 1, 3, 7}", new ExtendedBitSet( 10, "10001011" ).toString() );
      assertEquals( "{0}", new ExtendedBitSet( 10, "001" ).toString() );
      assertEquals( "0000000001", new ExtendedBitSet( 10, "001" ).convertToBitString() );
      assertEquals( "00000000001", new ExtendedBitSet( 10, "001" ).convertToBitString( 11 ) );
  }

  public void testMerge() throws Exception {

      ExtendedBitSet extendedBitSet1 = new ExtendedBitSet( 10, "1" );
      ExtendedBitSet extendedBitSet2 = new ExtendedBitSet( 10, "1" );

      assertEquals( "0000000001", extendedBitSet1.convertToBitString() );
      assertEquals( "0000000001", extendedBitSet2.convertToBitString() );

      ExtendedBitSet mergedBitSet = ExtendedBitSet.merge( extendedBitSet1, extendedBitSet2 );
      String mergedString = mergedBitSet.convertToBitString();

      assertEquals( "00000000010000000001", mergedString );
      assertEquals( "{0, 10}", mergedBitSet.toString() );
      assertTrue( mergedBitSet.get( 0 ) == true );
  }

  public void testBoolMultiple() throws Exception {

      ExtendedBitSet extendedBitSet1 = new ExtendedBitSet( 3, "1" );
      ExtendedBitSet extendedBitSet2 = new ExtendedBitSet( 10, "1" );

      assertEquals( 1, ExtendedBitSet.boolMultiply( extendedBitSet1, extendedBitSet2 ) );

      extendedBitSet1 = new ExtendedBitSet( 1000, "1" );
      extendedBitSet2 = new ExtendedBitSet( 2, "1" );

      assertEquals( 1, ExtendedBitSet.boolMultiply( extendedBitSet1, extendedBitSet2 ) );

      extendedBitSet1 = new ExtendedBitSet( 10, "1" );
      extendedBitSet2 = new ExtendedBitSet( 10, "1" );

      assertEquals( 1, ExtendedBitSet.boolMultiply( extendedBitSet1, extendedBitSet2 ) );

      extendedBitSet1 = new ExtendedBitSet( 10, "1" );
      extendedBitSet2 = new ExtendedBitSet( 10, "10" );

      assertEquals( 0, ExtendedBitSet.boolMultiply( extendedBitSet1, extendedBitSet2 ) );

      extendedBitSet1 = new ExtendedBitSet( 10, "10" );
      extendedBitSet2 = new ExtendedBitSet( 10, "10" );

      assertEquals( 1, ExtendedBitSet.boolMultiply( extendedBitSet1, extendedBitSet2 ) );

      extendedBitSet1 = new ExtendedBitSet( 10, "110" );
      extendedBitSet2 = new ExtendedBitSet( 10, "110" );

      assertEquals( 0, ExtendedBitSet.boolMultiply( extendedBitSet1, extendedBitSet2 ) );
  }

  public void testToByteArray() throws Exception {

      ExtendedBitSet extendedBitSet = new ExtendedBitSet( "100000110" );
      byte[] toByteArray = extendedBitSet.toByteArray();

      assertEquals( 1, toByteArray[ 0 ] );
      assertEquals( 6, toByteArray[ 1 ] );

      extendedBitSet = new ExtendedBitSet( "10111111111" );

      toByteArray = extendedBitSet.toByteArray();

      assertEquals( 5, toByteArray[ 0 ] );
      assertEquals( -1, toByteArray[ 1 ] );
  }
}

Porządki w kodzie czyli nie tylko o refaktoringu cz. 2

2008-06-18T00:40:00.000+02:00

Tutaj możesz pobrać wersję PDF artykułu

Ze względu na problemy z formatowaniem kodu w blogspot artykuł ten warto przeczytać w formie pliku PDF.

Zatem zrobiliśmy pierwszy krok w kierunku uporządkowania pierwotnego kodu.

Zróbmy zatem kolejny. Przyjrzyjmy się bliżej następującemu fragmentowi:

public class ExtendedBitSet extends BitSet {

 int length ;

Pole klasy length ma widoczność pakietową. Prawdopodobnie nie to było zamierzeniem autora. Być może zapomniał w sposób jawny napisać odpowiedni modyfikator dostępu. W każdym razie warto znać jedną z podstawowych konsekwencji tego rozwiązania: pole to będzie dostępne dla wszystkich klas w pakiecie, co ogranicza jego enkapsulacje informacji. Przypadek ten można uogólnić do stwierdzenia:

Nadawaj najbardziej restrykcyjny z możliwych modyfikatorów dostępu

W tym przypadku byłby to oczywiście modyfikator prywatny:

    private int length;

W przypadku gdy tworzona klasa będzie klasą bazową innych klas oraz będzie potrzeba udostępnienia tego pola, należy użyć modyfikatora dostępu protected:

    protected int length;

Dobrą praktyką jest jednak wybieranie modyfikatora private, aż do momentu, gdy nie zaistnieje potrzeba użycia tego pola w klasie podrzędnej (czyli do momentu wyprowadzania nowych klas). Jest to analogia do typowej dla administratorów sieciowych strategii bezpieczeństwa: domyślnie blokuj.

Poza powyższymi uwagami, chciałbym zaproponować jeszcze jedno udoskonalenie. Jestem zwolennikiem jawnego inicjalizowania zmiennych, gdyż jest to bezpośrednie ujawnienie intencji autora. Jeśli tworzę pole obiektowe, to jawnie przypisuję mu wartość początkową na null, kiedy tworzę liczbę całkowitą inicjuję ją zerem. W ten sposób oszczędzam potencjalnemu czytelnikowi mojego kodu domyślania się, czy rzeczywiście chodziło mi o wartość domyślną, czy być może nie dokońca znając szczegóły języka, przyjąłem błędne założenie. W przypadku wyszukiwania przyczyn błędów może to mieć duże znaczenie.

Zatem podsumowując:

Jawnie inicjuj pola i zmienne

W efekcie uzyskamy takie rozwiązanie:

    private int length = 0;

W powyżej przytoczonym wierszu ujawnił się jeszcze jeden nawyk związany ze sposobem programowania

Jak najwięcej przestrzeni dla Twoich oczu

Wzrok lubi przestrzeń. Nie lubi zbitych zdań, ogromnych ilości wyrażeń na niewielkiej przestrzeni. Zróbcie prosty eksperyment. Weźcie niewielki fragment swojego kodu i dodajcie kilka spacji (pomiędzy operatorami, pomiędzy wierszami) i porównajcie, który zapis jest czytelniejszy.

Oto przykład:

    public byte[] toByteArray() {
    int bytesNumber ;
    if(length % 8 == 0) bytesNumber = length / 8 ;
    else bytesNumber = length / 8 + 1 ;
    byte[] arr = new byte[bytesNumber] ;
    for(int j = bytesNumber - 1, k = 0; j >= 0 ; j--, k++) {
        for(int i = j * 8 ; i < (j + 1) * 8; i++){
            if(i == length) break ;
            if(get(i)) arr[k] += (byte)Math.pow(2, i % 8) ;
        }
    }                    
    return arr ;
}

oraz wersja przestrzenna:

    public byte[] toByteArray() {

     int bytesNumber = 0;

     if ( length % 8 == 0 ) {
         bytesNumber = length / 8;
     } else {
         bytesNumber = length / 8 + 1;
     }

     byte [] arr = new byte[ bytesNumber ];

     for( int j = bytesNumber - 1, k = 0; j >= 0 ; j--, k++ ) {

         for( int i = j * 8 ; i < ( j + 1 ) * 8; i++ ) {

             if ( i == length ) {
                 break;
             }

             if ( get( i ) ) {
                 arr[ k ] += (byte) Math.pow( 2, i % 8 );
             }

         }

     }             

     return arr ;
 }

Modyfikacja ta zajęła mi około dwóch minut. Jednak umiejętność tworzenia kodu zgodnego ze stylem kodowania, która jest moim nawykiem, umożliwia mi pisanie takiego kodu bez żadnego dodatkowego nakładu czasu. Za to jaka przyjemność z czytania! A to dopiero początek. Kiedy mówimy o stylu kodowania przychodzi mi do głowy jeszcze jedna reguła:

Używaj konsekwentnie przyjętego standardu kodowania

Obecnie nie wyobrażam sobie tworzenia kodu, który nie podlega z góry ustalonym zasadom. Jeśli chodzi o pracę w zespole, jest to wręcz warunek konieczny pracy grupowej. A mamy ogromne wsparcie, gdyż istnieje wiele gotowych do wykorzystania standardów, np. Code Conventions for the Java Programming Language (http://java.sun.com/docs/codeconv/), oraz narzędzi, które pomogą go, szczególnie w początkowym okresie, sumiennie przestrzegać (Checkstyle http://checkstyle.sourceforge.net/).

Poniżej znajduje się przykład omawianej klasy sformatowany wg standardu opartego na standardzie zaproponowanym przez Suna.

public class ExtendedBitSet extends BitSet {

  private int length = 0;

  public ExtendedBitSet( int size, String str ) {
      super( size );

      length = size;
      int strLength = str.length();

      for( int i = 0; i < strLength; ++i ) {          

          if ( str.charAt( strLength - 1 - i ) == '1' ) {
              set( i );
          }

      }

  }

  public ExtendedBitSet( String str ) { 
      super( str.length() );

      int strLength = str.length();
      length = strLength;

      for( int i = 0; i < strLength; ++i ) {

          if( str.charAt( strLength - 1 - i ) == '1' ) {
              set( i );
          }

      }

  }

  public void merge( ExtendedBitSet extendedBitSet ) { 

      for ( int i = extendedBitSet.nextSetBit( 0 ); i >= 0;
                      i = extendedBitSet.nextSetBit( i + 1 ) ) {

          this.set( this.length + i );
      }

      this.length = this.length + extendedBitSet.length;
  }

  public int boolMultiply( ExtendedBitSet extendedBitSet ) {

      int sum = 0;
      int len = 0;

      if( this.length < extendedBitSet.length ) {
          len = this.length;
      } else {
          len = extendedBitSet.length;
      }

      for( int i = 0; i < len; i++ ) { 

          if ( this.get(i) && extendedBitSet.get(i) ) {
              sum++;
          }

      }

      return sum % 2 ;
  }

  public byte[] toByteArray() {

      int bytesNumber = 0;

      if ( length % 8 == 0 ) {
          bytesNumber = length / 8;
      } else {
          bytesNumber = length / 8 + 1;
      }
    
      byte [] arr = new byte[ bytesNumber ];

      for( int j = bytesNumber - 1, k = 0; j >= 0 ; j--, k++ ) {

          for( int i = j * 8 ; i < ( j + 1 ) * 8; i++ ) {

              if ( i == length ) {
                  break;
              }

              if ( get( i ) ) {
                  arr[ k ] += (byte) Math.pow( 2, i % 8 );
              }

          }

      }          

      return arr ;
  }

  public String convertToBitString( int size ) {

      char [] resultArray = new char[ size ];

      for ( int i = 0; i < size; ++i ) {
          resultArray[ i ] = '0';
      }

      for ( int i = this.nextSetBit( 0 ); i >= 0; i = this.nextSetBit( i + 1 ) ) {
          resultArray[ size - 1 - i ] = '1';
      }

      return new String( resultArray );
  }

  public String convertToBitString() {

      return convertToBitString( this.length );

  }
}

Wróćmy do naszego pola length. Tak naprawdę posiada ono jeszcze jeden mankament – jego nazwa jest dokładnie taka sama jak nazwa metody z klasy bazowej. Jest to sytuacja niekorzystna z dwóch powodów:

dwa różne byty nie powinny mieć tej samej nazwy (metoda i pole), gdyż może to prowadzić do pomyłek,
nazwa zmiennej nie odzwierciedla sensu właściwości. Pole to przechowuje wartość, która określa ustaloną długość wektora bitowego. Dużo większy sens miałaby na przykład nazwa fixedLength.

Zmieńmy zatem nazwe pola length na fixedLength.

Podsumowując powyższe rozważania:

Nie używaj jednej nazwy do różnych celów

oraz

Nadawaj polom, metodom i klasom nazwy, które jednoznacznie odzwierciedlają ich znaczenie

Analizując dalej przykład, spójrzmy na oba konstruktory, wyraźnie zauważymy pewną właściwość - jest tam mnóstwo powtarzającego się kodu. W ten sposób docieramy do zasady będącej esencją refaktoringu:

Eliminuj wszelkie powtórzenia

Powtórzenie to zło, które towarzyszy programistom na każdym kroku. Kuszące kopiuj-wklej, zazwyczaj ostatecznie prowadzi do kilkunastominutowych lub co gorsza wielogodzinnych poszukiwań błędów, wynikających z rozsynchronizowania się podobnych fragmentów kodu. Powtórzenia na dłuższą metę są nie do utrzymania, stąd ich eliminowanie jest podstawowym celem wszelkich refaktoringów. Przykładowy kod możemy zmienić do następującej postaci:

    public ExtendedBitSet( int size, String str ) { 
       super( size );

       fixedLength = size;
       initializeBitSet( str );
   }
   public ExtendedBitSet( String str ) {
       this( str.length(), str );  

       initializeBitSet( str );
   }
  
   private void initializeBitSet( String str ) {
       int strLength = str.length();       

       for( int i = 0; i < strLength; ++i ) {           

           if ( str.charAt( strLength - 1 - i ) == '1' ) {
               set( i );
           }

       }

   }

Kod nam się powoli porządkuje i wygląda coraz lepiej. Wprowadziliśmy zmiany związane z wyglądem (standard kodowania i przestrzeń), wyeliminowaliśmy kilka powtórzeń i niejednoznaczności. Oczywiście zawsze należy wyważyć stopień refaktorowania lub upiększania kodu, tak aby nie stać się ofiarą perfekcjonizmu. Warto wesprzeć się pomocą innych programistów, najlepiej takich, którzy sami posługują się pewnymi zasadami oraz posiadają duże doświadczenie, i poprosić o opinię. Z pewnością wiele można się będzie dowiedzieć na temat swojego programowania.

Porządki w kodzie czyli nie tylko o refaktoringu cz. 1

2008-06-08T14:31:00.000+02:00

Tutaj możesz pobrać wersję PDF artykułu

Ze względu na problemy z formatowaniem kodu w blogspot artykuł ten warto przeczytać w formie pliku PDF.

Początkowo moim zamysłem było stworzenie artykułu o refaktoringu. Jednak im bardziej zastanawiałem się nad tematem, tym bardziej utwierdzałem się w przekonaniu, iż nie będę pisał tylko i wyłącznie o refaktoringu. Chodzi o coś znacznie istotniejszego, o przelanie bardzo rozległej wiedzy, a w zasadzie doświadczenia związanego z tworzeniem kodu. Kodu, który nie tylko działa, nie tylko jest dobrze zaprojektowany, ale przede wszystkim doskonale się czyta. Kiedy osiągamy tę umiejętność, stajemu u progu profesjonalizmu. Programistycznego profesjonalizmu.

Zatem będzie to artykuł między innymi o refaktoringu, ale wzbogacony o zbiór przemyśleń, sugestii, czasami również wątpliwości, którą mają pobudzić Cię, Czytelniku, do refleksji, zweryfikowania swoich programistycznych poczynań. Wierzę, że spowodują cały proces zmian – wprowadzenia nowych, dobrych nawyków.

Przede wszystkim czytelność

Programowanie bardzo szybko ewoluuje. Pamiętam jeszcze dość dobrze czasy, kiedy rozpocząłem swoją przygodę z kodowaniem jakieś dziesięć lat temu. Programy pisało się wtedy całkiem inaczej. Ceniono pomysłowość, zwięzłość i enigmatyczność. Im kod był bardziej niezrozumiały, tym programista był lepszy.

Jednak z czasem systemy informatyczne stawały się coraz bardziej skomplikowane, wymagały coraz większej wiedzy i co najważniejsze, stały się produktem pracy zespołowej. Obecnie pojedynczy programista nie jest w stanie zdziałać zbyt wiele. Być może stworzy rozbudowany program desktopowy, natomiast nie będzie w stanie w wystarczająco skończonym czasie stworzyć rozproszonego systemu, opartego o architekturę trójwarstwową, zapewniającego odpowiedni poziom bezpieczeństwa, umożliwiającego zarządzanie prawami dostępu do wybranych części aplikacji, realizującym wielojęzyczność itp. itd. Takie systemy tworzy obecnie kilkunastu lub kilkudziesięciu programistów, w zależności od wielkości projektu, przez kilka lub kilkanaście miesięcy. Programista przestał być nierozumianym przez nikogo indywidualistą, a stał się graczem zespołowym, nastawionym na współpracę.

Co za tym idzie, sposób kodowania też musiał się zmienić. Wyłonił się podstawowy postulat dotyczący kodowania:

Przede wszystkim czytelność

Istnieją przynajmniej trzy podstawowe powody, które potwierdzają ważność tego stwierdzenia:

wymagania się zmieniają,
programowanie to umiejętność zespołowa,
projekty są zbyt duże, aby pojedyncza osoba była w stanie ogarnąć całość.

Z tych właśnie powodu w ciągu ostatnich kilku lat bardzo mocno rozwijają się takie techniki jak refaktoring, pisanie testów oraz zwraca się ogromną uwagę na standard kodowania.

To właśnie Czytelność będzie głównym bohaterem tego artykułu. Będzie on zawierać sugestie i przemyślenia, które ułatwią realizację powyższego postulatu. Niektóre wskazówki będą stanowić moją subiektywną opinię, inne będą wyrażać mądrość doświadczeń społeczności programistycznej. Oczywiście należy pamiętać o pewnej zasadzie: “Jedyną niezmienną zasadą jest to, że nie ma niezmienych zasad”. Uogólniając, należy stwierdzić, iż przedstawiane wnioski sprawdziły się w wielu sytuacjach, co nie znaczy, że są zasadne w 100% przypadkach. Dlatego należy uważnie się przyglądać pojawiającym się na co dzień problemom i odważnie stosować przytoczone wskazówki. Warto krytycznie spojrzeć na swoje nawyki lub ich brak i rozpocząć zmiany. Zatem do dzieła!

Poprzez przykład do celu

Analiza kodu mniej doświadczonych programistów, często doprowadzała mnie do zaskakujących spostrzeżeń, umożliwiających znalezienie źródła problemów młodych (ale również i tych doświadczonych) adeptów sztuki programowania. Dlatego artykuł ten oparty będzie o przykład nie najlepiej napisanej klasy, która będzie analizowana i stopniowo udoskonalana.

Celem, postawionym przed autorami poniższego kodu, było zaimplementowanie klasy pochodnej klasy java.util.BitSet (wektora bitowego) wzbogaconej o:

możliwość konkatenacji,
właściwość narzuconej długości wektora (pole length),
specyficznego mnożenia dwóch wektorów bitowych polegającego na zwróceniu wartości 0, jeśli jedynki w obu wektorach bitowych powtarzają się na parzystej ilości miejsc, oraz wartości 1, jeśli jedynki pokrywają się na nieparzystej ilości miejsc,
operację zamiany wektora na ciąg znakowy (w określonym z góry formacie),
operację zamiany wektora w ciąg bajtów.

Pragnę zaznaczyć, iż treść przykładu nie ma tu większego znaczenia. Przytoczony kod służy tylko jako ilustracja często występujących niedoskonałości programistycznych. Ponadto, ponieważ nieodłączną częścią refaktoringu są testy, sprawdzające testowany kod, jako dodatek do artykułu została zamieszczona klasa testowa do analizowanej klasy.

Oto zaproponowana implementacja nowej wersji wektora bitowego:

import java.util.* ;
public class ExtendedBitSet extends BitSet {
 int length ;
 public ExtendedBitSet(int size, String str) {
     super(size) ;
     length = size ;
     int strLength = str.length();
     for(int i = 0; i < strLength; ++i) {
         if(str.charAt( strLength - 1 - i) == '1') set(i) ;
     }
 }
 public ExtendedBitSet(String str) {
     this( str.length(), str );
     int strLength = str.length();
     for(int i = 0; i < strLength; ++i) {
         if(str.charAt( strLength - 1 - i) == '1') set(i) ;
     }
 }
 public static ExtendedBitSet merge(ExtendedBitSet a, ExtendedBitSet b) {
     StringBuffer str = new StringBuffer(a.convertToBitString() + b.convertToBitString()) ;
     return new ExtendedBitSet(a.length + b.length, str.toString()) ;
 }
 public static int boolMultiply(ExtendedBitSet a, ExtendedBitSet b) {
     int sum = 0 ;
     int len ;
     if(a.length < b.length) len = a.length ;
     else len = b.length ;
     for(int i = 0; i < len; i++) {
         if (a.get(i) && b.get(i)) sum++ ;
     }
     return sum % 2 ;
 }
 public byte[] toByteArray() {
     int bytesNumber ;
     if(length % 8 == 0) bytesNumber = length / 8 ;
     else bytesNumber = length / 8 + 1 ;
     byte[] arr = new byte[bytesNumber] ;
     for(int j = bytesNumber - 1, k = 0; j >= 0 ; j--, k++) {
         for(int i = j * 8 ; i < (j + 1) * 8; i++){
             if(i == length) break ;

             if(get(i)) arr[k] += (byte)Math.pow(2, i % 8) ;
         }
     }                     
     return arr ;
 }
 public String convertToBitString( int size ) {
     char [] resultArray = new char[ size ];
     for ( int i = 0; i < size; ++i ) {
         resultArray[ i ] = '0';
     }
     for ( int i = this.nextSetBit(0); i >= 0; i = this.nextSetBit(i + 1) ) {
         resultArray[ size - 1 - i ] = '1';
     }
     return new String( resultArray );
 }

 public String convertToBitString() {
     return convertToBitString( this.length );
 }
}

W pierwszej kolejności spójrzmy na klasę całościowo. Jedna z pierwszych rzeczy, która rzuca się w oczy to fakt, że metody konkatenacji i mnożenia wektorów są statyczne. Jest to sprzeczne z bardzo ważną zasadą:

Twórz spójne interfejsy i klasy

Jeśli przyjrzymy się klasie bazowej BitSet, łatwo zauważymy, iż żadna publiczna metoda nie jest statyczna. Dostępne są m. in. niestatyczne metody or( Bitset ), xor( Bitset ), których celem jest modyfikacja obiektu na rzecz którego są one wywolywane (operacja na this), a nie udostępnienie metody zewnętrznej (statycznej), która tworzy nowy obiekt, będący efektem implementowanej operacji. Zatem obydwie metody (merge i boolMultiply) swoją postacią wprowadzają rozdźwięk w strukturze nowej klasy, prowadząc do niespójnego interfejsu klasy ExtendedBitSet. W tym przypadku utrzymanie spójności poprzez zamianę metod statycznych na metody niestatyczne, uprości używanie klasy ExtendedBitSet, gdyż będzie się z niej korzystać tak samo jak z klasy BitSet.

Istnieje jeszcze jedna zasada, którą warto przytoczyć analizując metody merge i boolMultiply:

Unikaj statycznych elementów w programowaniu

Elementy statyczne to pozostałość po programowaniu proceduralnym, gdyż statyczność oznacza globalność. A przecież jedną z konsekwencji programowania obiektowego jest zamykanie implementowanych funkcjonalności w autonomicznych i możliwie jak najbardziej niezależnych obiektach. Dlatego elementów statyczne używaj tylko wtedy, kiedy nie ma innego wyjścia lub kiedy informacja lub operacja ma rzeczywiście charakter globalny. Zatem używaj pól statycznych jako stałych, szczególnie stałych globalnych, zaś metod statycznych używaj dla operacji globalnych. Przykładem użycia metod i pól statycznych jest wzorzec Singletonu, jednak „wzorcowość” tego wzorca bywa kwestionowana (http://c2.com/cgi/wiki?SingletonsAreEvil). Ponadto należy pamiętać, że metody statyczne nie są polimorficzne, co oznacza, że nie możemy dostarczyć ich alternatywnych implementacji oraz że nie możemy ich zastępować za pomocą mocków. Zatem ich użycie powoduje usztywnienie kodu oraz utrudnia testowanie.

Zmieńmy zatem nieco przytoczony kod, zgodnie z pierwszymi dwoma regułami:

  public void merge( ExtendedBitSet extendedBitSet ) {
     for ( int i = extendedBitSet.nextSetBit(0); i >= 0;
             i = extendedBitSet.nextSetBit(i + 1) ) {
         this.set( this.length + i );
     }
     this.length = this.length + extendedBitSet.length;
 }

 public int boolMultiply( ExtendedBitSet extendedBitSet ) {
     int sum = 0 ;
     int len ;
     if(this.length < extendedBitSet.length) len = this.length ;
     else len = extendedBitSet.length ;
     for(int i = 0; i < len; i++) {
         if (this.get(i) && extendedBitSet.get(i)) sum++ ;
     }
     return sum % 2 ;
 }

To dopiero pierwsze wprawki, więcej już niebawem.
c. d. n.

JUG Łódź

2008-06-07T19:44:00.000+02:00

Sprawy potoczyły się bardzo szybko - pierwsze info na jdn.pl, lista dyskusyjna http://groups.google.com/group/lodz-jug?hl=pl, niesamowita reakcja łódzkich fanów Javy, Javarsovia i tak po tygodniu w sobotę 07.06.2008 o godz. 16.00 odbyło się pierwsze spotkanie osób zainteresowanych rozwojem JUGu w Łodzi i chwała wszystkim za to. Trzymam kciuki i wierzę, że ta inicjatywa rozwinie się w prężnie współdziałającą grupę ludzi.
Najważniejsze założenia na najbliższy czas, to trzy miesiące testów wewnętrznych - spotkań, które mają rozkręcić zainteresowanych po to, by później rozpocząć już działania na szerszą skalę.