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....

Bicie piany

Czy słyszałeś o tym gościu, który powiedział, że Object Oriented to przeżytek? No nie. Następny. Co powiedział? Opisał wszystkie obietnice OO, i jak żadna z nich tak naprawdę nigdy nie została spełniona i o tych wszystkich możliwościach OO, które kosztują więcej, niż są warte i że funkcjonalne programowanie jest lepsze i ... Phi. Tak słyszałem już to wcześniej. No, więc OO jest martwe, leży i kwiczy i możemy przejść dalej. Przejść dalej do czego? Co? No do NASTĘPNEJ WIELKIEJ RZECZY oczywiście. Aaaa, do tego. Czy wiesz już co to jest? Nie bałdzo, ale jestem podekscytowany na myśl o mikroserwisach; jaram się Elixirem; i słyszałem, że React jest fantastyczny; i ... Tak, tak. Bicie piany. Dałeś się nabrać na bicie piany. Co? Co masz na myśli. Przecież mamy takie wspaniałe czasy. Tak naprawdę postrzegam te czasy jako depresyjne. Ale dlaczego? Przecież co kilka dni wyskakują nowe wspaniałe technologie! Wspinamy się na coraz wyższe szczyty. Phi. To, co tak napraw...

Podstawy Programowania Funkcyjnego Epizod 1

O czym jest programowanie funkcyjne? Zakładam, że słyszałeś już kiedyś o programowaniu funkcyjnym. No cóż, któż nie słyszał? Wszyscy o tym gadają. Wychodzi dużo nowych języków funkcyjnych takich, jak Scala, F# i Clojure. Ludzie rozmawiają też o starszych językach jak Erlang, Haskell, ML i innych. A więc, o co w tym wszystkim chodzi? Dlaczego programowanie funkcyjne jest Następną Wielką Rzeczą™? I co jest w tym takiego pociągającego? Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina z dnia 22 grudnia 2012 ze strony: https://blog.cleancoder.com/uncle-bob/2012/12/22/FPBE1-Whats-it-all-about.html Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta. Po pierwsze, prawie na pewno programowanie funkcyjne jest następną wielką rzeczą. Są ku temu dobre, solidne powody i poznamy je w tym artykule. Ale najpierw, aby zrozumieć te powody, musimy poznać, czym programowanie funkcyjne jest....