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

Wydajność mojego zespołu zwiększyła się w ostatnich miesiącach kilkukrotnie. Oczywiście jest to powód do zadowolenia, ale generuje to również wiele code review, które wcześniej czy później trzeba przejrzeć. Co prawda, nie wszyscy muszą oglądać wszystko, ale tak czy inaczej, ich ilość ostatnimi czasy jest przytłaczająca. Zazwyczaj rano przy kawie przeglądam ich listę i po kolei, jeden po drugim, zamykam bądź oglądam, w zależności od tego, ile osób przede mną już miało przyjemność patrzyć na ten kod. Tak też zrobiłem ostatnio. Gorąca, czarna, parzona i aromatyczna kawa powoli cuciła mnie i przywracał do świata żywych, a ja w między czasie przedzierałem się przez kolejne linijki kodu. W pewnym momencie trafiłem na bardziej złożone zadanie i po ilości klas byłem w stanie stwierdzić, że zrozumienie wszystkiego będzie wymagało ode mnie trzeźwości umysłu i skupienia, o jakie ciężko we wczesnych godzinach porannych. Ale któż powiedział, że życie lekkie jest:) Łyk, już tylko ciepłego, napoju i do dzieła.Czytaj więcej »

łatwo powiedzieć

W najprostszej i najkrótszej postaci definicja drugiej zasady SOLID, to: elementy systemu powinny być otwarte na rozszerzenia, ale zamknięte na zmiany. Proste, jasne i przejrzyste, czyż nie? No dobra, może nie takie jasne i przejrzyste, ale przynajmniej proste. Łatwo zapamiętać:) Może przesadzam z tym, że nie jest ona (definicja) równie przejrzysta jak prosta, bo w większości przypadków programista jest w stanie wytłumaczyć o co chodzi - "O to, żeby łatwo było rozszerzać bez mieszania w kodzie". Problemy zaczynają się wtedy, gdy docieramy do projektowanie czy też tworzenia kodu, bo to, co prosto powiedzieć, już wcale takie banalne w realizacji nie jest. Jak umożliwić rozwój, który nie wymaga zmian? Czytaj więcej »

w czym rzecz

Jak już ostatnio pisałem, Single responsibility principle (SRP), czyli zasada jednej odpowiedzialności, mówi o tym, że klasa nie powinna mieć więcej niż jednego powodu do modyfikacji.Często spotykam się z tym, że programiści twierdzą, że takie myślenie prowadzi jedynie do niepotrzebnego rozbijania każdej klasy na kilka bądź więcej elementów składowych. Co za tym idzie? Potrzeby zarządzania wieloma klasami. A to wszystko tylko po to, żeby zrobić coś naprawdę prostego.Cóż, można na to spojrzeć w ten sposób. Jednak jest kilka ale...Czytaj więcej »

wstęp

Zdaję sobie sprawę, że o różnicach pomiędzy interfejsem, a klasą abstrakcyjną pisałem już wielokrotnie (m. in. "klasa, czy już interfejs" oraz "abstrakcja vs interfejs"), jednak nigdy nie pisałem o tych podstawowych. Opierając się na wielu rozmowach rekrutacyjnych, które do tej pory przeprowadziłem, zauważyłem, że te różnice nie są jednak tak powszechnie znane, jak przypuszczałem i może warto byłoby je wymienić oraz wytłumaczyć skąd się biorą. Dlatego też dzisiaj chciałbym nadrobić brak wpisu na ten temat:)Czytaj więcej »

co się odwlecze...

Już od dłuższego czasu przymierzałem się do przeczytania książki Martina Fowlera niestety nieustannie coś mnie od tego odciągała (zazwyczaj brak czasu lub inna literatura:). Na szczęście ostatnio udało mi się po nią sięgnąć, a dzisiaj zakończyłem jej lekturę i muszę przyznać, że... ale o tym za chwilę:)Czytaj więcej »

SOLIDnie, czyli jak?

Skoro podstawy programowania obiektowego mamy już za sobą (dla tych, którzy przegapili - spis treści jest tutaj), to pora zająć się jakimiś poważniejszymi tematami związanymi z OOP :) Na początek chciałbym rozszyfrować akronim SOLID.Co się za nim kryje? Zbiór pięciu podstawowych zasad dotyczących programowania obiektowego:

• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

Czytaj więcej »

ach ten pehape...

Jedyną rzeczą, której naprawdę nie mogę przeboleć w PHP, to fakt, że nie posiada on typowania. Oczywiście można "umówić się" z innymi programistami w zespole, że "typujemy" tzn. w komentarzach określamy typ przyjmowany i zwracany i się tego trzymamy, ale jest to jedynie obejście problemu, a nie jego rozwiązanie.Dobra, niestety świat nie jest idealny i musimy jakoś z tym żyć. W dodatku, jeżeli kod jest rzeczywiście obiektowy, to w większości przypadków typowania rzeczywiście można używać na tyle często, że zapomina się o problemie. Jednak tylko do czasu...Czytaj więcej »