Zasada skauta (scout rule)

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

blog@orbisbit.com

Komentarze

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Sprawdź również
  • CQRS – Command Query Responsibility Segregation

    Command Query Responsibility Segregation czyli CQRS. Jest to wzorzec projektowy, który rozdziela zadania odczytu i zapisu do osobnych modeli. Sprawdź ten wpis, aby dowiedzieć się kiedy i jak z niego skorzystać.

    Zobacz wpis

  • GRASP – kolejny zbiór zasad Clean Code do zapamiętania

    Pewnie większość z Was słyszała o zasadach SOLID. Są one bardzo rozpowszechnione i dosyć często stosowane, ale czy słyszeliście o GRASP? General Responsibility Assignment Software Patterns, to kolejna dawka zasad czystego kodu do zapamiętania.

    Zobacz wpis

  • Wzorzec strategia (strategy pattern)

    Jeżeli masz dość if-ologii w swoim kodzie, to konieczne sprawdź czym jest czynnościowy wzorzec projektowy strategia. Pozwala on mądrze obsługiwać różne scenariusze w procesie i jednocześnie być fancy pod względem zasad SOLID.

    Zobacz wpis