Jak pracujemy w P3 Doweks?

Nasz sposób pracy daje bardzo dużo satysfakcji z tego co robimy ponieważ efekty naszych starań są dostarczane niemal natychmiast. Masz zastrzeżenia? Zapraszamy do pytań na pierwszej rozmowie i komentowania nas na LinkedIn!

Trunk-Based Development czyli brak branchy

Nie pracujemy na branchach, robimy Trunk-Based Development. Wszystkie nasze commity wrzucamy na master i z reguły każdy commit kończy się deploymentem na produkcję.

  • 20-50 deploymentów/msc

    Każdy programista w zespole może w ten sposób bez problemu wykonać w ciągu miesiąca min. 20-50 deploymentów na produkcję.

  • Trunk-Based vs CI/CD

    Trunk-Based to to samo co Continuous Integration, Continuous Deployment, Continuous Delivery. Te nazwy są jednak mylące ponieważ najczęściej używa się ich w stosunku do narzędzi CI/CD - a te z kolei nie wymagają przecież pracy bez branchy.

  • Energia po pracy

    Praca przebiega płynnie i bezstresowo, ponieważ nie występują merge conflicts, 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.

  • Satysfakcja

    Taki sposób pracy daje też o wiele więcej satysfakcji z tego co robimy ponieważ efekty naszych starań są dostarczone do użytkowników czy biznesu niemal natychmiast.

  • Piątek 17:00

    Całkowicie normalną i bezpieczną sytuacją jest wykonywanie deploymentów w piątki, a nawet jest to sytuacja pożądana(!).

Continuous Integration - jak dostarczać więcej i szybciej bez branchy i GitFlow! [Konferencja w Poznaniu]

Zobacz nagranie PHPers Summit (największa polska konferencja PHP):

(Prezentacja language-agnostic)

Test-Driven Development

  • Red Green Refactor

    Tworząc kod rzeczywiście zaczynamy pracę od napisania failującego testu (red). Następnie implementujemy funkcjonalność, którą ten test “zazielenia” (green). Na samym końcu ma miejsce refactoring.

  • Szkoła Detroit

    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 "jednolinijkowe"

Testy piszemy w standardzie jednej linijki na każdą z części arrange, act oraz assert.

Aby doprowadzić kod do tego standardu często wymaga to refactoringu nie tylko testów ale też kodu produkcyjnego. Natomiast niemal w każdym przypadku gwarantuje to dobrą jakość kodu: czytelność, dobrą organizację, odpowiednie abstrakcje itd.

Fail Fast czyli rzucanie exceptionami wszędzie

Nieintuicyjny ale skuteczny sposób na brak bugów.

  • Exceptions

    Praktykujemy zasadę Fail Fast tzn. częste i agresywne stosowanie exceptionów i asercji stopujących execution procesu.

  • ~ 0 bugów

    Fail Fast dosłownie dziesiątkuje liczbę bugów w naszym kodzie do liczb bliskich 0. Z tego powodu jest to jeden z fundamentów naszego podejścia do kodu.

Fail Fast! Zacznij pisać kod, który nie posiada bugów! [Meetup w Gdańsku]

Fail Fast prezentowaliśmy podczas kilku meetupów i konferencji. Zobacz nagranie z Gdańska tutaj lub poniżej:

(Prezentacja language-agnostic)

Jakość kodu i umiejętności

Poszukujemy osób, które potrafią wykorzystać dobre praktyki tworzenia kodu lub są chętne i otwarte aby się ich nauczyć.

  • Dbamy o standardy

    Potrafimy przekonać naszych klientów w inwestycje w dług techniczny. Sprawny monitoring, skrypty deploymentowe, CD/CD pipeline, zaczynanie od napisania testu są u nas podstawą i codziennością.

  • Inne praktyki

    Stosujemy również m.in. Domain-Driven Design, Infrastructure as Code, feature toggles, Extreme Programming, DevOps/Theory of Constraints, Clean Code, SOLID, KISS, YAGNI, a także szeroko pojętą automatyzację.

Workflow: flow tak, Scrum nie

Pracujemy na bardzo małych iteracjach. Dzielimy duże stories na wiele małych. W środowisku gdzie pracuje się bez branchy i bardzo często deploy'uje kod na produkcję Scrum nie wnosi po prostu żadnej wartości.

  • WIP ~ 1

    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.

  • Kanban

    Nasze boardy posiadają 5 kolumn: MAYBE, TO DO, IN PROGRESS, DONE, ACCEPTED z czego pierwsza i ostatnia kolumna to tylko szybkie "bramki" dla managera i klienta.

  • Code review f2f

    Code review wykonujemy “na żywo” np. podczas połączenia wideo prezentujemy ekran i rozmawiamy o kodzie. Dzięki temu oszczędzamy czas i energię - unikamy długich dyskusji na GitHub czy Slack. Ponadto, w związku z zasadą limitowania WIP, code review ma priorytet nad nowymi zadaniami.

  • DONE DONE DONE

    W ciągu 1-2h od skończenia story Twój kod jest na produkcji, masz zrobione code review, story jest zaakceptowane przez "biznes", a Ty zabierasz się za kolejne zadanie.

  • Testy e2e/UI

    Nie zatrudniamy testerów/QA. Piszemy również testy angażujące UI (aka e2e, acceptance) w PlayWright (narzędzie podobne do Selenium).

A gdzie Agile?

To właśnie w/w konkretne narzędzia i praktyki stosowane na co dzień, sprawiają, że możemy uważać się za organizację, która swoją pracę dostarcza w duchu takich idei jak Agile, DevOps, Continuous Delivery czy Extreme Programming.

Dzięki tym praktykom skutecznie skracamy tzw. feedback loop oraz minimalizujemy cycle time projektów.

Pomóż zespołowi dowozić więcej i szybciej! Teoria Ograniczeń w praktyce [Nerd Management]

Zobacz wywiad z Konradem Otrębskim na kanale Nerd Management:

Dowiedz się więcej

Czy muszę to wszystko umieć?

Co jest wymagane aby dołączyć?

Newsletter

Praktyczna wiedza o budowie software szybko i bez bugów. Niuanse, które pomija reszta branży, a które będą stanowić przewagę konkurencyjną Twojego biznesu.

Dbamy o politykę prywatności