Bugi – jak zapobiegać zamiast leczyć

Jak działać prewencyjnie jakością kodu, testami oraz innymi zabiegami, aby oszczędzić sobie czas fixowania.

Temat niejednokrotnie poruszany na blogu, ale uzbierało się parę wątków, które moim zdaniem warto tutaj zebrać i po krótce opisać. Nie jesteśmy idealni i co jakiś czas w naszych programach coś nie działa. Walka z błędami chyba nikomu nie daje takiej satysfakcji jak dodawanie kolejnych funkcjonalności. Co możemy zrobić, aby tych bugów pojawiało się jak najmniej? W artykule skupię się na kilku pomocnych narzędziach i zabiegach. 

Analiza statyczna kodu

Na początek coś prostego, co łatwo będzie Wam wprowadzić do codziennego pisania kodu. Przydatne narzędzie, dość naturalnie używane w profesjonalnych projektach – analiza statyczna kodu. To coś na rodzaj sprawdzenia kodu pod kątem warningów. Generalnie ostrzeżenia to ważna sprawa. Część początkujących programistów kompiluje projekt, nic nie świeci się na czerwono, buduje się, to super. Często jednak te ostrzeżenia pomiędzy, które gdzieś tam monitują tylko na żółto, zawierają wiele ważnych informacji, mogą mieć potencjalny wpływ na jakość naszego kodu. Ignorowanie ich może skończyć się nawet błędem podczas pracy programu lub spadkiem jego performance’u.

Prosta sprawa, przekazujecie tekst do funkcji. 

Poniższy kod działa.

void foo (String text)
{
    //np. wyświetlanie tekstu na ekranie
}

//...

foo("Jakiś tekst");

Jednak kolejny działa znacznie szybciej.

void foo (String& text)
{
    //np. wyświetlanie tekstu na ekranie
}

//...

fun("Jakiś tekst");

Poniższy kod dla kompilatora nie jest problemem, ale w normalnym działaniu skończy się tragedią.

char text [4];

void print_char(char some_letter)
{
    //coś tam sobie robi z literką
}

//...

print_char(text[4]);

Na przedstawione przykłady i inne zagrożenia możemy nawet nie uzyskać ostrzeżenia od kompilatora, ale może to dla nas zrobić narzędzie do analizy statycznej kodu. Dla C++ to często Cpp check, który pokazałem na wideo. 

Takie sprawdzenie zajmie tylko chwilę, a pomoże nam zwrócić w postaci przejrzystego raportu uwagę na miejsca, gdzie kod można poprawić i zapobiec bugowi. 

Unit testy

Następny pomocnik, a właściwie cały szereg pomocników, wymaga od nas trochę więcej pracy, ale jest niezwykle istotny. Większość programistów zna ten temat bardzo dobrze. O testach, także tych jednostkowych, wspominałem już trochę na blogu – tutaj oraz tutaj

Nasze kody używają różnych klas i funkcji, które sami tworzymy i potrafimy zdefiniować, co one mają robić. Jeśli już “myślimy kodem” to potrafimy to zdefiniować nawet za pomocą kilku linii, np. zakładam że moja funkcja:

uint8_t calculations(uint8_t base, uint8_t parameter)
{
    //jakieś skomplikowane obliczenia
}

przy podaniu parametrów 100 i 20 da wynik 68. Kodem możnaby sprawdzić poprawność działania mniej więcej w taki sposób:

if(calculations(100, 20) == 68)
{
    //wszystko działa poprawnie
    //możemy sobie to gdzieś wyświetlić
}

Na szczęście ktoś to już przemyślał i przygotował nam do tego całkiem solidny zestaw narzędzi. W materiale opisałem to, jak w projekcie, który korzysta z frameworku Arduino, uruchamiam unit testy z najbardziej popularnym framewrokiem UT do C++: Google test.

Jak najlepiej zacząć z unit testami?

  • Przejść przez wprowadzenie od Googla.
  • Przygotować według wideo środowisko.
  • Przemyśleć architekturę naszego oprogramowania.
  • Pisać testy, jak najwięcej potrafimy ich wymyślić, co jest dobrym testem kreatywności 😉

Jeśli będziecie mieli jakieś problemy, piszcie śmiało 🙂

Czyste i sformatowane

Ważnym elementem w kodzie jest jego czystość i mówię tutaj nie tylko o tych najważniejszych elementach jak architektura. Chodzi mi także o takie małe składowe, jak np. brak nieużywanych funkcji/zmiennych, z którymi pomoże nam także Cpp check oraz nazwy zmiennych i trzymanie się jakiejś konwencji stylu. Z tym drugim pomoże nam Clang format. Po co nam to? Patrząc na przejrzysty kod, łatwiej znaleźć błędy! Dlatego zachęcam do video o tym narzędziu oraz polecam klasyk wśród książek dla programistów – “Czysty Kod” autorstwa Robert C. Martina.

Code review

Pomimo zastosowania tych elementów i tak może nam się zdarzyć błąd /: Stąd programiści mają do siebie ograniczone zaufanie i praktykuje się code review. To także powszechny zabieg w wielu projektach. Wygląda to następująco, jak na schemacie poniżej.

Na czym to polega? Drugi programista przegląda nasz kod, sprawdzając czy np. coś można poprawić lub coś zagraża bezbłędnemu działaniu. (Jak to Ewa sprawdza, czy notka będzie dla Was zrozumiała). Wiele osób może to stresować, że ich kod będzie oceniany. Moim zdaniem nie ma się czego bać, tu nie chodzi o to, żeby komuś wytykać błędy na złość i się z kogoś śmiać. Chodzi o jakość kodu i uczenie się. Takie review to świetna sprawa w nauce programowania. Polecam, nieraz dostałem do swojego kodu fajne pro tipy 😉 Jak możecie poddać swój kod review, nie pracując w zespole? Wrzućcie choćby na naszego discorda w dział code review 🙂  

Podsumowanie

Oczywiście, to nie wszystkie pomysły na ratowanie swojego kodu przed błędami, ale może Wam pomogą. Z pewnością jeszcze wrócę do tematu, kiedy będę przedstawiał automatyzację omóqwionych procesów.

Pamiętajcie, praca programisty to nie tylko wrzucanie na ślepo funkcjonalności na zasadzie “ważne że działa”, ale także dbałość o szczegóły, jakość tego, co spod naszych palców wychodzi 😉 Jeśli macie jakieś swoje sposoby na unikanie błędów, podzielcie się nimi w komentarzach. Niebawem pojawi się także artykuł o tym, co robić, kiedy błędy się już pojawią 🙂

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.