Pracujemy w Test-Driven Development, stosujemy więc znany framework Red Green Refactor. Programista tworząc kod rzeczywiście najpierw zaczyna pracę od napisania failującego testu. Następnie implementuje funkcjonalność, którą ten test “zazielenia”. Na samym końcu ma miejsce refactoring.
Pisząc testy, w przeważającej większości przypadków stosujemy klasyczne podejście do testów (Tzw. szkoła Detroit). Jeśli chodzi o podejście mockistyczne (szkoła Londyńska) to stosujemy je bardzo rzadko, tam gdzie to podejście ma faktycznie sens.
Testy piszemy w standardzie jednej linijki na każdą z części “arrange”, “act” oraz “assert”. Wymaga to oczywiście również rafactoringu testów.
Nie pracujemy na branchach. Stosujemy podejście Trunk-Based Development. Wszystkie nasze commity wrzucamy na master i z reguły każdy commit kończy się deploymentem na produkcję.
Każdy programista pracujący w zespole jest w stanie w ten sposób wykonać w ciągu miesiąca ok. 50-100 deploymentów na produkcję.
Inne nazwy opisujące to samo podejście to Continuous Integration, Continuous Deployment, Continuous Delivery. Jest ono jednak mylące ponieważ najczęściej używa się ich w stosunku do narzędzi CI/CD, których można używać mimo, że stosuje się w swoim flow branche.
Praca przebiega płynnie i bezstresowo, ponieważ nie występują merge conflikty, a jeśli nawet występują to ich rozwiązanie zajmuje sekundy. Dzień kończy się z spokojną głową gotową na inne aktywności.
Całkowicie normalną i bezpieczną sytuacją jest wykonywanie deploymentów w piątki, a nawet jest to sytuacja pożądana.
O tym podejściu nasz founder, Konrad Otrębski, opowiadał m.in. na największej polskiej konferencji PHP PHPers Summit w 2019 roku (zobacz).
Pracujemy na bardzo małych iteracjach. Dzielimy duże stories na wiele małych. Nie korzystamy z frameworku Scrum, ponieważ dla takich zespołów jak nasze niewystarczający i spowalniający w połączeniu z pracą bez branchy i bardzo częstym deployowaniem kodu na produkcję,
W praktyce stosujemy proste Kanban boardy i agresywnie limitujemy przy tym Work In Progress. Nasi programiści w danej chwili mają “otwarte” tylko i wyłącznie jedno story.
Prosty Kanban Board z 3x kolumnami TODO, IN PROGRESS, DONE
Code review wykonujemy “na żywo” np. Podczas połączenia video prezentujemy ekran i komentujemy kod. Dzięki takiej praktyce oszczędzamy czas i unikamy długim dyskusji na GitHub lub Slack. Ponadto, w związku z zasadą limitowania WIP, code review ma absolutny priorytet nad nowymi zadaniami.
W ciągu 1-2h od skończenia story Twój kod jest na produkcji, masz zrobione code review, story jest zaakceptowane, a Ty zabierasz się za kolejne zadanie.
Nie zatrudniamy testerów/QA. Piszemy testy automatyczne (nazywane m.in. end-2-end/UI/acceptance) w narzędziach typu Selenium czy PlayWright.
Poszukujemy osób, które w swojej pracy potrafią wykorzystać zaawansowane praktyki tworzenia kodu lub są chętne i otwarte aby się ich nauczyć.
Duża część z nich jest niezbędna aby z sukcesem osiągać wyżej wspomniane wysoko wydaje flow 50-100 deploymentów na produkcję w miesiącu - gdzie oczywiście
Potrafimy przekonać naszych klientów w inwestycje w dług techniczny. Sprawny monitoring, skrypty deploymentowe, CD/CD pipeline, rozpoczynanie pracy od napisania testu są u nas podstawą i codziennością.
Konkretne praktyki, jakie stosujemy to m.in. Domain-Driven Design, Infrastructure as Code, Test-Driven Development, Trunk-Based Development oraz feature toggles, Refactoring, SOLID, KISS, YAGNI, DRY, Theory of Constraints, Clean Code, Extreme Programming, Fail Fast, a także szeroko pojętą automatyzację.
Praktykujemy również zasadę Fail Fast tzn. częste i agresywne stosowanie exceptionów i assercji stopujących execution procesu. Dzięki temu nasz kod posiada znikomą liczbę bugów.
Nasz founder Konrad Otrębski prezentował Fail Fast podczas kilku meetupów i konferencji. Zobacz nagranie z PHPers Gdańsk tutaj.
Stosowanie powyższych narzędzi i praktyk na co dzień, sprawia, że możemy uważać się za organizację, która swoją pracę dostarcza w duchu takich idei jak Agile, DevOps czy Continuous Delivery. Staramy się skracać tzw. feedback loop oraz minimalizować cycle time projektów, przy których pracujemy.