Senior Deweloper - a któż to jest?

gdy każdy widzi to inaczej

W mojej poprzedniej firmie mieliśmy pewnego razu kilka dyskusji dotyczących definicji ról w projektach i odpowiedniego tytułowania osób, które w nich uczestniczą. O ile nie było większych problemów z określeniem tego kim jest Junior oraz Regular Developer, to gdy przyszło do definiowania roli Seniora dyskusja zrobiła się naprawdę ciekawa :)

Po interesujących i żywych rozmowach (udało mi się nawet zaczepić ludzi na Goldenline, żeby "podkraść" dobre pomysły :), w trakcie których miałem okazję dowiedzieć się kim dla kogo jest senior i kim dla kogo nie jest, mogłem stwierdzić przede wszystkim dwie rzeczy:

• Uniwersalna definicja nie jest prosta do znalezienia.
• Przy liczbie osób większej niż jeden jest to tym mniej prawdopodobne.

Skończyło się na tym, że wróciliśmy do starego, dobrego i wypróbowanego developera :)

Visitator, czyli czas na wizytę to tu, to tam...

kolejna wizyta w świecie wzorców

Zapewne już trochę kodu mieliście okazję stworzyć odkąd pisałem o dekoratorze. Mam nadzieję, że przez ten czas mieliście możliwość go wypróbować i sprawdzić jak daje radę w świecie prawdziwych problemów.

Następnym wzorcem, z którym spróbujemy się zmierzyć będzie wizytator.
Muszę uczciwie się przyznać, że moje pierwsze z nim spotkanie, gdy wertowałem strony Wzorców Projektowych to nie była miłość od pierwszego wejrzenia i trochę czasu musiało minąć zanim w pełni doceniłem korzyści płynące z jego wykorzystania.

Ale jak tak w ogóle ten wizytator wygląda? Gdzie i po co się go stosuje?
Wierzę, że na te pytania uda mi się odpowiedzieć w poniższych akapitach.

Wzorce... wzorce są wszędzie!

Muszę szczerze przyznać, że sporo czasu upłynęło zanim książka Patterns of Enterprise Application Architecture Fowler'a trafiła z półki, na której zajmowała jedno z honorowych miejsc, do moich rąk. Przez długi czas nie mogłem się w sobie zebrać, zawsze w jakiś tajemniczy sposób znajdowała się pozycja, która skutecznie odciągała mnie od tej lektury. W końcu skończyło się na tym, że niekiedy nawet głupio było mi przyznawać się, że jeszcze jej stronic nie przewertowałem. Zebrałem się w sobie i... jakoś poszło :)

Nie pamiętam dokładnie jakie odczucia towarzyszyły mi gdy czytałem poszczególne opisy wzorców przedstawionych w książce przez Fowler'a. Miałem już za sobą lekturę Wzorców Projektowych Bandy Czworga, ba, nawet powoli zaczynała do mnie docierać wiedza w niej zawarta :) Mimo wszystko po przeczytaniu książki Fowler'a ponownie nie byłem w stanie zrozumieć wszystkiego, nie wszystkie motywacje były dla mnie jasne, niekiedy wręcz, sądziłem, że to przerost formy nad treścią, ale...

Dlaczego warto mówić jednym językiem?

Zapewne już nie raz mieliście okazję przeczytać stwierdzenie, że bardzo istotne jest to, aby w kodzie do nazywania klas domenowych wykorzystywać, te (nazwy) których używa nasz klient.
Wielu z Was uznaje to za oczywistość, wielu dodaje jakieś "ale", są tacy, którzy twierdzą, że przecież klient i tak nie wie czego chce, to po ci się przejmować. Oczywiście są też tacy, którzy sami się takimi "pierdołami" nie mają czasu przejmować, bo przecież "kod jest do napisania".
Nie powiem, że się nie da i Wasz projekt bez takiego odwzorowania nie ma szans na powodzenie, bo to nie jest prawda. Przynajmniej nie w każdym przypadku. Są jednak projekty odpowiednio duże bądź skomplikowane, gdzie ten brak spójności potrafi zauważalnie wpłynąć na tempo produkcji kodu oraz na jego jakość. Niestety, jeżeli się "nie dogadamy", to nawet mimo naszych najszczerszych chęci i przy wykorzystaniu najlepszych technik i praktyk nie unikniemy błędów.

Jak robić code review lepiej i krócej?

