Zastanawialiście się czy w programowaniu mamy coś podobnego do Savoir-vivre? Okazuje się, że tak! Idealną kandydatką do miana jednej z zasad, może być znana w harcerstwie reguła skauta. Przenieśmy ją do kodu, jako jedną z zasad dobrych manier.
Kto był harcerzem, ten wie!
Reguła, o której będę dzisiaj pisał jest szeroko znana w środowisku harcerskim. Może wydać Ci się to zabawne, ale doskonale nadaje się ona do zastosowania w świecie programowania. Mowa tutaj o zasadzie skauta, której używanie jest swoistego rodzaju przejawem dobrych manier w kodzie i nie tylko, ale do rzeczy! O co w niej chodzi? W oryginale brzmi ona następująco: „zostaw obozowisko w stanie lepszym, niż je zastałeś/aś”. Tę świetną sentencję możemy przerobić do postaci: „zostaw kod lepszym, niż go zastałeś/aś”.
Zasada skauta w praktyce
Jak przestrzegać tej zasady? Wystarczą drobne uczynki! Jeśli jesteś w lesie i znajdziesz papierek, to go podnieś i wyrzuć. Zostawisz las w stanie lepszym, niż był wcześniej. Dokładnie to samo można zrobić w Twoim projekcie. Każdemu czasami zdarzy się przecież zostawić nieużywany import lub zmienną (statyczna analiza kodu f.t.w.), albo źle umiejscowić plik. Za jakiś czas do kodu zagląda nasz kolega z zespołu, bo musi coś w tym pliku zmienić. Chcąc spełniać zasadę skauta powinien on usunąć nieużywaną zmienną czy też przenieść plik w poprawne miejsce. Prosto mówiąc, powinien on pozostawić swoje obozowisko (plik projektu) w stanie lepszym, niż je zastał.
Nie naprawisz błędów całego świata…
Oczywiście, nie można popaść w skrajność. Załóżmy, że Twoim zadaniem jest dodanie nowej metody w pewnej klasie serwisowej, która wygląda tak:
class UsersServic { private sendEmail() { /* ... */ }
create() { /* ... */ }
constructor(private r: UserRepository,
) {}
update() { /* ... */ }
}
Programista implementujący tę klasę niepoprawnie ją nazwał, nie uruchomił formatowania kodu, a także źle poukładał jej metody. Skoro i tak już zmieniasz ten kod, to spróbuj go poprawić. Uważaj jednak, aby nie przesadzić. Jeśli Powyższa klasa używana jest w 30 miejscach, to zmiana jej nazwy spowoduje, że wszystkie te 30 miejsc trzeba będzie zmienić. Trzeba znać granice i wiedzieć kiedy drobny uczynek spowoduje, że obozowisko stanie się lepsze, bo nikt nie każe Ci, abyś posprzątał/a całe obozowisko.
class UsersServic { p
constructor(private r: UserRepository) {}
create() { /* ... */ }
update() { /* ... */ }
private sendEmail() { /* ... */ }
}
Kiedy stosować zasadę skauta?
Stosowanie się do zasady skauta w programowaniu jest przejawem dobrych manier, szczególnie jeśli pracujemy w zespole. Zamiast wytykać komuś, że źle poukładał kod, bądź nazwa zmiennej nie jest zgodna z Waszym standardem, to po prostu weź to na siebie. Niekiedy, zdarzyć się może, że trafisz na projekt z project managerem lub scrum masterem, który jest typowym „agile-nazi”. Dostaniesz wtedy zakaz stosowania tej pięknej reguły, bo na wszystkie zmiany musi być osobny ticket w Jirze – wtedy uciekaj z tego projektu <heheszki>. Jeśli jednak masz możliwości do „sprzątania obozowiska”, to sprzątaj małymi krokami, np.:
- niepoprawna nazwa zmiennej,
- nieużywane fragmenty kodu,
- zagnieżdżone instrukcje warunkowe,
- literówki,
- niepotrzebne komentarze,
- brakujące komentarze dla skomplikowanego kodu,
- brak testu jednostkowego.
To Ty musisz wiedzieć, kiedy poprawka jest na tyle mała, że nie spowoduje lawiny zmian, a w efekcie czego nie sprzątniesz całego projektu.
Podsumowanie
- Zasada skauta to nasza (programistów) złota reguła savoir-vivre.
- „Zostaw projekt w stanie lepszym, niż go zastałeś/aś”.
- Nie bądź zbyt nadgorliwy/wa, bo posprzątasz cały projekt, a satysfakcja przerodzi się w frustrację.
Dodaj komentarz