KLOC (ang. Kilo Lines Of Code) to bardzo stara miara złożoności programów na podstawie liczby linii kodu. Z pewnością ma wiele wad, bo jak porównywać kod w C/C++ z kodem w Java czy C#. Czy jako linie kody powinno liczyć się komentarze lub importy przestrzeni nazw, co z kodem generowanym automatycznie itd. Wszystko to prawda, ale osobiście uważam, że ta miara jednak coś mówi. Ostatnio natknąłem się na bardzo ciekawe dane dotyczące liczby błędów/KLOC.
W książce Code Complete Steve McConnell pisze, że średnia wynosi 15-50 błędów/KLOC dla produkcyjnego kodu (jak dla mnie dużo), a Microsoft osiąga podobno wynik 0.5 błędów na tysiąc linii produkcyjnego kodu. W publikacji Number of faults per line of code Myron Lipow cytuje zbliżone wyniki, czyli 5 do 30 błędów/KLOC. Metoda Cleanroom software engineering opracowana przez IBM pozwoliła osiągnąć w niektórych projektach dużo lepsze wyniki. W projektach prowadzonych przez NASA osiągnięto natomiast oszałamiający wynik zero błędów na 500 tysięcy linii kodu. Czemu się jednak dziwić. Na stronie The Flight of STS-1 można znaleźć informację, że NASA wydawała 1000$ na wyprodukowanie jednej linii kodu!!!, podczas gdy średnia przemysłowa na tamte czasy to 50$.
Źródła jakie zacytowałem są dość albo nawet bardzo stare. Sądzę jednak, że współczesne systemy są coraz bardziej skomplikowane i nawet pomimo zastosowania nowoczesnych narzędzi i techniki wyniki będą podobne. Według prezentacji ThoughtWorks z 2007 średnia liczba błędów na tysiąc linii kodu to 5 przy średnim koszcie wyprodukowania jednej linii kodu 5$ (wliczając testy, dokumentację itd.). NASA płaci natomiast 850$ za linię aby obniżyć współczynnik do 0.004 błędów/KLOC.
Pracowałem przy projekcie, w którym udało się uzyskać bardzo dobry wynik 0.23 błędów/KLOC przy czym dużo zmian zostało wprowadzonych przez stworzone przez zespół narzędzia do automatycznej modyfikacji kodu. Jestem ciekawy Waszych opinii na temat tej miary? Jaki wynik uważacie za dobry?
W książce Code Complete Steve McConnell pisze, że średnia wynosi 15-50 błędów/KLOC dla produkcyjnego kodu (jak dla mnie dużo), a Microsoft osiąga podobno wynik 0.5 błędów na tysiąc linii produkcyjnego kodu. W publikacji Number of faults per line of code Myron Lipow cytuje zbliżone wyniki, czyli 5 do 30 błędów/KLOC. Metoda Cleanroom software engineering opracowana przez IBM pozwoliła osiągnąć w niektórych projektach dużo lepsze wyniki. W projektach prowadzonych przez NASA osiągnięto natomiast oszałamiający wynik zero błędów na 500 tysięcy linii kodu. Czemu się jednak dziwić. Na stronie The Flight of STS-1 można znaleźć informację, że NASA wydawała 1000$ na wyprodukowanie jednej linii kodu!!!, podczas gdy średnia przemysłowa na tamte czasy to 50$.
Źródła jakie zacytowałem są dość albo nawet bardzo stare. Sądzę jednak, że współczesne systemy są coraz bardziej skomplikowane i nawet pomimo zastosowania nowoczesnych narzędzi i techniki wyniki będą podobne. Według prezentacji ThoughtWorks z 2007 średnia liczba błędów na tysiąc linii kodu to 5 przy średnim koszcie wyprodukowania jednej linii kodu 5$ (wliczając testy, dokumentację itd.). NASA płaci natomiast 850$ za linię aby obniżyć współczynnik do 0.004 błędów/KLOC.
Pracowałem przy projekcie, w którym udało się uzyskać bardzo dobry wynik 0.23 błędów/KLOC przy czym dużo zmian zostało wprowadzonych przez stworzone przez zespół narzędzia do automatycznej modyfikacji kodu. Jestem ciekawy Waszych opinii na temat tej miary? Jaki wynik uważacie za dobry?
orcid.org/0000-0002-6838-2135
5 comments:
A jak są liczone błędy w kodzie?
Błąd czyli niezgodność z wymaganiami, może to być nieobsłużony wyjątek, błąd w obliczeniach, czy zły wygląd interfejsu użytkownika itd. Ja podałem wyniki dla kodu produkcyjnego czyli w tym przypadku były to błędy zgłoszone przez klientów.
A ja jestem na nie. Tego typu statystyki nie pomagają, a mogą wręcz zaszkodzić. OK, ja naprawdę jestem uprzedzony do zbierania statystyk z kodu. Statystyka LOC jest zupełnie oderwana od tego co się dzieje rzeczywiście.
Powiedzmy, że ktoś by mi dał zadanie programistyczne i jako funkcję celu podał coś w stylu błędów/KLOC. Gdyby to brać na serio to napisałbym (znalazł w necie i przystosował) generatory kodu specyficzne dla domeny. Trzymałbym sobie jedno repozytorium z moim kodem oraz jedno z kodem wygenerowanym pokazywanym w firmie. Czy to moja wina, że ktoś źle ustawił funkcję celu? Każdy wskaźnik można nagiąć. Tak w praktyce to szybko z takich firm trzeba uciekać :)
Taaa, jestem hejterem traktowania ludzi jako resource'ów piszących KLOC, rozwiązujących taski na ilość, poprawiających bug na ilość, itd, itp.
Spoko Michał, że o tym piszesz - mogłem wyrazić niezadowolenie :)
Ciekawy komentarz, ale będę z nim polemizował. Metryki takie jak błędy/KLOC nie powinny być oczywiście celem samym w sobie, ale są przydatne. Nie w każdej firmie, w dużych bardziej niż w małych, ale są. Do czego? Żeby móc oceniać proces wytwarzania oprogramowania. Załóżmy, że do tego procesu zostały wprowadzone jakieś zmiany, struktura firmy zmieniła się itd. W jaki sposób ocenić, że są to zmiany na dobre?
Miary różnego rodzaju mogą być tutaj bardzo pomocne. Przy czym zaznaczam, nie tylko one. Nie można patrzeć tylko na liczby, trzeba je interpretować biorąc pod uwagę specyficzne uwarunkowania w danej firmie, projekcie, zespole itd. No i oczywiście rozmawiać z ludźmi.
Statystyka ma to do siebie, że w DŁUGIM terminie się jej nie oszuka. Jeśli dana miara przez dłuższy czas utrzymywała się na danym poziomie X. To jeśli w pewnym momencie zanotowano dużo gorszy wynik Y to trzeba odpowiedzieć na pytanie czemu tak się stało.
"Tak w praktyce to szybko z takich firm trzeba uciekać :)"
Przekornie zapytam. A nie chciałbyś wziąć udziału w projekcie prowadzonym przez IBM dla NASA. To właśnie ze względu na wyśrubowane wymagania koszt wytworzenia był tak wysoki. Ale z tego co wiem nie zauważono żadnego błędu w oprogramowaniu w czasie misji wahadłowców, dla których zostało ono napisane.
"Statystyka ma to do siebie, że w DŁUGIM terminie się jej nie oszuka." - to jest racja na pierwszy rzut oka i to jest zaleta. Problem jest w tym, że jeśli ludzie na których robimy statystykę, wiedzą o tym, to zachowują się inaczej. Nie pomoże, że ludzi będzie DUŻO, a statystyka będzie miała DŁUGI termin. Każda z tych osób będzie na swój sposób się dostosowywać.
Czy jest coś złego w tym żeby, będąc ocenianym za podstawie zamkniętych tasków w Jirze, starać się zamykać taski? Następnym krokiem jest zamykanie tasków, które jeszcze nie powinny być zamknięte... Już wiesz do czego dążę. Dla każdego wygląda to inaczej, ale coś takiego jest.
A czy w projekcie dla NASA error/KLOC był brany jako miara jakości? Takie rzeczy można sobie liczyć, ale nie koniecznie brać je pod uwagę. Np mój ostatni projekt miał X KLOC i Y bugów w Jirze. Statystycznie więc X/Y error/KLOC. To nie znaczy że braliśmy to pod uwagę gdy pisaliśmy projekt. Statystyki wziąłem już. Krytyce poddałem nie same (może hobbystyczne) zbieranie i porównywanie takiej statystyki, ale kierowanie się takową podczas developmentu.
Post a Comment