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.
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 🙂
Top Kategorie
Jako programiści lubimy dyskutować nad tym, czy nasz kod wygląda dobrze. Zastanawiamy się, czy da radę go re-używać oraz zrozumieć. Niestety, nie podejmujemy zbyt wiele dyskusji na temat tego, czy aplikacje, które tworzymy mają odpowiedni performance. Zatem dziś jak podejrzewacie, będzie właśnie o performance.
Warstwa domeny w Domain Driven Design jest prawdziwą wisienką na torcie. Powinniśmy dbać o nią, aby zawsze była czysta. Dziś przedstawię Wam kilka heurystyk, których stosowanie spowoduje, że Wasza domena nabierze barw 🙂
Kiedyś, podczas sesji Event Stormingu, w której brałem udział kilka lat temu, co chwilę padało zdanie „A to wyłapie jakaś polityka”. Następnie naklejaliśmy fioletową karteczkę. Wtedy nie było dla mnie jasne, czym są polityki w kontekście Stormingu oraz DDD. Dzisiaj już to wiem i chcę tą wiedzą podzielić się z Wami 🙂
Podejście typu „rób tak zawsze i koniec” jest moim zdaniem słabe. Tym bardziej, jeżeli nie padają żadne argumenty. Bo jak pojawiają się argumenty, to jest również dyskusja. Tak jest w kwestii podejścia „klasa powinna być finalna by default”, a ja przychodzę z argumentami, dlaczego nie 🙂
Niestety, bardzo często, wybór narzędzia do testów jednostkowych sprowadza się do słów: „Znam PHPSpec, piszmy specki” lub „Wszyscy piszą w xUnit, więc korzystajmy z PHPUnit”. Uważam, że dobrze jest mieć porównanie między narzędziami, dlatego na przestrzeni kilku wpisów postaram się zbadać, w których sytuacjach lepiej jest skorzystać z PHPSpec, a kiedy lepiej wybrać PHPUnit.
Każdy programista, prędzej czy później, zaczyna pisać testy. W większości, wszyscy zaczynają od testów jednostkowych, choć zdarzają się również osoby, które przygodę z testami zaczynają od testów wysokiego poziomu, np. pisanych w behacie. Niestety zdarza się, że programiści pozostają przy tym, czego się nauczyli na początku, ignorując wachlarz zalet pełnego zakresu testowania. Dlatego od dziś, w kilku postach, poruszę temat testów deweloperskich.
Podejście typu „rób tak zawsze i koniec” jest moim zdaniem słabe. Tym bardziej, jeżeli nie padają żadne argumenty. Bo jak pojawiają się argumenty, to jest również dyskusja. Tak jest w kwestii podejścia „klasa powinna być finalna by default”, a ja przychodzę z argumentami, dlaczego nie 🙂
Kiedyś, podczas sesji Event Stormingu, w której brałem udział kilka lat temu, co chwilę padało zdanie „A to wyłapie jakaś polityka”. Następnie naklejaliśmy fioletową karteczkę. Wtedy nie było dla mnie jasne, czym są polityki w kontekście Stormingu oraz DDD. Dzisiaj już to wiem i chcę tą wiedzą podzielić się z Wami 🙂
Utrzymanie dobrego performance aplikacji jest prawdziwą sztuką. Jako developerzy najczęściej poświęcamy swoją uwagę na to, w jaki sposób piszemy kod. I to jest okej, chociaż na tym przyśpieszanie aplikacji się nie kończy. Stąd właśnie mam kilka porad związanych z dobrym performance, które niekoniecznie skupiają się na tym, jaki kod piszemy 🙂