Miliony linii kodu a problem bezpieczeństwa i przetwarzania danych.
Artykuł zwraca uwagę na ewolucję i wielkość współczesnych programów. Kody liczone w milionach linii powodują, iż konieczne staje się inne spojrzenie na jakość i niezawodność tak wielkich konstrukcji tworzonych przez wieloosobowe zespoły.
W ostatnich latach, wraz ze wzrostem objętości pamięci dyskowych i spadkiem kosztów przechowywania danych, pojawiła się wyraźna tendencja do zwiększania wielkości oprogramowania.
Oczywiście tak wielkie kody współczesnego oprogramowania powstają latami w zespołach programistów, analityków, projektantów i testerów. Wielkość kodu oprogramowania moim zdaniem ma istotny wpływ na bezpieczeństwo i jakość przetwarzania.
Warto tu wspomnieć o nagłośnionym w październiku 2013 r. problemie z wielkim kodem healthcare.gov. Według anonimowych źródeł ok. 1% tego kodu (czyli "jedyne" 5 mln linii kodu) powinien być przepisany na nowo z powodu wielu potencjalnych błędów. Można tu podać dwa przykłady. Typowym błędem może być pojedynczy znak zakończenia bloku, w wielu językach programowania nawias klamrowy "}". Znak ten umieszczony w złym miejscu może spowodować błędy często trudne do powtórzenia i - zwłaszcza w dużym kodzie " niemal niemożliwe do zlokalizowania. Takiego błędu kompilator może nie wychwycić. Innym źródłem problemów w heralthcare.gov były linie komentarzy. Zapis "//TODO: make sure this code doesn't crash!" to zapewne uwaga od inżynierów sprawdzających kod i nie budzi zastrzeżeń (podwójny slash "//" powoduje, że kompilator pomija tą linię kodu). Problem pojawia się jednak wtedy, gdy komentarzy jest znacznie więcej niż kodu właściwego i nie zawsze są właściwie oznaczone, co niestety w tym przypadku miało miejsce.
Nad tak złożonym i obszernym oprogramowaniem jedna osoba nie jest w stanie zapanować. W praktyce oznacza to konieczność rozdzielania odpowiedzialności za jakość kodu na zespoły ludzi. To z kolei wymaga stworzenia i przestrzegania procedur postępowania, przydzielania odpowiedzialności i uprawnień, czyli wdrażania skomplikowanych mechanizmów zarządzania jakością kodu.
Wydaje się tu być wskazanym wykorzystanie myśli normatywnej w zakresie oceny i doskonalenia procesów tworzenia oprogramowania. Najpopularniejsza na tym polu jest metodyka oceny promowana przez Software Engineering Institute (SEI) znana jako CMMI (Capability Maturity Model Integration). Wytyczne te mają odpowiedniki w normach ISO IEC - dawniej norma ISO IEC 15504 Information Technology - Software Process Assessement. Specyfikacja ta rozwijana jest od 1998 roku, a ostatnia jej edycja pochodzi z roku 2011 (ISOIEC 15504 - System and Software Engineering - System and Software Assurance). Norma ta jest szerzej znana jako SPICE - Software Process Improvement. Od 2013 roku ISO oraz IEC pracują nad nową rodziną norm - ISO IEC 3100x Information Technology - Process Assessment. Dla przemysłu samochodowego opracowano bardziej restrykcyjną normę znaną jako Automoto SPICE. W Polsce znana jest tylko certyfikacja na zgodność z wymaganiami CMMI, audyty ISO IEC 15504 nie były wykonywane.
Skutki błędów w kodzie oprogramowania mogą być ogromne. Nawet na pozór banalne niedociągnięcia mogą prowadzić do katastrofy. I to dosłownie. Jednym z najbardziej spektakularnych przykładów jest samozniszczenie rakiety Ariane 5, które miało miejsce 4 czerwca 1996 roku. Tego dnia z kosmodromu Kourou w Gujanie Francuskiej w swój pierwszy lot testowy wyruszyła europejska rakieta Ariane 5. Po 37 sekundach lotu rakieta zeszła z kursu i została zniszczona przez system autodestrukcji. Straty oszacowano na około 370 mln dolarów. Przed lotem próbnym przetestowano dokładnie cały sprzęt, ale nie wypróbowano oprogramowania. Było ono niemal w całości skopiowane z rakiety Ariane 4, gdzie działało bez zarzutów. Przyczynę tej decyzji podano w oficjalnym raporcie, który brzmiał następująco: "Panowało przekonanie, że nie byłoby wskazane dokonywanie zmian w softwarze, który tak dobrze funkcjonował w Ariane 4". W języku angielskim taką postawę określa się za pomocą idiomu: "Never touch a running system". Nikt nie wziął pod uwagę, że Ariane 5 miała szybsze silniki niż Ariane 4, przez co oprogramowanie generowało większe liczby. Błąd pojawił się, gdy 64-bitową zmienną zmiennoprzecinkową program próbował zamienić na 16-bitową zmienną całkowitą, co spowodowało nadmiar stałoprzecinkowy. Wskutek tego powstał efekt domina - pojawiła się seria sytuacji nieprzewidywalnych. W ich efekcie rakieta zeszła z kursu i nastąpiło zaprogramowane samozniszczenie rakiety. Zbliżona sytuacja miała miejsce w oprogramowaniu sterującym systemem obrony przeciwrakietowej podczas pierwszej wojny w Iraku (awaria antyrakiet Patriot).
W kontekście wielkich kodów znamienna jest statystyka liczby błędów na 1000 linii kodu (znana jako defect density). W książce "Code Complete" Steve McConnell (nieoficjalny podręcznik kodowania w standardach Microsoft) znajdują się estymacje: (a) Industry Average: około 15-50 błędów na 1000 linii dostarczonego kodu, (b) Aplikacje Microsoft: około 10-20 wad na 1000 linii kodu w wersjach testowych i 0,5 błędu na 1000 linii kodu w produkcie handlowym (źródło: http://www.pbm.com/~lindahl/real.programmers.html). Według Google statystyczna gęstość błędów jest na poziomie 0,02- 0,05, ale zdarza się też 5 lub 50 błędów na 100 linii kodu.
Wychodząc w przyszłość, konieczność zapewnienia jakości dla nowoczesnego wielkiego oprogramowania jest szansą dla Polskiego Towarzystwa Informatycznego, które mogłoby dostarczyć wyszkolonych i kompetentnych trenerów i audytorów dla tego obszaru.
