Wzorców projektowych jest bardzo dużo, nawet jeżeli jakoś je pogrupujemy. A pogrupowałem już we wcześniejszym wpisie, którego temat będę kontynuował tutaj. Zapraszam więc na drugą część wpisu o wzorcach projektowych przyjaznych zasadzie OCP 🙂
Jednym z dziedzictw świata programowania są wzorce projektowe. Jest to meta-język, którym mogą posługiwać się programiści niezależnie od tego, w jakiej technologii, czy języku piszą. Bardzo podobnie jest z zasadami SOLID. Dziś połączymy te dwie rzeczy w pierwszym, z dwuczęściowej serii, wpisie.
System zdarzeń jest jednym z fajniejszych wzorców projektowych. Nie dość, że jest on zgodny z SOLID (bo rozszerzamy), to dodatkowo jest on łatwo testowalny. Niestety, czasami możemy przeszarżować, zwłaszcza, jeżeli chodzi o nasłuchiwanie zdarzeń, które oferuje nam Doctrine 2. Poznajcie kilka wskazówek, dzięki którym (mam nadzieję) pozbędziecie się potencjalnych problemów w przyszłości.
Praca programisty to nie tylko programowanie. To również zorganizowana praca zespołowa, która (podobnie jak u mrówek czy pszczół) polega na tworzeniu mniejszych elementów, które w jakiś sposób trzeba złożyć w większą całość. Jedną z metodyk organizacji pracy na projekcie jest GitFlow, czyli bardzo popularny schemat „branchowania”, o którym dziś coś niecoś opowiem 🙂
Podczas tworzenia aplikacji biznesowych, nie sposób nie poruszyć tematu aktualizacji bazy danych – elementu, z którym spotykamy się w codziennej pracy. Niezależnie od typu środowiska, zawsze trafimy na temat migracji bazy danych. Na szczęście Doctrine posiada specjalnie do tego wyspecjalizowany mechanizm, którego najważniejsze elementy poruszymy w tym wpisie.
Doctrine, jako bardzo zaawansowane narzędzie, posiada bardzo dużo mechanizmów, które należałoby poznać zarówno od strony teoretycznej jak i w boju. Okazuje się, że niektóre z tych funkcjonalności – pomimo, że służą do podobnych celów – mogą się wzajemnie wykluczać. Niestety, niezbyt wiele osób wie, że właśnie tak jest z funkcjami Doctrine Schema oraz Migration. Dlatego właśnie powstał ten wpis.
Tworzenie aplikacji biznesowych z grubsza polega na definiowaniu procesów, które mają za zadanie w określony sposób przetwarzać zapisane w systemie dane. Część z tych danych posiada swój stan (jeden z wielu), który zmienia sposób interpretacji zawartych wewnątrz informacji. Tematem dzisiejszego wpisu jest więc Maszyna Stanów – wzorzec, który upraszcza dużo w poruszonej wyżej kwestii.
We wpisie o Lazy Loadingu wspomniałem, aby pobierać wszystko, czego potrzebujemy, na raz. Słowem-kluczem tutaj są słowa „czego potrzebujemy”. Z perspektywy działania aplikacji wydaje nam się, że do konkretnych operacji potrzebujemy pełnego zestawu danych. O tym, że czasami można taniej – jest dzisiejszy wpis.
Najsłabszym ogniwem większości aplikacji jest baza danych. Praca na domyślnej konfiguracji Doctrine tylko pogłębia ten problem. Znajomość podstawowych procesów optymalizacji oraz zasady ich działania powinny być wiedzą ogólnodostępną. Dlatego dziś poruszymy klasyka, jakim jest Doctrine Eager fetch mode, czy jak kto woli – Doctrine Eager loading.
Większość świeżych programistów, którzy pytają tych starszych o porady, słyszą: „Ucz się Symfony, Doctrine i pisz testy”. A młodzi przyjmują to za świętość i uczą się. Znają podstawowe pojęcia, po czym wchodzą na projekt, napiszą endpoint dla dużego zestawu danych i… całość wykonuje się w 13 sekund. Ta historia, choć nieco przeze mnie ufarbowana, wydarzyła się całkiem niedawno. I z chęcią podzielę się z Wami kilkoma szczegółami oraz wnioskami z tej sprawy 🙂