Zasada skautów

Oryginalny tytuł: The Boy Scout Rule

Autor: Robert C. Martin (Uncle Bob)

Skauci mają zasadę: "Zawsze zostawiaj obozowisko czystsze niż je zastałeś." Jeśli zastaniesz bałagan, posprzątaj go niezależnie od tego, kto był jego sprawcą. Celowo ulepszaj środowisko dla następnych obozowiczów. (W rzeczywistości, oryginalna forma tej zasady, zapisana przez Roberta Baden-Powella, ojca skautingu, brzmi następująco: "Postaraj się zostawić świat choć trochę lepszym, niż go zastałeś.")

A co jeśli wprowadzilibyśmy taką samą zasadę w naszym kodzie: "Zawsze wysyłaj do repozytorium moduł czystszy niż go zastałeś"? Niezależnie od tego, kto był autorem, co jeśli za każdym razem włożylibyśmy trochę wysiłku, nieważne jak małego, aby ulepszyć moduł? Jaki byłby tego efekt?

Myślę, iż jeśli wszyscy byśmy pracowali wedle tej zasady, to bylibyśmy świadkami końca bezlitosnego pogarszania się naszego oprogramowania. Zamiast tego, nasze systemy stawałyby się coraz lepsze, w miarę jak ewoluują. Widzielibyśmy również zespoły, które dbają o system jako całość, zamiast jednostek dbających tylko o swoje małe części.

Nie sądzę, aby trzymanie się tej zasady wiele kosztowało. Nie musisz doprowadzać każdego modułu do perfekcji przed oddaniem go do repozytorium. Musisz tylko sprawić, aby stał się on odrobinę lepszy niż go zastałeś. Oczywiście oznacza to, że kod jaki dodasz do modułu musi być dobry. Oznacza to również, że poprawisz chociaż jedną rzecz przed oddaniem modułu z powrotem do repozytorium. Możesz po prostu poprawić nazwę zmiennej, bądź podzielić długą funkcję na dwie mniejsze. Możesz usunąć cykliczne zależności, albo wprowadzić interfejs, aby odłączyć kontrakt od detali.

Szczerze powiedziawszy, to brzmi to jak pospolita przyzwoitość - jak mycie rąk po skorzystaniu z ubikacji, bądź wrzucenie śmiecia do kosza zamiast na ziemię. W rzeczy samej, fakt zostawiania bałaganu w kodzie powinien być tak samo nieakceptowalny społecznie, jak zaśmiecanie. To powinno być coś, czego po prostu się nie robi.

Niemniej jednak jest w tym coś jeszcze. Dbanie o własny kod jest jedną rzeczą. Dbanie o kod zespołu jest czymś zupełnie innym. 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 dla nich.

Artykuł został opublikowany na licencji Creative Commons Uznanie Autorstwa 3.0.

Tłumaczenie: rafek

Komentarze (11)

pejotr pisze:

03-08-2010 10:59:43

"(...) przed oddaniem modułu spowrotem do repozytorium." "z powrotem", nie "spowrotem". Dodawanie artykułów bez sprawdzenia ich poprawności językowej powinno być jedną z tych rzeczy, których "po prostu się nie robi". ;)

rafek pisze:

03-08-2010 11:27:44

@pejotr: dzięki.

Lopez pisze:

03-08-2010 13:59:53

W idealnym świecie wydaje się to nawet zasadne, szczególnie z punktu widzenia dalszej perspektywy, ale w przypadku dużych projektów (mowa to wielkości rzędu setek tys. linii kodu) wiąże się to z ryzykiem wprowadzenia nowych, często trudnych do wykrycia błędów. Sytuacje znacznie ułatwia tutaj posiadanie unit testów (a nie oszukujmy się, zwykle ich nie mamy), albo chociaż korzystanie z języków kompilowanych. Techniki zwinne natomiast bardzo niechętnie podchodzą do tego tematu. Dodatkowo z biznesowego punktu widzenia jest to często operacja zbyt kosztowna w stosunku do wymiernych korzyści takiej operacji, bo wiadomo, poświęciliśmy dodatkowy czas (czyli pieniądze) na dodatkowe ulepszanie i testowanie kodu, a nie potrafimy nawet oszacować wartości dodanej, albo zazwyczaj jest ona zerowa. Podsumowując "działa, nie ruszaj, no chyba, że musisz" :)

Tomasz Kowalczyk pisze:

03-08-2010 18:03:46

Nim mi o tym nie mówcie, siedzę od dwóch dni i poprawiam projekt po "programistach", naprawiłem już kilkadziesiąt miejsc które powodowały około tysiąca błędów E_NOTICE, czy E_WARNING w PHP. Niby nikomu to niepotrzebne, ale ja po prostu nie mogę pracować z takim kodem. ;]

Gerard pisze:

04-08-2010 10:57:42

W odniesieniu do kodu, czasami nie trzeba wykonywać zmiany. Samo jego przejrzenie może spowodować przecież różne efekty: można uzupełnić lub poprawić dokumentację; można zauważyć element, który wkrótce zostanie klasyfikowany jako "deprecated" i przygotować się; można zauważyć, że gdzie indziej kod został niepotrzebnie zduplikowany itd. Zasada "działa, nie ruszaj" nie jest tożsama z "działa, nie zaglądaj".

2b3 pisze:

05-08-2010 09:05:54

