Dobre praktyki programowania w CakePHP #3

Tym razem krótka notka…

Zauważyłem, że czasem gdy stosujemy wzorzec MVC, zapominamy* że istnieje coś takiego jak projektowanie i programowanie zorientowane obiektowo.
(*)zakładając, że wcześniej wiedzieliśmy, że coś takiego istnieje – to nie jest takie oczywiste.

Chodzi mi o to, że jak piszesz class, private i extends to jeszcze za mało, żeby powiedzieć iż Twój kod jest obiektowy. Na razie możesz powiedzieć, że masz klasy i metody. Ale dalej możesz mieć bajzel jak bez nich.

Dlatego powstają takie niespodzianki jak metoda getAllComments($postId) w kontrolerze Posts, bo akurat wyświetlając dany post potrzebujesz wyświetlić komentarze. Chwała i tak się należy, bo ktoś umieścił ten fragment w osobnej metodzie. Jednak to jeszcze za mało, żeby nie musieć się kodu wstydzić.

Jeśli przypomnisz sobie podstawy programowania obiektowego ze studiów, czy książki o C++ może taki przykład wyda Ci się znajomy:
- Auto jest obiektem: posiada atrybuty szybkość_maksymalna, ilość_pasażerów oraz metody jedź(), ruszaj(), zatrzymaj_się(), włącz_klimę() ;)
To jest przykład w którym wyjaśnia się czym są obiekty, jak ich używać. Czasem brakuje jednak informacji – prostej odpowiedzi na pytanie:
“Dlaczego klasa Auto nie posiada metody wypij_kawę_w_samochodzie()?”. To już zagadnienie z OODesign.

W przypadku samochodu jest to oczywiste, ale łatwo zapomnieć o tym, kiedy nasze klasy są mniej “dotykalne” i sami je projektujemy, a nie “mapujemy” ze świata rzeczywistego. Dlatego skoro wiemy, że metoda wypij_kawę_w_samochodzie() powinna należeć do klasy Człowiek – to dlaczego każemy klasie Posts znajdować komentarze?

Dochodzę już do sedna: przy projektowaniu aplikacji w CakePHP (i w każdym innym frameworku opartym na MVC lub nie) nie możesz olewać zasad projektowania obiektowego. Nie możesz ignorować problemu przynależenia metod do odpowiednich klas. Dlaczego?

Przykład:
Gdy w kilka osób rozwijacie aplikację i nie mieliście 10tysięcy na wynajęcie architekta, który zaprojektowałby wszystkie klasy i ich metody, to prawdopodobnie rozwijacie architekturę stopniowo. W przypływie twórczości jeden z kolegów umieścił metodę getAllComments() w kontrolerze Posts. Następnie Ty na stronie główniej musisz umieścić ostatnie komentarz. Rzucasz okiem na klasę Comments i widzisz, że brakuje tam metody getAll() (Comments w domyśle) więc ją implementujesz.
W wyniku łamana jest reguła DRY, a co za tym idzie powstaje redundancja w kodzie. Zmniejsza się prostota projektu i rośnie dług techniczny.

Może się wydawać, że to błahy przykład i to jest dobre wrażenie. Jednak jeśli nie myślisz o tym problemie takich kwiatków w projekcie prędzej czy później będziesz miał całą łączkę. Po jakimś czasie łączka zarasta tak bardzo, że nie sposób tam wejść z maczetą, więc zarzucasz projekt, bo nie nadaje się on już do konserwacji.

Zatem zasada numer 3:
Poznaj zasady projektowania obiektowego, i nie wypinaj się na nie podczas programowania

Jaką książkę warto przeczytać, aby poznać Agile?

