Kontrola jakości kodu źródłowego: już nie tylko dla programistów

Dwadzieścia lat temu, kiedy pracowałem w branży motoryzacyjnej, dyrektor jednej z fabryk często mawiał: „Mamy jeden dzień na zbudowanie samochodu, ale nasz klient ma całe życie na sprawdzenie go”. Jakość była najważniejsza. Rzeczywiście, w bardziej dojrzałych sektorach, takich jak przemysł motoryzacyjny i budowlany, zapewnienie jakości jest kluczowym czynnikiem, który jest systematycznie włączany w proces rozwoju produktu. Chociaż jest to z pewnością spowodowane presją ze strony firm ubezpieczeniowych, jest również podyktowane – jak zauważył dyrektor fabryki – długością życia produktu.

Jednak w przypadku oprogramowania krótsze cykle życia i ciągłe aktualizacje oznaczają, że integralność kodu źródłowego jest często pomijana na rzecz nowych funkcji, zaawansowanej funkcjonalności i szybkości wprowadzania na rynek. Menedżerowie produktu często tracą priorytet zapewniania jakości kodu źródłowego lub pozostawiają to programistom, mimo że jest to jeden z bardziej krytycznych czynników decydujących o losie produktu. Dla menedżerów produktu, którym zależy na zbudowaniu solidnych podstaw do rozwoju produktu i eliminowaniu ryzyka, niezbędne jest zdefiniowanie i wdrożenie systematycznej oceny jakości kodu źródłowego.

Definiowanie „jakości”

Przed zbadaniem sposobów prawidłowej oceny i wdrożenia procesu kontroli jakości kodu źródłowego ważne jest, aby określić, co oznacza „jakość” w kontekście tworzenia oprogramowania. Jest to złożone i wieloaspektowe zagadnienie, ale dla uproszczenia możemy powiedzieć, że jakość odnosi się do kodu źródłowego, który wspiera propozycję wartości produktu bez narażania zadowolenia konsumentów i narażania modelu biznesowego firmy deweloperskiej.

Innymi słowy, jakościowy kod źródłowy dokładnie implementuje specyfikacje funkcjonalne produktu, spełnia wymagania niefunkcjonalne, zapewnia satysfakcję konsumentów, minimalizuje zagrożenia bezpieczeństwa i prawne oraz może być utrzymywany i rozszerzany w przystępnej cenie.

Biorąc pod uwagę, jak szeroko i szybko rozpowszechnia się oprogramowanie, wpływ defektów oprogramowania może być znaczący. Problemy takie jak błędy i złożoność kodu mogą zaszkodzić wynikom finansowym firmy, utrudniając wdrażanie produktów i zwiększając koszty zarządzania zasobami oprogramowania (SAM), podczas gdy naruszenia bezpieczeństwa i naruszenia zgodności licencji mogą wpłynąć na reputację firmy i wzbudzić wątpliwości prawne. Nawet jeśli defekty oprogramowania nie mają katastrofalnych skutków, wiążą się z niezaprzeczalnymi kosztami. W raporcie z 2018 r. firma Tricentis ustaliła, że ​​606 awarii oprogramowania z 314 firm spowodowało utratę 1,7 biliona dolarów w poprzednim roku. W opublikowanym właśnie raporcie z 2020 r. CISQ określił koszt oprogramowania złej jakości w Stanach Zjednoczonych na 2,08 biliona dolarów, a kolejne szacowane na 1,31 biliona dolarów poniosą w przyszłości koszty związane z długiem technicznym. Liczby te można złagodzić dzięki wcześniejszym interwencjom; średni koszt rozwiązania problemu podczas projektowania produktu jest znacznie niższy niż rozwiązanie tego samego problemu podczas testowania, co z kolei jest wykładniczo niższe niż rozwiązanie problemu po wdrożeniu.

Postępowanie z gorącymi ziemniakami