Zgadzam sie z Lopezem - w idealnym swiecie to by bylo bardzo na miejscu. Ale niestety w przyrodzie idealy nie istnieja. Sam bylem niejednokrotnie w sytuacji w ktorej przejmowalismy kod od innej firmy - napisany nieraz tak, ze od samego patrzenia odechciewalo sie wszystkiego(np. poza WndProc, zadnej innej funkcji, a w srodku tej jednej 80 casow i 4000 linii kodu). Ale terminy gonia, a finalny klient nie placi za to zebysmy spedzili dwa tygodnie na dopasowaniu kodu do ludzkich standardow, ale za to zeby sprawic zeby wszystko dzialalo "as designed". Jedyne co pozostawalo nam w takim wypadku to pisanie nowego kodu w sposob cywilizowany. Co innego jesli ma sie do czynienia z nowy projektem - pisanym od zera. Wtedy do gry wchodza firmowe "coding standards" - a tych ktorzy ich nie przestrzegaja i wypuszczaja kod "brzydki" i "niechlujny" czeka bardzo nie mily komentarz po code review i dodatkowy czas spedzony na poprawianiu tego co mozna bylo zrobic dobrze za pierwszym razem. Dodatkowo warto pamietac piszac nowy kod o pewnej zasadzie(bylo chyba takie tlumaczenie na devblogach, aczkolwiek doslownie go nie przytocze): Zawsze pisz kod tak, jakby osoba która będzie pracowała nad nim po tobie była psychopatycznym mordercą, który wie gdzie mieszkasz.

TeMPOraL pisze:

08-08-2010 22:16:19

Fakt, nie żyjemy w idealnym świecie ale to w dużej części dlatego, że wielu ma ideały "w nosie" i chciałoby mieć ten idealny świat dany, żeby zaczęli się starać. Ale nie dostaną go, bo lepsze warunki tworzy właśnie dobre nastawienie ludzi. Fakt, niełatwo się czasem trzymać ideałów; w przypadku kodu sam ostatnio byłem winny kilku niezbyt eleganckich hacków w pracy i gryzie mnie sumienie. Ale myślę, że warto. To wraca prędzej czy później, i chociaż "wartość dodana" może nie być łatwa do sprecyzowania, to ona tam jest. Chociażby taka, że te kilka słów komentarza o tym, co kod ma robić i dlaczego może oszczędzić jakiemuś programiście kilku godzin pracy. Być może za rok, być może w innej firmie, ale ktoś będzie miał dzięki temu lepszy dzień, jakiś projekt pójdzie szybciej do przodu. Świat stanie się ciut lepszym miejscem do życia. /* Już nie mówiąc o tym, że czasem trzeba wrócić do własnego kodu pisanego kilka tygodni lub miesięcy wcześniej. ;) */

noisy pisze:

10-08-2010 20:21:48

Ten wpis zakłada, że kod z którym pracujemy nie jest przez nikogo utrzymywany. Tak jednak często nie jest. Jest np. module owner i to on odpowiada za to jak ten moduł wygląda. Oczywiście możemy wprowadzić zmiany i wysłać mu patcha, ale on musi je przejrzeć i zaaplikować..a być może wersja z której ja korzystam jest już daleko, daleko od bieżącej i po prostu nie opłaca się wprowadzać pewnych zmian. Nawet jeżeli dany kod nie ma module ownera, to i tak wg mnie stosunkowo rzadko spotykamy się z sytuacją w której to jesteśmy pewnie w 100% jak dany kod działa i czy nasze zmiany na pewno coś upraszczają. Bardzo często kod z którym musimy pracować to dziedzictwo wielu wcześniejszych programistów, czyli kod plus 7 fixów dla każdej funkcji. Wg mnie powyższa zasada jest możliwa do stosowania ale chyba bardziej dla stylu niż samej treści. Widzisz, że coś jest źle sformatowane, wcięcia nie te, widzisz że ktoś korzysta z magic numberów, które możesz zamienić na stałą... ok, możesz wtedy wprowadzić pewne zmiany... ale przez niektórych to nie jest czasem porządane....

wojtekm pisze:

07-03-2011 10:29:16

imho to kolejny sposób na zajmowanie się nie tym co potrzeba. Jak przedmówcy pisza-jest mnóstwo argumentów przeciw, a za jest tylko to, że będzie ładniej i czytelniej. Ale jakim kosztem i czy to naprawdę potrzebne?

kuba pisze:

24-03-2011 10:40:04

To "ładniej i czytelniej" może przynieść konkretne i spore oszczędności. Ale zgadzam się, cudzą kupę (skoro już mowa o obozowisku) łatwo zakopać jak się wie, że nie stała się niezbędną częścią ekosystemu.

soho pisze:

15-01-2012 14:45:13

W małych firmach mało kto poprawia kod. Jest to strata czasu dla rządzących, którzy nie rozumieją pewnych zachodzących procesów podczas rozwoju aplikacji. Rządzący widzi tylko, że brak nowych funkcjonalności i zysków w pewnym odstępie czasu. Jeśli firma źle stoi to zwalnia właśnie tych, którzy chcieli być dobrzy i poprawić pewne rzeczy po kolegach. No bo jak się ma obronić taka osoba, że nie widać efektów jego pracy. Powiedzieć, że jego koledzy to robią co chcą byle były widoczne efekty a później nie da się połapać w kodzie.

Dodaj komentarz