Z racji mojej magisterki i zainteresowań trochę książek o tej tematyce mam za sobą (na szczęście “za” ;)). Dlatego chętnie podzielę się swoimi doświadczeniami polecając trzy pozycje:

  1. Agile Software Development. Gra zespołowa. Alistair Cockburn
    Agile Software Development. Alistair Cockburn

    Agile Software Development. Dużo teorii i dużo informacji



    Bardzo dobra pozycja, choć dość trudna w odbiorze. Charakteryzuje się dość wysokim poziomem abstrakcji. Ale dzięki niej można zrozumieć dlaczego agile działa, a nawet kiedy nie działa i dlaczego. Autor jest też twórcą rodziny metodyk Crystal i z tej książki dowiesz się o nich co nieco. Jeśli na temat stosowania Agile chcesz poznać wszystkie sekrety i mechanizmy stojące za jego siłą – to pozycja dla Ciebie. Jeśli nie jesteś gotowy na teoretyczną przeprawę – rzuć okiem na pozycje poniżej.

  2. Agile Development. Filozofia programowania zwinnego. James Shore, Shane Warden
    Agile Development. Shore, Warden

    Agile Development. Równowaga między teorią a praktyką stosowania XP


    To nieco lżejsza pozycja, bardziej traktująca o tym jak używać (w tym przypadku XP), a nie jak działa. Z tej książki poznasz dokładnie wszystkie elementy XP, łącznie z tymi najbardziej subtelnymi. Dowiesz się dlaczego programowanie w parach jest równie skuteczne, co dziwaczne (na pierwszy rzut oka). Jeśli jesteś szefem programistów – zrozumiesz dokładniej co programiści robią podczas pracy. Dowiesz się, że jeśli nie klepią w klawiaturę, to jeszcze nie oznacza, że nie pracują. Pozycja obowiązkowa dla tych, którzy chcą z powodzeniem stosować XP. Dla osiągnięcia mistrzostwa prawdopodobnie po pół roku używania XP warto by do niej wrócić.
  3. Head First Software development. Dan Pilone, Russ Miles
    Head First Software Development. Pilone, Miles

    Head First Software Development. Zestaw praktyk w lekkiej i przystępnej formie


    Najlżejsza pozycja w zestawienia, jednak również wartościowa. Nie przedstawia z sobą żadnej konkretnej metodyki. Choć może raczej nie przedstawia żadnej nazwanej metodyki. Jest to zbiór prostych praktyk, które usprawnią działanie Twojego zespołu. Przykłady zamieszczone są w języku Java, ale pozycja przydatna nawet dla tych co Javy nie znają (jak ja, kiedy zaczynałem tą książkę czytać). Wiele ćwiczeń, pytań i wszystkiego, co sprawi, że nawet jeśli zdiagnozowano u Ciebie ADHD – wciągnie Cię i niewielkim wysiłkiem poznasz podstawy zwinnego wytwarzania oprogramowania.
  4. Miłej lektury.

    Ps. jeśli sam(a) chcesz mi coś polecić – wrzuć to koniecznie do komentarza – nie mogę się doczekać.

Refactoring pracy magisterskiej

Sobota (wczoraj)

http://helion.pl/view/4113g/agilsd.htm

To było jak olśnienie. Okazuje się, że refactoring to nie jest coś co tylko programiści mogą robić. Oto jak było.

Od miesiąca nie przybyło w mojej pracy magisterskiej więcej niż 2 strony. Nie mogłem się zabrać. Jak się zabierałem – szybko kończyły mi się pomysły, nie miałem ochoty więcej rozwijać wątków. Miałem wrażenie, że nic nowego tam nie dodam. Aż wczoraj wracając z wykładu przedmiotu “Koncepcje zarządzania” (o Lean management, banchmarkingu, outsourcingu itp. – inspirujące tematy) pomyślałem, że trzeba coś z tym zrobić.

Miesiącami już czytam o zwinnym wytwarzaniu oprogramowania. Niedawno w książce “Agile Software Development. Gra zespołowa” doszedłem do miejsca, w którym autor, Alistair Cockburn, opisał jak wykorzystał podejście zwinne przy rozbudowie domu (!). Wracając ze wspomnianego wykładu pomyślałem- skoro piszę pracę o zwinnym wytwarzaniu (oprogramowania), to może napiszę ją w sposób zwinny?

