Jak osiągnąć i utrzymać przepływ podczas programowania w parach?

Flow to koncepcja wprowadzona przez Mihaly Csikszentmihalyi; w skrócie oznacza wejście w „strefę”. Czujesz się zanurzony w swoim zadaniu, skoncentrowany; zadanie może być trudne, ale jednocześnie trudne. Kiedy ludzie osiągają przepływ, ich produktywność wzrasta. Programowanie wymaga dużej koncentracji umysłowej, ponieważ często musimy żonglować kilkoma rzeczami w naszych umysłach. Wielu lubi pracować w cichym otoczeniu, w którym mogą skupić całą swoją uwagę na zadaniu. Jeśli zostaną przerwane, powrót do przepływu może potrwać kilka minut lub nawet godzin.

Rozumiem, że w zwinnym programowaniu i ekstremalnym programowaniu jest praktyka zwana programowaniem par. Oznacza to, że umieścisz cały zespół programistów w jednym pokoju, aby komunikacja była płynna. Piszesz kod ze swoją parą, ponieważ w ten sposób otrzymujesz natychmiastowe recenzje kodu i mniej błędów.

Zawsze miałem problemy z osiągnięciem przepływu podczas programowania par z powodu ciągłych zakłóceń. Zastanawiam się głęboko nad problemem, a potem nagle ktoś zadaje mi pytanie od innej pary. Mój tok myślenia został utracony.

Jak osiągnąć i utrzymać przepływ podczas programowania w parach?

Edycja: Oświadczenie - w ten sposób definiuję „strefę”: A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

Staram się unikać tego stanu, ponieważ chociaż mogę tworzyć poprawny kod w strefie, ja i inni programiści będą mieli trudności z jego zrozumieniem. Krótko mówiąc: odczytanie kodu, który został napisany w strefie, może często wymagać od czytelnika przebywania w strefie. To ograniczenie jest moim problemem.

Jest piękny rozdział na temat Czystego kodera, w którym wujek Bob przekonująco wyjaśnia, dlaczego „wejście w strefę” jest złym pomysłem.

Oto prawdopodobnie lepsza alternatywa niż „wejście w strefę”: pomyśl prosto i rozważ spokojnie i profesjonalnie, co robisz. Porozumieć się. Podziel się przemyśleniami ze swoim partnerem (partnerami). Zidentyfikuj prawdziwe problemy. Omów możliwe rozwiązania. Możesz nie czuć się nadmiernie skoncentrowany, ale prawdopodobnie podejmujesz dobre decyzje i przystępne projekty.

Jeśli ty i twój partner możecie porozmawiać o tym problemie bez obawy, że jesteście bardzo skoncentrowani, istnieje prawdopodobieństwo, że problem został sprowadzony do jego prostszej natury. To sugeruje, że będziesz w stanie to zrozumieć, kiedy tylko zajdzie taka potrzeba.

Z drugiej strony ... Jeśli potrzebujesz tylko trochę czasu, aby wyprostować głowę (wszyscy czasem to robimy), po prostu weź to. Zbierz myśli. Najpierw rozwiąż problem.

Chodzi o to, że jeśli to zrobisz - nie marnuj tego czasu na pisanie kodu produkcyjnego. Zamiast tego baw się z przykładowym kodem i prototypami. Spróbuj zrozumieć problem, nie zastanawiając się jeszcze nad rozwiązaniami. Kiedy wszystko zrozumiesz i spisasz, przedyskutuj to ze swoim zespołem i partnerem, a nawet gumową kaczką na biurku. Jeśli nadal nie możesz go wypowiedzieć lub nie potrafią tego zrozumieć, dopracuj swoje pomysły. Kiedy już to wszystko przybędziesz - zintegruj cały ten myśl i przykładowy kod w prawdziwe, działające rozwiązanie.

Programowanie w parach wymaga czasami okresów izolacji od partnera.

Przykład