Pomimo zagrożeń, zapewnienie jakości w tworzeniu oprogramowania jest traktowane fragmentarycznie i charakteryzuje się podejściem reaktywnym, a nie proaktywnym stosowanym w innych branżach. Kwestionowana jest własność jakości kodu źródłowego, która powinna być postrzegana jako zbiorowa odpowiedzialność różnych funkcji. Menedżerowie produktu muszą postrzegać jakość jako wpływową cechę, a nie koszty ogólne, kierownictwo powinno zwracać uwagę na stan jakości i w niego inwestować, a funkcje inżynierskie nie powinny traktować czyszczenia kodu jako „gorącego ziemniaka”.

Te wyzwania związane z delegowaniem potęguje fakt, że istniejące metodologie i narzędzia nie rozwiązują całości problemu jakości kodu. Zastosowanie metodologii ciągłej integracji/ciągłego dostarczania zmniejsza wpływ kodu niskiej jakości, ale jeśli CI/CD nie jest oparte na dokładnej i holistycznej analizie jakości, nie może skutecznie przewidywać i rozwiązywać większości zagrożeń. Zespoły odpowiedzialne za testowanie jakości, bezpieczeństwo aplikacji i zgodność licencji pracują w silosach, korzystając z narzędzi, które zostały zaprojektowane w celu rozwiązania tylko jednej części problemu i oceny tylko niektórych wymagań niefunkcjonalnych lub funkcjonalnych.

Biorąc pod uwagę rolę Product Managera

Jakość kodu źródłowego wiąże się z licznymi dylematami, przed którymi staje menedżer produktu podczas projektowania produktu i podczas całego cyklu życia oprogramowania. Dług finansowy jest dużym obciążeniem ogólnym. Trudniejsze i droższe jest dodawanie i modyfikowanie funkcji w bazie kodu niskiej jakości, a obsługa istniejącej złożoności kodu wymaga znacznych inwestycji czasu i zasobów, które w przeciwnym razie można by przeznaczyć na rozwój nowego produktu. Ponieważ menedżerowie produktu nieustannie równoważą ryzyko z szybkością wejścia na rynek, muszą rozważyć pytania takie jak:

• Czy powinienem używać biblioteki OSS (oprogramowania open source) czy budować funkcjonalność od podstaw? Jakie licencje i potencjalne zobowiązania wiążą się z wybranymi bibliotekami?
• Który stos technologii jest najbezpieczniejszy? Co zapewnia szybki i tani cykl rozwoju?
• Czy powinienem priorytetowo traktować konfigurowalność aplikacji (wysoki koszt/opóźnienie czasowe) czy wdrożyć niestandardowe wersje (wysokie koszty utrzymania/brak skalowalności)?
• Jak wykonalna będzie integracja nowo nabytych produktów cyfrowych przy zachowaniu wysokiej jakości kodu, minimalizacji ryzyka i utrzymaniu niskich kosztów inżynieryjnych?

Odpowiedzi na te pytania mogą poważnie wpłynąć na wyniki biznesowe i reputację menedżera produktu, jednak decyzje są często podejmowane na podstawie intuicji lub wcześniejszych doświadczeń, a nie rygorystycznych badań i solidnych wskaźników. Dokładny proces oceny jakości oprogramowania nie tylko dostarcza danych potrzebnych do podejmowania decyzji, ale także łączy interesariuszy, buduje zaufanie i przyczynia się do kultury przejrzystości, w której priorytety są jasne i uzgodnione.

Wdrażanie 7-etapowego procesu

Kompletny proces oceny jakości kodu źródłowego skutkuje diagnozą, która uwzględnia pełny zestaw określeń jakości, a nie kilka pojedynczych symptomów większego problemu. Przedstawiona poniżej siedmioetapowa metoda jest zgodna z zaleceniami CISQ dotyczącymi doskonalenia procesów i ma na celu ułatwienie realizacji następujących celów:

• Znajdź, zmierz i napraw problem blisko jego pierwotnej przyczyny.
• Mądrze inwestuj w poprawę jakości oprogramowania w oparciu o ogólne pomiary jakości.
• Rozwiąż problem, analizując pełny zestaw pomiarów i identyfikując najlepsze, najbardziej opłacalne ulepszenia.
• Rozważ całkowity koszt oprogramowania, w tym koszty posiadania, utrzymania i dostosowania licencji/regulacji bezpieczeństwa.
• Monitoruj jakość kodu w całym SDLC, aby zapobiec nieprzyjemnym niespodziankom.

1. Mapowanie produktu do kodu: śledzenie funkcji produktu z powrotem do ich bazy kodu może wydawać się oczywistym pierwszym krokiem, ale biorąc pod uwagę tempo wzrostu złożoności programowania, niekoniecznie jest to proste. W niektórych sytuacjach kod produktu jest podzielony między kilka repozytoriów, podczas gdy w innych wiele produktów korzysta z tego samego repozytorium. Zidentyfikowanie różnych lokalizacji, w których znajdują się określone części kodu produktu, jest konieczne, zanim będzie można przeprowadzić dalszą ocenę.

2. Analiza stosu technologicznego: Ten krok uwzględnia różne języki programowania i używane narzędzia programistyczne, procent komentarzy na plik, procent kodu wygenerowanego automatycznie, średni koszt rozwoju i inne.

Sugerowane narzędzia: cloc

Alternatywy: Tokei, scc, sloccount

3. Analiza wersji: Na podstawie wyników tej części audytu, która obejmuje identyfikację wszystkich wersji bazy kodu i obliczenie podobieństw, można połączyć wersje i wyeliminować duplikaty. Ten krok można połączyć z analizą błędów (gorących punktów), która identyfikuje trudne części kodu, które są najczęściej poprawiane i generują wyższe koszty utrzymania.

Sugerowane narzędzia: cloc, scc, sloccount

4. Zautomatyzowany przegląd kodu: ta inspekcja bada kod pod kątem defektów, naruszeń praktyk programistycznych i ryzykownych elementów, takich jak zakodowane na sztywno tokeny, długie metody i duplikaty. Narzędzia wybrane do tego procesu będą zależeć od wyników powyższej analizy stosu technologicznego i wersji.

Sugerowane narzędzia: SonarQube, Codacy

Alternatywy: RIPS, Veracode, Micro Focus, Parasoft i wiele innych. Inną opcją jest Sourcegraph, uniwersalne rozwiązanie do wyszukiwania kodu.

5. Statyczna analiza bezpieczeństwa: Ten krok, znany również jako statyczne testowanie bezpieczeństwa aplikacji (SAST), bada i identyfikuje potencjalne luki w zabezpieczeniach aplikacji. Większość dostępnych narzędzi skanuje kod pod kątem często występujących problemów bezpieczeństwa zidentyfikowanych przez organizacje takie jak OWASP i SANS.

Sugerowane narzędzia: WhiteSource, Snyk, Coverity

Alternatywy: SonarQube, Reshift, Kiuwan, Veracode

6. Analiza komponentów oprogramowania (SCA)/analiza zgodności licencji: Ten przegląd obejmuje identyfikację bibliotek typu open source połączonych bezpośrednio lub pośrednio z kodem, licencji chroniących każdą z tych bibliotek oraz uprawnień związanych z każdą z tych licencji.

Sugerowane narzędzia: Snyk, WhiteSource, Black Duck

Alternatywy: FOSSA, Sonatype i inne

7. Analiza ryzyka biznesowego: Ten ostatni środek obejmuje konsolidację informacji zebranych w poprzednich krokach w celu zrozumienia pełnego wpływu stanu jakości kodu źródłowego na biznes. Wynikiem analizy powinien być obszerny raport, który dostarczy zainteresowanym stronom, w tym kierownikom produktów, kierownikom projektów, zespołom inżynierskim i kadrze kierowniczej, szczegółowych informacji potrzebnych do oceny ryzyka i podejmowania świadomych decyzji dotyczących produktów.