Po pierwsze postanowiłem znokautować swój pierwszy problem: nie wiedziałem na jakim etapie jestem. Brakowało mi informacji mimo, że mój zespół składał się tylko ze mnie – potrzebowałem radiatora informacji mimo, że jedynie ja miałbym z niego korzystać. Kupiłem korkową tablicę (miałem ochotę na “suchościeralną”, ale a/ była sobota i jeden sklep papierniczy był otwarty w okolicy b/ to wersja ekonomiczna: 60x40cm ok.20zł). Po powrocie do domu, przy pomocy dratwy przymocowałem ją do regału nad monitorem. Jest “Wystarczająco stabilna”

Miałem już radiator, teraz pora zacząć od podstaw: ustalić misję, cel projektu. Na niedużej kartce (takiej do notowania) napisałem mazakiem “Cel pracy”
i przykleiłem do niej 3 karteczki z powodami dla których w ogóle się tym zajmuję, zamiast na przykład wspinać się po górach. Po chwili uznałem, że warto ustalić im ważność. Dopisałem w nawiasie “wysokość ma znaczenie” i narysowałem podziałkę ;). Poniżej wrzucę efekty, jak tylko będę miał w rękach aparat.

Po drugie potrzebowałem “opowieści”, głównie po to, aby móc stosować “energiczną pracę”. Znam siebie na tyle, że wiem iż kiedy mam niepustą kolejkę zadań do wykonania – wtedy pracuję wydajniej. Zawsze mogę sięgnąć po następne zadanie – nie tracę czasu na zastanawianie się “co teraz?”. Na tablicy pojawiły się karteczki z nazwami danych obszarów: “Do zrobienia”, “W trakcie”, “Zrobione” :)

Postanowiłem postawić sobie krótkie zadanie do wykonania, aby szybko otrzymać nagrodę w postaci jego wypełnienia. Cały czas tytuł mojej pracy nie był ostateczny. Choć należałoby powiedzieć raczej, że był bardzo wstępny. Źle się z tym czułem, bo też mi się nie podobał, trącił trywialnością. Brzmiał “Możliwość zastosowania Zwinnej metodyki budowania aplikacji internetowych w firmie X”. Nawet gdyby zmiana tytułu miała polegać na zmianie błędu “zwinnej metodyki” na “zwinnych metodyk” – to był sukces, którego potrzebowałem.
Jednak podczas wypełniania karteczki z opowieścią, w której chciałem opisać mniej więcej co jest do zrobienia pojawił się pomysł i zanotowałem:

Może warto zmienić na “Nowoczesne metodyki wytważania wytwarzania oprogramowania; Agile; możliwość zastosowania w mikroprzedsiębiorstwach na podstawie firmy X”

Potem dokleiłem karteczkę “elasyczne, zwinne zamiast *nowoczesne*” i drugą “drugi temat pozwala skupić się na Agile zamiast na firmie”.

Efekty mi się podobały. Pomyślałem, że ta zmiana powinna zostać skonsultowana z moim promotorem. Zmniejszyłem nieco obszar “Zrobione”, który nie jest istotny pod względem informacyjnym – rosnący tam pęk zadań ma sprawiać, że będę się czuł pracowity :D; dodałem obszar “Skonsultować z promotorem” i tam wbiłem zadanie z tytułem.

Przyszedł czas na zadanie numer dwa. Jakiś czas temu M (nie wiem, czy pozwoli ujawnić swoje imię), kolega z pracy, zagaił mnie o magisterkę. Sam jest prawie rok po obronie. W dyskusji wyjawił, że gdy już miał spis treści – bardzo łatwo mu się pisało, gdyż po prostu pisał o tym o czym dany podrozdział miał traktować. Ja miałem odczucie, że mój spis treści jest zabałaganiony. Dlatego zadanie numer 2 brzmiało: “Uporządkować spis treści”.

Spis treści jest krajobrazem mojej pracy, dlatego go wydrukowałem, aby móc nad nim kontemplować. Wyglądał mniej więcej tak:

    Wstęp

  1. Zapotrzebowanie na metodyki
  2. Ogólnie o metodykach
  3. Przykłady metodyk zwinnych
  4. Typowe problemy w firmie X
  5. Metodyki zwinne (Agile)
  6. Konfrontacja teorii z rzeczywistością

