Przejdź do głównej zawartości

Zasada skautów

Skauci mają zasadę: "Zawsze zostawiaj obozowisko czystsze niż je zastałeś." Jeśli zastaniesz bałagan, posprzątaj go, niezależnie od tego, kto to zrobił. Celowo ulepszaj otoczenie dla następnych obozowiczów. W rzeczywistości, oryginalne brzmienie tej zasady, zapisanej przez Roberta Stephensona Smytha Baden-Powella, ojca skautingu, jest następujące: "Postaraj się zostawić świat choć trochę lepszym, niż go zastałeś."

Poniższy tekst jest tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony (Wayback Machine) :


Bazowałem na tłumaczeniu jakie dokonał Rafał Legiędź. @rafek.

na nieistnieącej już stronie 97rzeczy.devblogi.pl.

Archiwum na Wayback Machine

Licencja oryginalnego tekstu: Creative Commons Attribution 3


Co byłoby gdybyśmy postępowali według tej samej zasady podczas naszego kodowania: "Zawsze wysyłaj do repozytorium moduł czystszy niż go pobrałeś"? Co byłoby gdybybyśmy zawsze wkładali trochę wysiłku, nieważne jak małego, aby ulepszyć moduł, niezależnie od tego, kto był oryginalnym autorem? Jaki byłby rezultat?
Myślę, że jeżeli wszyscy pracowalibyśmy według tej zasady, to doświadczylibyśmy końca nieustającego pogarszania się naszego oprogramowania. Zamiast tego, nasze systemy, ewoluując stawałyby się coraz lepsze. Dostrzeglibyśmy zespoły, które dbają o system jako całość, a nie tylko indywidualne jednostki dbające o swoje małe części.
Nie sądzę, aby ta zasada była prośbą o zbyt wiele. Nie musisz doprowadzać każdego modułu do perfekcji przed oddaniem go do repozytorium. Po prostu musisz tylko sprawić, aby stał się odrobinę lepszy niż go zastałeś. Oczywiście oznacza to, że jakikolwiek kod jaki dodajesz do modułu musi być czysty. Oznacza to również, że musisz poprawić chociaż jedną dodatkową rzecz zanim skomitujesz moduł do repozytorium. Mógłbyś po prostu poprawić nazwę zmiennej, albo podzielić długą funkcję na dwie mniejsze. Mógłbyś usunąć cykliczne zależności, albo wprowadzić interfejs, aby odłączyć kontrakt od detali.


Szczerze mówiąc, to brzmi jak zwykły dobry nawyk - jak mycie rąk po skorzystaniu z ubikacji, bądź wrzucenie śmieci do kosza zamiast na ziemię. W rzeczywistości fakt zostawiania bałaganu w kodzie powinien być tak samo nieakceptowalny społecznie, jak śmiecenie. To powinno być coś, czego po prostu się nie robi.
Ale to coś jeszcze wiecej. Dbanie o własny kod to jedno. Dbanie o kod zespołu to kolejna rzecz. Zespoły pomagają sobie i wzajemnie po sobie sprzątają. Pracują trzymając się Zasady Skautów, ponieważ jest dobra dla wszystkich, a nie tylko dobra dla nich samych.

Powyższy tekst jest tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony (Wayback Machine):


Bazowałem na tłumaczeniu jakie dokonał Rafał Legiędź. @rafek.

na nieistnieącej już stronie 97rzeczy.devblogi.pl.

Archiwum na Wayback Machine

Licencja oryginalnego tekstu: Creative Commons Attribution 3

Komentarze

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