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

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.

Niech Wam testy przejdą :)

Ostatnio trochę Was zaniedbałem za co serdecznie przepraszam i obiecuję, że w nadchodzącym roku postaram się nadrobić dwumiesięczny brak aktywności na blogu :) To tyle w kwestii usprawiedliwiania się, w końcu kończy się rok i nie ma co płakać nad tym, co nie wyszło w stu procentach tak jak byśmy chcieli. Natomiast tym, co wyszło dobrze albo nawet lepiej niż zakładaliśmy również trzeba przestać się zachwycać i zrobić miejsca na kolejne sukcesy :)

Dzisiaj krótko i w klimacie TDD - Niech za rok, po odpaleniu, poniższe testy Wam przejdą :)

SOLIDny kod cz. 4 - Liskov substitution principle

zacznijmy od podstaw

Zasada podstawienia Liskov brzmi:

Funkcje które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów.

Sprowadza się to do tego, że w każdym miejscu gdzie wykorzystujemy klasę bazową (rozszerzaną) lub interfejs możemy wykorzystać każdą klasę potomną i nie wpłynie to na zmianę zachowania czy też wynik działania, nie wpłynie negatywnie na działania aplikacji.

Prototype i this - wiem, że nic nie wiedziałem

Kolejna prezentacja stworzona przez Piotrka Repetowskiego i Mirka Filipa. Tym razem na temat działania prototype i this w JavaScripcie. Obejrzyjcie, bo warto:)

Człowiek nie zdaje sobie sprawy o ilu rzeczach nie wie i ile kryje się "pod maską" dopóki ktoś mu tego w jasny i klarowny sposób nie przedstawi:)

Nie mam wątpliwości, że dzięki tej prezentacji dowiecie się "kilku" interesujących (i możliwe, że przydatnych) rzeczy:)

Prezentacja do obejrzenia tutaj.