Najlepszy styl pracy z kodem: TDD + Pair programming

Marzy mi się stworzenie idealnego środowiska pracy. Wpadłem na pomysł jak je osiągnąć, ale do tego potrzebuję kilku desek, aby zbudować customowe biurko.

Konfiguracja

Słyszę od wielu, że powinno się pracować w TDD, bo to jest najlepsze dla wytworzonego kodu, aby posiadał od razu testy (a nawet kiedy jeszcze sam się nie urodził).

Świetnie, ale bardzo mało ludzi je stosuje ^{[Potrzebne źródło]}.

Co jeśli Wam powiem, że jest to pewna bariera, taka fosa wokół zamku. Jeśli jednak ją się pokona osiągnie się coś fantastycznego (trzymając się tego przykładu z zamkiem - zdobędzie się skarb 💰).

Wyobrażam sobie, że na początku potrzebny jest spory nakład budżetowy oraz odpowiednia konfiguracja softwarowo-białkowa, ale jakie później zbierze się owoce takiej pracy, to mało która konfiguracja może z nią konkurować.

Czego potrzebujemy?

Aby zbudować idealne środowisko potrzebujemy 3 wyświetlaczy (w porywach do 5 - po 2 dla każdego developera).

• monitor wyświetlający kod z testami jednostkowymi (dla Developera A)
• monitor wyświetlający kod z implementacją (dla Developera B)
• monitor wyświetlający raport z testów, który automatycznie się uruchamiają, kiedy zmieni się implementacja albo testy

Przykład:

Role

Cała idea skupia się na tym, że:

• Developer A jest odpowiedzialny za zdefiniowanie test case–ów, które są przekazane przez np. biznes, albo przez kogoś innego
• Developer B jest odpowiedzialny za implementację logiki, tak aby pokryć wymagania zdefiniowane przez Developera A
• monitor na samej górze, wyświetla aktualny procent zaawansowania implementacji, tj. ile testów już przeszło, a ile jeszcze pozostało do implementacji.

Workflow

Jak widzę taki styl pracy:

1. Przychodzi do nas biznes (albo spotykamy się na planowaniu)
2. Developerzy notują co jest do zrobienia (albo czytają to, co biznes napisał w tickecie)

3. Developer A pisze pojedynczo oczekiwania biznesowe w katalogu z testami:

   • na początku end-to-end (najwyższego poziomu)
   • potem w integracyjnych (komunikacja między modułami)
   • kończy na testach jednostkowych (pojedyncze funkcje / klasy)

   konsultując się ciągle z Developer B

4. Developer B tworzy logikę biznesową, podpiera się mocno atrapami (najprawdopodobniej będą to stuby)
5. Zadanie można uznać za skończone, jeśli:
   • Developer A skończył swoją pracę, czyli zdefiniuje wszystkie test case-y jakie jemu (oraz biznesowi) mogły przyjść do głowy, oraz
   • monitor prezentujący aktualny raport z testów wyświetla informację, że wszystkie przypadki zostały przetestowane.

Opinia

Jak sądzisz, czy taki styl pracy jest idealny dla nas, developerów?

Chciałbym spróbować.

Zainteresowałem Ciebie takim stylem pracy? Odezwij się

Cya! 👋