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