Zautomatyzuj swój standard kodowania
Oryginalny tytuł: Automate Your Coding Standard
Autor: Filip van Laenen
Prawdopodobnie byłeś już w takiej sytuacji. Na początku projektu każdy ma sporo dobrych chęci — nazwijmy je "postanowieniami nowoprojektowymi". Bardzo często wiele z tych postanowień jest zapisywanych w dokumentach. Te dotyczące kodu trafiają do standardów kodowania projektu. Podczas spotkania rozpoczynającego projekt, główny programista czyta wszystko, co znajduje się w takim dokumencie, i w najlepszym wypadku, wszyscy zgadzają się z tym, że będą starali się tego przestrzegać. Jednak kiedy projekt się rozpoczyna, dobre postanowienia zostają porzucane jedno po drugim. Kiedy projekt jest w końcu dostarczony, kod wygląda jak istny bałagan i nikt zdaje się nie wiedzieć, jak do tego doszło.
Kiedy coś poszło nie tak? Prawdopodobnie już na spotkaniu rozpoczynającym. Niektórzy z członków zespołu nie uważali. Inni nie zrozumieli sensu. Co gorsza, niektórzy nie zgodzili się i już planowali bunt. W końcu, niektórzy zrozumieli i zgodzili się, ale kiedy presja w projekcie stała się zbyt duża, musieli odpuścić niektóre rzeczy. Dobrze sformatowanym kodem nie zaplusujesz u klienta, który chce więcej funkcjonalności. Co więcej, podążanie za standardami kodowania może być nudne, jeśli nie jest zautomatyzowane. Aby przekonać się o tym samemu, spóbuj ręcznie porobić poprawne wcięcia w niechlujnej klasie.
Tak więc, skoro to jest taki problem, to dlaczego tak bardzo pragniemy standardów kodowania? Jednym powodem, aby unifikować formatowanie kodu jest to, iż nikt nie może "posiadać" kodu poprzez sformatowanie go na swój sposób. Możemy chcieć zapobiegać używania pewnych antywzorców, aby unikać niektórych popularnych błędów. Reasumując, standardy kodowania powinny ułatwiać pracę w projekcie i podtrzymywać prędkość rozwoju oprogramowania od początku do końca. Co za tym idzie to, że każdy powinien zgodzić się na standardy kodowania - robienie wcięć na trzy spacje przez jednego programistę, a na cztery przez drugiego, nie ułatwia sprawy.
Istnieje całe mnóstwo narzędzi, które mogą być użyte do tworzenia raportów o jakości kodu i do dokumentowania oraz utrzymywania standardów kodowania, ale to nie wszystko. Wszystko powinno być zautomatyzowane i egzekwowane, gdzie tylko się da. Poniżej znajduje się kilka przykładów:
- Upewnij się, że formatowanie kodu jest częścią procesu buildowego tak, aby każdy uruchamiał to automatycznie za każdym razem, kiedy kompiluje kod.
- Używaj narzędzi do statycznej analizy kodu, aby sprawdzić kod na obecność niechcianych antywzorców. Jeśli jakikolwiek jest znaleziony, psuj builda.
- Naucz się konfigurować te narzędzia tak, abyś mógł wypatrywać antywzorców specyficznych dla Twojego projektu.
- Nie tylko mierz pokrycie kodu testami, ale też automatycznie sprawdzaj wyniki. I znowu, psuj builda jeśli pokrycie jest za małe.
Staraj się robić powyższe dla wszystkiego, co uważasz za istotne. Nie będziesz w stanie zautomatyzować wszystkiego, na czym Ci naprawdę zależy. Dla tych rzeczy, których nie możesz automatycznie zaznaczyć bądź naprawić, załóż, że są zbiorem dodatkowych dyrektyw standardów kodowania do tych, które są zautomatyzowane, oraz miej świadomość, że Ty i Twoi współpracownicy możecie nie podążać za nimi tak pilnie.
W końcu, standardy kodowania powinny być bardziej dynamiczne aniżeli statyczne. W miarę jak projekt rozwija się, jego potrzeby się zmieniają i to, co mogło wydawać się mądre na początku, niekoniecznie musi być takie kilka miesięcy później.
Artykuł został opublikowany na licencji Creative Commons Uznanie Autorstwa 3.0.
Komentarze (13)