Po pierwsze postanowiłem połączyć rozdział 2 z 3 – w końcu były niemal o tym samym. A treść zawarta w rozdziale 2 sprawiała, że nie miałem o czym pisać w rozdziale 3. To samo tyczyło się rozdziałów 4 i 6 – nabazgrałem między nimi linię opatrzoną opisem “połączyć”.
Rzuciłem okiem na nowy pomysł tytułu, który mi się spodobał bardziej. Pomyślałem, że fajnie przesunął ciężar pracy z implementacji metodyki w firmie X, na opisanie metodyk zwinnych. Pomyślałem, że spis powinien oddawać kolejność zaproponowaną w tytule, tym bardziej, że tytuł oddawał to o czym chciałem pisać. Nabazgrałem kilka strzałem z przesunięciem rozdziału 5 na przedostatnią pozycję. Teraz spis miał sens – drzewa były “zielonym do góry;)”. Policzyłem jeszcze ile będzie “nowych” rozdziałów, żeby ich nie było za mało. Z 8 liczba spadła do 6. Projekt uległ uproszczeniu, stał się bardziej przejrzysty.

Zatem zabrałem się za przenoszenie akapitów w pracy w taki sposób, aby wygenerowany spis treści był taki jak chciałem. W trakcie tych czynności pomyślałem, że przeprowadzam właśnie refactoring mojej pracy magisterskiej. Ucieszyłem się i z tej radości napisałem “refactoring :)” na przylepnej, żółtej karteczce i ustawiłem sobie opis na skype “refactoring pracy magisterskiej”. Taka była moja radość.

Gdy skończyłem – wpiąłem zadanie w miejsce “Skosultować z promotorem”; wygenerowałem dwa pdfy ze starym i nowym spisem treści i wysłałem maila do doktora B, z nowym pomysłem tytułu, uzasadnieniem i spisami treści.

W międzyczasie pojawił się pomysł na kolejne zadanie. Otóż czytając książki (źródła ;)) nauczony doświadczeniem – sporo bazgrałem, zaznaczałem ciekawe fragmenty itd. Gdybym tego nie zrobił – straciłbym przemyślenia, które pojawiały się podczas czytania (często w krakowskich tramwajach). Nie miałbym też ochoty drugi raz brnąć przez lekturę (nie chodzi o to, że nieciekawą – ale mam znam kilka większych przyjemności niż czytanie dwa razy tej samej książki, na przykład przeczytanie dwóch książek raz :D).

Teraz miałem 6 książek: 2 przeczytane w całości (w tym “Marsz ku klęsce” Yourdona), jedną przeczytaną tak daleko jak wydało mi się konieczne, 2 w trakcie czytania oraz jedną ledwie liźniętą. Łącznie mają już w sobie kilka dobrych gram grafitu ołówków z ikei (mały czasem może więcej). Problem polegał na uporządkowaniu tej wiedzy. Trzecie zadanie “Uporządkowanie źródeł” zostało wbite w strefę “do zrobienia”. Pojawiło się na niej 6 karteczek – jedna dla każdego tytułu.

W międzyczasie moja ukochana wróciła z zajęć, więc praca była tego dnia skończona. Całe szczęście – nie przeszkadza jej spora tablica korkowa zasłaniająca pół regału :D

Niedziela.

Zabrałem pierwszą i wkleiłem w miejsce “W trakcie”. Przeglądałem wypatrując zakreśleń, gdy je namierzałem – opisywałem o czym jest i wklejałem zakładkę. Mniej więcej w połowie przyszedł czas na przerwę: picie zimnej kawy, głośne słuchanie muzyki, telefon do przyjaciela (serio).

Teraz karteczka “Cockburn” jest skreślona (znaczy skończona) i wróciła na kartkę opowieści. Zabrało mi to nieco ponad 3 godziny. Jednak na pierwszy ogień postanowiłem wziąć zadania trudniejsze, żeby po dwóch największych skarbnicach grafitu mimo zmęczenia móc na luzie dokończyć pracę. “W trakcie” jest teraz Shore, ale zanim zacznę – miałem ochotę napisać ten post.

Teraz wracam do porządkowania źródeł. Gdy w tej sprawie coś się pojawi jeszcze ciekawego, na pewno o tym napiszę.