Przejdź do głównej zawartości

Gdzie jest majster?

Majster na budowie to człowiek odpowiedzialny za to, że wszyscy pracownicy robią to, co powinni. On jest tym człowiekiem z miarką, który kręci się dookoła i upewnia się, że wszystkie ściany są ustawione odpowiednio. On jest tym człowiekiem, który sprawdza wszystkie rozpórki, spoiny i belki, aby upewnić się, że są zmontowane odpowiednio i nie mają żadnych znaczących uszkodzeń. On jest tym człowiekiem, który liczy wkręty w podłodze, aby upewnić się, że podłoga nie będzie skrzypieć, jeżeli będziesz po niej chodzić. On jest tym człowiekiem -- człowiekiem, który bierze na siebie odpowiedzialność -- człowiekiem, który upewnia się, że wszystko jest robione właściwie.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony:
https://8thlight.com/blog/uncle-bob/2014/02/21/WhereIsTheForeman.html
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Gdzie jest majster naszych projektów budowy oprogramowania? Gdzie jest człowiek, który upewnia się, że wszystkie testy zostały napisane? Gdzie jest człowiek, który upewnia się, że wszystkie wyjątki zostały obsłużone. Gdzie jest człowiek, który upewnia się, że błędy są sprawdzone i obiekty nie są nullami i zmienne są bezpieczne dla wielu wątków. Gdzie jest człowiek, który upewnia się, że programiści wystarczająco programują w parach, wystarczająco rozmawiają ze sobą, wystarczająco planują? Gdzie jest człowiek, który sprawia, że podłogi nie skrzypią?

Bez dobrego majstra budowa pogrążyłaby się w chaosie. Ściany nie schodziłyby się. Drzwi wisiałyby krzywo. Zimna woda wypływałaby z gorącego kurka, a gorąca woda z zimnego. Bez dobrego majstra podłoga i dach przeciekałyby i z kominka dymiłoby do salonu. Bez dobrego majstra budowa skończyłaby się dużo po czasie, daleko poza budżetem i w nędznej jakości.

Bez majstra podłogi skrzypiałyby.



Co robiłby majster na projekcie budowy oprogramowania? Robiłby to samo, co na budowie.  Upewniałby się, że wszystko zostało zrobione, zrobione dobrze i zrobione na czas. Byłby jedynym z prawami do kommitów. Wszyscy inni wysyłaliby mu pull requesty. On przeglądałby każdy request po kolei i odrzucałby te które nie miałyby odpowiedniego pokrycia testami albo miałyby burdel w kodzie, albo złe nazwy zmiennych, albo funkcje byłyby za długie. On odrzucały te, które w jego mniemaniu nie spełniają poziomu jakości żądanego dla tego projektu.

Mogę sobie wyobrazić, że wielu programistów odrzuca pomysł, że ktoś inny ma władzę oceny ich kodu i odrzucania ich kommitów. No bo przecież, jak można dostarczyć na czas całą tę funkcjonalność, jeżeli kod ma być jeszcze czysto napisany? Jak możesz dotrzymać harmonogramu, jeżeli musisz jeszcze napisać te wszystkie testy? Mam na myśli to, że jeżeli będzie człowiek, który w rzeczywistości będzie patrzył na kod, nie będzie możliwości postawienie siebie w dobrym świetle, mówiąc, że kod jest skończony, jeżeli w rzeczywistości nie będzie. To byłoby okropne.

Okropne czy nie, tak właśnie robi większość branż. Jeżeli chcesz mieć robotę zrobioną, zrobioną dobrze i zrobioną na czas to potrzebujesz majstra.  I ten majster musi być technicznie wnikliwy, aby móc sprawdzić pracę, wszystkich pracowników. On musi mieć prawo do odrzucania każdej pracy, którą uważa za poniżej standardów. I on także musi mieć władzę, aby móc powiedzieć "Nie" nierealnym żądaniom klientów i menedżerów.

Gdzie jest majster naszych projektów informatycznych? Gdzie jest człowiek z jedynymi prawami do kommitów? Gdzie jest człowiek, który upewnia się, że wszystkie testy są napisane i wszystkie warstwy abstrakcji są rozdzielone i wszystkie zależności są odwrócone?


Dlaczego nie mamy takiego człowieka?