Code review jest to jedna z tych aktywności, do której niektórych bardzo ciężko przekonać, bo przecież to "kolejna rzecz do zrobienia". pamiętajcie jednak, że więcej nie znaczy wolniej i naprawdę warto spróbować, bo potencjalne korzyści są naprawdę duże.
Dzisiaj jednak nie mam na celu namawiania Was do wypróbowania tej aktywności w Waszym projekcie. Dzisiaj kilka rad dla tych, którzy już code review praktykują oraz dla tych, którzy mają w planach dodanie tej aktywności do swojego harmonogramu :)

Publiczne metody w abstrakcie = interfejs istnieje

a zaczęło się to tak...

Jak każdy (a przynajmniej mam taką nadzieję) zespół ludzi pracujący nad tym samym kodem, i w naszym projekcie istnieje dokument ze standardami kodowania. Co jakiś czas wprowadzamy drobne modyfikacje, bo refaktoryzować można (i powinno się) nie tylko kod :)

Dzisiaj ten właśnie dokument przeglądał jeden z moich kolegów i natknął się na jedną z moich notatek/uwag w tym dokumencie, którą odrobinę przeredagowaną (niestety użyłem skrótów myślowych pisząc ją :) zamieszczam poniżej:
Jeżeli posiadasz klasę abstrakcyjną z metodą publiczną, która jest rozszerzana przez kilka klas nie implementujących tego samego interfejsu, to wiedz, że coś się dzieje.

Dobra, samo stwierdzenie może nie być zbyt oczywiste, ale wierzę, że po krótkich wyjaśnieniach dojdziecie nie tylko do wniosku, że ma to sens, ale co więcej, że sami już tą zasadę w kodzie stosujecie.
Jakby na to nie patrzeć, jest całkiem naturalna :)

SOLIDny kod

kolejna seria za nami

Następna seria wpisów skończona. Mam nadzieję, że udało mi się przedstawić omawiane zasady w jasny i zrozumiały sposób.

Dzisiaj jedynie krótki wpis, w którym chciałem zebrać linki do opublikowanych postów. Zdaję sobie sprawę, że spis treści zazwyczaj jest na początku, ale mam nadzieję, że mi wybaczycie tą ekstrawagancję :)

O zasadach SOLID jeszcze z pewnością nie raz napiszę, a jeżeli w między czasie będziecie mieli jakieś pytania lub wątpliwości to czekam na komentarze, może uda mi się coś więcej rozjaśnić, a może sam się czegoś nowego nauczę :)

A w międzyczasie zapraszam do czytania wpisów związanych z kolejną serią - tym razem temat długo przeze mnie pomijany, czyli wzorce projektowe.
Mam nadzieję, że po ponad trzech latach jestem już wystarczająco przygotowany :)

SOLIDny kod cz. 6 - Dependency inversion principle

poodwracane?

Zacznijmy od definicji:

Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu. Jedne i drugie powinny być zależne od pewnych abstrakcji.

Niby proste, ale żeby usunąć wszelkie niejasności to pozwolę sobie na rozwinięcie.

SOLIDny kod cz. 5 - Interface segregation principle

segregacja interfejsów czyli co?

Czyli:

Klasa udostępnia tylko te interfejsy, które są niezbędne do zrealizowania konkretnej operacji. [link]

albo:

Klasy nie powinny być zmuszane do zależności od metod, których nie używają. [link]

no chyba, że tak:

Klasa powinna udostępniać drobnoziarniste interfejsy dostosowane do potrzeb jej klienta. Czyli, że klienci nie powinni mieć dostępu do metod których nie używają. [link]

I są to tylko niektóre z definicji, które udało mi się znaleźć w internecie po bardzo krótkich poszukiwaniach. I oczywiście pomimo tego, że brzmią odrobine inaczej, to sprowdzają się one do tego samego.

Dekorator - zmiany bez dziedziczenia

więc chodź, pomaluj mój świat

Jak obiecałem ostatnio pora zabrać się w końcu za wzorce. Pierwszym, nad którym się odrobinę poznęcamy będzie Dekorator.

Dekorator to wzorzec należący do rodziny wzorców strukturalnych i jego głównym zadaniem jest umożliwienie rozszerzenia funkcjonalności konkretnego obiektu poprzez "dodanie" do niej czegoś od siebie, rozwinięcie jego możliwość o to, co oferuje konkretny dekorator.
Zdaję sobie sprawę, że trochę enigmatycznie może to brzmieć, ale mam nadzieję, że po przeczytaniu całego wpisu, wszystko stanie się jasne i proste :)