Chociaż poprzednie kroki w tym procesie oceny można zautomatyzować i ułatwić dzięki szerokiej gamie produktów typu open source i produktów komercyjnych, nie ma istniejących narzędzi, które wspierałyby pełny siedmioetapowy proces lub agregację jego wyników. Ponieważ kompilacja tych danych jest żmudnym i czasochłonnym zadaniem, jest ona wykonywana przypadkowo lub całkowicie pomijana, potencjalnie zagrażając procesowi tworzenia. Jest to moment, w którym dokładny proces kontroli oprogramowania często się rozpada, co czyni ten ostatni krok prawdopodobnie najbardziej krytycznym w procesie oceny.

Wybór odpowiednich narzędzi

Chociaż jakość oprogramowania wpływa na produkt, a tym samym na wyniki biznesowe, wybór narzędzi jest generalnie delegowany do działów rozwoju, a wyniki mogą być trudne do interpretacji przez osoby nie będące programistami. Menedżerowie produktu powinni być aktywnie zaangażowani w wybór narzędzi zapewniających przejrzysty i przystępny proces zapewniania jakości. Chociaż powyżej sugerowane są konkretne narzędzia dla różnych etapów oceny, istnieje szereg ogólnych kwestii, które należy uwzględnić w każdym procesie wyboru narzędzi:

• Obsługiwany stos technologii: należy pamiętać, że większość dostępnych ofert obsługuje tylko niewielki zestaw narzędzi programistycznych i może skutkować częściowymi lub mylącymi raportami.
• Prostota instalacji: narzędzia, których procesy instalacji są oparte na złożonych skryptach, mogą wymagać znacznych inwestycji inżynieryjnych.
• Raportowanie: Preferowane powinny być narzędzia, które eksportują szczegółowe, dobrze ustrukturyzowane raporty, które identyfikują główne problemy i dostarczają zaleceń dotyczących poprawek.
• Integracja: Narzędzia należy sprawdzać pod kątem łatwej integracji z innymi używanymi narzędziami programistycznymi i zarządzającymi.
• Cennik: Narzędzia rzadko są dostarczane z wyczerpującym cennikiem, dlatego ważne jest, aby dokładnie rozważyć inwestycję. Różne modele cenowe zazwyczaj uwzględniają takie rzeczy, jak liczba osób w zespole, rozmiar kodu i zaangażowane narzędzia programistyczne.
• Wdrożenie: Rozważając wdrożenie lokalne w porównaniu z wdrożeniem w chmurze, należy wziąć pod uwagę takie czynniki, jak bezpieczeństwo. Na przykład, jeśli oceniany produkt obsługuje dane poufne lub wrażliwe, preferowane mogą być narzędzia lokalne i narzędzia wykorzystujące podejście ślepego audytu (FOSSID).

Utrzymanie tego w ruchu

Gdy ryzyko zostanie zidentyfikowane i przeanalizowane metodycznie, menedżerowie produktu mogą dokładniej podejmować przemyślane decyzje dotyczące priorytetyzacji i selekcji defektów. Zespoły można zrestrukturyzować i przydzielić zasoby, aby rozwiązać najbardziej pojawiające się lub rozpowszechnione problemy. „Pokonujące przeszkody”, takie jak naruszenia licencji wysokiego ryzyka, miałyby pierwszeństwo przed defektami o mniejszej wadze, a większy nacisk byłby położony na działania, które przyczyniają się do zmniejszenia rozmiaru i złożoności kodu.

Nie jest to jednak jednorazowy proces. Pomiar i monitorowanie jakości oprogramowania powinno odbywać się w sposób ciągły przez cały SDLC. Pełna siedmioetapowa ocena powinna być przeprowadzana okresowo, a wysiłki na rzecz poprawy jakości rozpoczynają się natychmiast po każdej analizie. Im szybciej zostanie zidentyfikowany nowy punkt ryzyka, tym tańsze lekarstwo i mniejsze skutki. Uczynienie oceny jakości kodu źródłowego centralnym elementem procesu rozwoju produktu skupia zespoły, dopasowuje interesariuszy, łagodzi ryzyko i daje produktowi największą szansę na sukces — a to jest biznes każdego menedżera produktu.