Pracujesz razem nad konkretną klasą i zdajesz sobie sprawę, że musisz napisać metodę, która wymaga głębokiej refleksji nad złożoną logiką, ale w przeciwnym razie zwraca przyziemny wynik. Pracujesz razem nad tworzeniem testów jednostkowych dla tej metody i odkładasz zapisywanie tej metody na okres czasu, kiedy pracujesz w izolacji. Po zakończeniu metody wrócisz do siebie jako para i ocenisz wyniki.

Odkryłem, że istnieje niewielka klasa problemów, w przypadku których działa programowanie w parach. Na przykład, jeśli pracujesz nad produktem wieloplatformowym, a facet z Winders zaimplementował funkcję wymagającą kodu specyficznego dla systemu operacyjnego, może pomóc facetowi Mac zaimplementować tę samą funkcję w kodzie Maca, podczas gdy facet jeździ.

Jednak z mojego doświadczenia wynika, że ​​programowanie par powoduje nieoczekiwanie spadek wydajności netto. Tak często wydaje się, że płacimy dwóm programistom za wykonanie jednego.

Tak, zmniejsza to przerażającą możliwość, że deweloper może zrobić przerwę wymiany stosu w ciągu dnia roboczego.

IMHO byłoby taniej dla tych firm, które chcą pilnować swoich deweloperów, aby połączyli każdego dewelopera z prywatnym ochroniarzem, aby stanął za deweloperem i uderzył dewelopera pałką, jeśli kiedykolwiek zwolni lub spróbuje osiągnąć szczyt na nieistotnym Strona internetowa.

Jako programista próbujący dostać się do strefy, będziesz starał się jak najlepiej izolować siebie, aby uzyskać komfort i oczyścić umysł. Dlaczego programowanie parami powinno być inne?

Ty i twój partner powinniście znaleźć środowisko indukujące strefę, które działa dla was obojga. Być może będzie to wymagało kompromisu w niektórych sprawach, ale moim głównym punktem jest to, że środowisko pary powinno być podobne do solo. Wyłącz świat zewnętrzny. Para programuje razem; inne pary (ogólnie inni współpracownicy) nie powinny przeszkadzać (z wyjątkiem krytycznych problemów, polegających na upuszczaniu).

Flow jest świetnym stanem, w którym znasz dokładne kroki w celu rozwiązania problemu. tj. kilka nieznanych niewiadomych. Siedzisz w cichym kącie i odkurzasz rozwiązanie. Jednak większość problemów / historii / funkcji nie jest bardzo jasna, gdy zaczynasz je programować. Zawsze będzie „luka” między oczekiwanym stanem końcowym a tym, jak mózg go „zaplanował”. Nauczysz się wielu rzeczy, kiedy faktycznie to robisz. Twój mózg żongluje

• Projektowanie kodu

• Pisanie na maszynie

• Ucz się nowych rzeczy na temat domeny i kodu

Kiedy programuję sam, próbuję zrównoważyć te rzeczy. Mam skłonność do wchodzenia w „królicze dziury”, gdzie mój błąd utopionych kosztów uniemożliwia mi cofnięcie się o krok i spojrzenie na duże zdjęcie oraz zmianę projektu. Trudno mi też rozmawiać z wyimaginowaną gumową kaczką lub prawdziwą. W końcu jestem w „przepływie”.

Kiedy produktywnie paruję programowanie, dostaję naprzemienne okresy pisania, a następnie okresy myślenia i refleksji. To tutaj ujawnia się wiele ukrytych rzeczy i może pojawić się inny projekt. Jeśli idę do króliczej nory, mój partner z parowania może mnie z tego wyciągnąć. Mówienie / wyjaśnianie czegoś prawdziwemu człowiekowi ma ten cudowny efekt, że w jakiś sposób rozjaśnia twoje myśli. Czasami brakuje mi bycia w „nurcie”, ale myślę, że wnoszę dużo więcej do mojego zespołu, kiedy łączę program, niż kiedy gram solo. Po całym programowaniu! = Pisanie. Programowanie odbywa się w mózgu, a lepsze programowanie dzieje się, gdy dwa mózgi współpracują i krytykują się nawzajem.