Jakość techniczna - czyli pięć zasad, które spowodują, że oprogramowanie będzie lepsze

Co jako developer uznać za dobrze wykonaną robotę w projekcie? To dosyć trudne zagadnienie, jednak dziś postaram się nieco przybliżyć moje spojrzenie na ten temat.

Jakość techniczna - czyli pięć zasad, które spowodują, że oprogramowanie będzie lepsze

Co jako developer uznać za dobrze wykonaną robotę w projekcie? To dosyć trudne zagadnienie, jednak dziś postaram się nieco przybliżyć moje spojrzenie na ten temat.

Przede wszystkim należy pamiętać, że tworzenie oprogramowania, to nie tylko pisanie kodu. Bo gdyby tak było, to wystarczyłoby napisanie perfekcyjnej pętli, czy instrukcji warunkowej i zadanie można by uznać za wykonane na wysokim poziomie.

Więc co dokładnie składa się na jakościową pracę programisty?

  • Przygotowywanie kodu zgodnego ze standardami projektowymi

Każdy programista pracujący w projekcie musi przestrzegać standardów i sposobu pisania kodu zdefiniowanego przez zespół. Jeśli chcemy, żeby projekt był zarządzały i żeby dało się go rozwijać przez długi czas, to najlepiej zadbać o jego przewidywalność poprzez spójny standard wytwarzania kodu.

Sam ze swojego doświadczenia wiem, że jeśli nigdy nie było ustanowionego standardu i zasad kodowania w projekcie, to prędzej, czy później uda nam się natknąć na conajmniej kilka konwencji, które nie muszą być ze sobą spójne i bardzo utrudniają utrzymywanie aplikacji.

  • Pozostawianie kodu w lepszym stanie niż się go zastało

To dosyć ważna zasada, której powinien trzymać się każdy programista. Czyli jeśli pracujesz nad nową funkcją w projekcie i dotykasz kodu, który ma pewne problemy, to warto poświęcić dodatkową godzinę na delikatny refactoring tego co zastaliśmy. Natomiast tą zasadę trzeba stosować z umiarem - czyli nie przepisujemy całej, istniejącej funkcjonalności, jak tylko zauważyliśmy coś małego do poprawy. Sam podchodził bym do tego w taki sposób, że jeśli miejsce nad którym pracujemy jest nie najlepsze, ale nadal da się do niego dodać coś nowego, to wykonałbym zadanie, które przede mną stoi, zadbałbym o nieco poprawek (jak rozbicie obecnie istniejącego kodu na mniejsze funkcje) i dodałbym dodatkowy task do backlogu produktu na pełną refaktoryzację/przepisanie.

  • Implementacja zgodna ze specyfikacją/designem

Jest to bardzo ważny punkt, na którym wielu programistów się wykłada. Jeśli tworzymy nowe rozwiązanie, musimy być pewni, że to co zrobiliśmy działa tak, jak klient tego wymaga. Jeśli mamy design i piszemy aplikację front-endową, to musimy dbać o to, żeby nasz interfejs wyglądał tak jak na designie (szczególnie pod kątem wszelkich mniejszych elementów jak border, zaokrąglenia i inne). I generalnie cała funkcjonalność musi działać zgodnie z założeniami.

  • Testy

Testy jednostkowe, integracyjne, E2E, czyli wszystkie możliwe i potrzebne w danym projekcie. Są nie tylko dupochronem ale i świetnym sposobem na lepszą jakość wykonanych zadań! Dzięki nim jesteśmy w stanie przygotować dobrze działający kod i mieć pewność, że w przyszłości nasze zmiany nie spowodują błędów w miejscach, o których nie pomyśleliśmy.

  • Dbanie aby kod był czytelny

Jest to jedna z pierwszych i najważniejszych zasad, której nauczyłem się podczas swojej przygody z programowaniem. Jeśli dbamy o to by funkcje były małe, nazwy zmiennych opisowe i nie było zbyt dużo zagnieżdżeń, to jest to dobry znak, a kolejny programista odwiedzający ten konkretny kawałek kodu, będzie mógł dokonać w nim zmian w przyszłości

I to są właśnie moje zasady jeśli chodzi o jakość techniczną projektu. Bez tych pięciu, żaden projekt nie ma prawa bytu! Oczywiście, jak wspomniałem na początku - jest wiele innych punktów i zasad, które można wziąć pod uwagę, ale z tymi pięcioma projekt będzie szedł zgodnie z planem i wymaganiami klienta.