czwartek, 11 grudnia 2014

JDD2014: Code review - jak więcej zyskać niż stracić?

Jakiś czas temu pisałem o moim planowanym występie na JDD 2014. Wczoraj pojawił się film na youtubie z moją prezentacją, do którego obejrzenia gorąco Was namawiam. I liczę na jakiś feedback z Waszej strony, abym wiedział co poprawić na przyszłość :)



Osobiście jestem zadowolony zarówno z wystąpienia jak i doświadczenia, które dzięki niemu zdobyłem. Niemniej jednak, jestem ciekaw Waszych opinii.

Otrzymałem również maila od organizatorów, że na 98 oddanych na prezentację głosów, aż 83 to były głosy pozytywne. Za wszystkie dziękuję i mam nadzieję, że następnym razem będzie jeszcze lepiej :)

Jeżeli będziecie mieli trochę czasu i ochoty to zapraszam również na kanał PROIDEAconferences, na którym są wszystkie prezentacje z tegorocznego JDD, oraz wiele innych :)

wtorek, 25 listopada 2014

Diagram prawdę Ci powie

porozmawiajmy o diagramach

Zdaję sobie sprawę, że pewnie wielu z Was odrzuca na samą myśl o UML-ach, ale chcąc nie chcąc, na pewnym etapie Waszej kariery się z nimi spotkacie i możliwe, że nawet sami będziecie musieli je wykorzystać do pracy twórczej.

Dlaczego tylu programistów czuje awersję do diagramów? Cóż, przypuszczam, że wynika to z pewnej niechęci do tego, czego nie znamy, w tym konkretnym przypadku – do języka, który jest nam obcy. Bo tym właśnie jest UML, językiem, który nie wszyscy rozumiemy, którym nie wszyscy mówimy. Dzisiaj jednak nie o tym.

wtorek, 4 listopada 2014

Strach ma wielkie oczy...

Odwaga to podobno nie brak odczuwania strachu, a umiejętność jego pokonywania. I właśnie tą cechą powinien kierować się każdy, kto ma w planach napisanie jakiegoś testu. Nie ważne czy jest to test jednostkowy, czy integracyjny, czy jeszcze jakiś inny jego rodzaj - gdy zabieramy się za testowanie to właśnie w stronę tego, co nas przeraża powinniśmy kierować swój wzrok, w stronę tego, co spędza sen z powiek kolegom z naszego zespoł.

środa, 8 października 2014

JDD 2014

W końcu zebrałem się w sobie i udaję się na konferencję w roli speakera. Co prawda z tegorocznym PHPCon'em nie wyszło, ale już niedługo, bo w przyszłym tygodniu, będziecie mieli okazję posłuchać mnie na JDD 2014. Będę mówił o Code Review, o tym co zrobić, żeby wycisnąć z niego wszystko, co najlepsze :)

Wiem, że trochę późno, ale mimo to serdecznie zapraszam. Może z niektórymi z Was będę miał okazję w końcu porozmawiać :)

Tak więc, jeżeli się jeszcze nie zdecydowaliście, a chodziło Wam to po głowie, to nie czekajcie tylko się zapisujcie i... do zobaczenia.

piątek, 3 października 2014

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 :)

czwartek, 21 sierpnia 2014

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.

niedziela, 20 lipca 2014

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...

czwartek, 3 lipca 2014

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.

piątek, 30 maja 2014

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 :)

poniedziałek, 5 maja 2014

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 :)

piątek, 11 kwietnia 2014

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 :)

środa, 26 marca 2014

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.

czwartek, 13 marca 2014

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.

sobota, 8 marca 2014

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 :)

poniedziałek, 24 lutego 2014

Ach te wzorce...

kolejny rok czas zacząć...

Zima już nas zostawiła, wszelkie śniegi, które na chwilę do nas zawitały również już się potopiły tak więc najwyższa pora rozruszać stawy i sprawdzić czy palce potrafią jeszcze pisać w takt pojawiających się w głowie słów. A że powrót do formy po tak długiej przerwie do przyjemnych nie należy, a im dużej się go odwleka, tym jest trudniejszy, to aby sobie to wszystko uprzyjemnić i ułatwić postanowiłem zacząć nowy rok od nowej serii wpisów. Tym razem pod młotek idzie temat długo przeze mnie pomijany - Wzorce Projektowe.

Na wstępie jednak zaznaczę, że w przeciwieństwie do serii o tym jak pisać obiektowo oraz o SOLID (tutaj pragnę nadmienić, że ostatnie dwa wpisy pojawią się w niedługim czasie) będzie to dość luźna seria i choć plany na kilka najbliższych wpisów już mam, to jestem otwarty na propozycje i jeżeli w zakamarkach Waszych głów czai się wzorzec, który nie daje Wam spokoju, to piszcie w komentarzach, a ja postaram się co nieco rozjaśnić (o ile oczywiście będę w stanie :).
A jeżeli brakuje Wam pomysłów to zawsze możecie ponownie sięgnąć po klasykę i zastanowić się czy nie ma tam niczego, co wymagałoby wyjaśnienia :)

Chcąc nie chcąc, na wstępie, czyli dzisiaj, musi być trochę, tak przez wszystkich kochanej, suchej teorii, czyli słów kilka o tym, czym wzorzec jest, po co i dlaczego je stosować, co daje ich znajomość oraz jak je dzielimy.