Czy można się jeszcze dziwić, że nasze podłogi skrzypią?




Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony:
https://8thlight.com/blog/uncle-bob/2014/02/21/WhereIsTheForeman.html
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Komentarze

  1. A kto powiedział że majstrem nie może być cały zespół? Dobry SM ma właśnie za zadanie doprowadzić do takiej sytuacji gdzie każdy członek zespołu czuje odpowiedzialność A nie tylko jakiś wybraniec. Lider, kapitan zespołu w grupie tak. Ale to nie rodzaj audytora tylko drogowskaz dla reszty którędy podążać.
    Ale taka konstrukcja jest o rząd wielkości trudniejsza do zbudowania niż setup z majstrem. Boję się że częściej mamy majstrow, albo SM z mentalnością audytora, dla tego software trzeszczy i skrzypi...

    OdpowiedzUsuń
    Odpowiedzi
    1. Cześć Artur,

      Dzięki za komentarz.
      Słusznie zauważyłeś, że majster to rola i może być spełniana przez jednego człowieka i może być spełniana przez grupę ludzi. Jednak, tak jak piszesz profesjonalizm w grupie nie rozprzestrzenia się łatwo, a już na pewno nie rozprzestrzenia się samoczynnie. Warto więc zacząć od jednego człowieka.

      Usuń

Prześlij komentarz

Popularne posty z tego bloga

Kursy IT na Pluralsight. Dlaczego warto?

Bardzo sobie cenię kursy na Pluralsight. Mam wrażenie, że każdy kurs, który przeszedłem na tej platformie, w dużym stopniu podniósł moje zdolności. Wiem, dostęp do tej platformy nie jest tani, ale w mojej ocenie warty swojej ceny. To nie jest reklama, ale forma entuzjazmu jaki mam do tej formy samodoskonalenia. O to kilka punktów pokazujących ofertę tego serwisu i dlaczego warto skorzystać: Pluralsight to kursy z Javascript, C#, Java, Angular, Python, MySQL i wielu innych technologii i umiejętności. Kursy na Pluralsight w większości mają wyższą jakość niż te, które możemy znaleźć na przykład na YouTube. Są wyselekcjonowane, mają wysoką jakość dźwięku i obrazu. Często wgryzają się głęboko w dany problem daleko poza standardowe „Hello World” danej technologii. Twórcy Pluralsight to często osoby znane ze świata IT i konferencji branżowych, jak: Scott Hanselman, Microsoft John Somnez, SimpleProgrammer.com John Skeet, Google Pluralsight udostępnia funkcjonalność ścieżek – paths.

Algorytm Dijkstry

Byłem jednego dnia na SCNA , i ktoś zagadnął mnie o TDD i algorytm Dijkstry . Zastanawiał się, czy można znaleźć sekwencję testów, która zaprowadzi do tego algorytmu. To wyglądało mi na fajne, krótkie ćwiczenie, więc zdecydowałem się spróbować. Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony: https://blog.cleancoder.com/uncle-bob/2016/10/26/DijkstrasAlg.html Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta. Zacząłem tak, jak zwykle; przez odpalenie ograniczonego przypadku testowego. public class MinPathTest { @Test public void nothing() throws Exception { } } Algorytm Dijkstry jest prostym sposobem znajdowania najkrótszej drogi w grafie o krawędziach mających konkretną długość. Podając węzeł startowy i końcowy, algorytm wskaże, jaka jest najkrótsza ścieżka i jaka jest jej długość. A więc już od samego początku są ciekawe decyzje do podjęcia. W jaki sposób p

Podstawy Programowania Funkcyjnego Epizod 3

Czy wszystkie Zasady Się Zmieniają? Kiedy tylko zaczynamy używać nowego paradygmatu , porównujemy z nim nasze dotychczasowe zasady i nawyki. Pytamy siebie czy te wszystkie zasady i nawyki są poprawne w kontekście tego nowego paradygmatu. Rozważ, dla przykładu: Test Driven Development . Czy nadal jest poprawne w Programowaniu Funkcyjnym? Jeżeli tak, to jak się do tego zabierzesz? Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina z dnia 07 stycznia 2013 ze strony: https://blog.cleancoder.com/uncle-bob/2013/01/07/FPBE3-Do-the-rules-change.html Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta. Aby odpowiedzieć sobie na to pytanie spróbujmy napisać prosty funkcyjny program: Word Wrap (zawijanie tekstu). Wymagania są proste. Mając napis złożony ze słów, oddzielonych pojedynczymi spacjami