Ty nie.
Jakość oprogramowania jest naprawdę trudna do obiektywnego zmierzenia. Na tyle trudne, że nie ma rozwiązania. W tej odpowiedzi nie zastanawiam się, czy w ogóle można znaleźć rozwiązanie, ale po prostu wskazuję, dlaczego zdefiniowanie takiego rozwiązania byłoby naprawdę trudne.
Uzasadnienie według status quo
Jak zauważył Kilian Foth, gdyby istniał prosty sposób na „dobre” oprogramowanie, wszyscy byśmy go używali i wszyscy by tego wymagali.
Są projekty, w których menedżerowie zdecydowali się na egzekwowanie określonych wskaźników. Czasami działało, czasem nie. Nie znam żadnych istotnych korelacji. Szczególnie krytyczne oprogramowanie systemowe (np. Samoloty, samochody itp.) Ma wiele wymagań metrycznych w celu „zapewnienia” jakości SW - nie jestem świadomy żadnych badań wskazujących, że wymagania te faktycznie prowadzą do wyższej jakości, i mam osobiste doświadczenia z przeciwnie.
Uzasadnienie kontrwywiadu
Również wskazany przez Kiliana i bardziej ogólnie wyrażony jako „każda metryka może i będzie odtwarzana”.
Co to znaczy grać w metrykę? To zabawna gra dla programistów: zapewniasz, że wartości metryk wyglądają naprawdę dobrze, a robisz naprawdę gówniane rzeczy.
Powiedzmy, że mierzysz wady według LOC. Jak mam w to zagrać? Łatwe - wystarczy dodać więcej kodu! Stwórz głupi kod, który spowoduje brak operacji na 100 liniach i nagle będziesz mieć mniej defektów na LOC. A co najważniejsze: w ten sposób obniżyłeś jakość oprogramowania.
Braki w narzędziach są nadużywane, definicje są rozciągnięte do maksimum, wymyślane są zupełnie nowe sposoby. Zasadniczo programiści są naprawdę inteligentnymi ludźmi i jeśli masz tylko jednego programistę w zespole, który dobrze się bawi, to Twoje dane będą wątpliwe.
Nie oznacza to, że wskaźniki są zawsze złe - ale nastawienie zespołu do tych wskaźników ma kluczowe znaczenie. W szczególności oznacza to, że nie będzie działać dobrze w przypadku relacji podwykonawcy / zewnętrznego dostawcy.
Rozumowanie przez nieprawidłowe kierowanie
To, co chcesz zmierzyć, to jakość oprogramowania. Mierzysz jeden lub więcej wskaźników.
Istnieje różnica między tym, co mierzysz, a tym, co według ciebie to powie. Ta luka jest nawet ogromna.
Zdarza się to cały czas w różnego rodzaju firmach wokół nas. Widziałeś kiedyś decyzje oparte na KPI (kluczowe wskaźniki wydajności)? To tylko ten sam problem - chcesz, aby firma dobrze sobie radziła, ale mierzysz coś innego.
Uzasadnienie według kwantyfikowalności
Metryki można zmierzyć. To jedyny powód, dla którego sobie z nimi radzimy. Jakość oprogramowania wykracza jednak daleko poza te mierzalne jednostki i ma wiele trudnych do oszacowania: jak czytelny jest kod źródłowy? Jak rozbudowywalny jest twój projekt? Jak trudno jest nowym członkom zespołu wejść na pokład? itd itd.
Ocena jakości oprogramowania tylko na podstawie wskaźników i przymykanie oka na te części jakości, których nie da się określić ilościowo, z pewnością nie zadziała dobrze.
edytować:
streszczenie
Zaznaczę, że powyższe dotyczy obiektywnego oceniania, czy oprogramowanie jest dobre, czy złe na podstawie wskaźników. Oznacza to, że nie mówi nic o tym, czy i kiedy należy zastosować wskaźniki.
W rzeczywistości jest to jednokierunkowa implikacja: złe metryki oznaczają zły kod. Jednokierunkowy oznacza, że zły kod nie gwarantuje złych danych, ani dobre dane nie gwarantują dobrego kodu. Z drugiej strony, to samo w sobie oznacza, że możesz zastosować metryki, aby ocenić oprogramowanie - jeśli pamiętasz o tych implikacjach.
Mierzysz oprogramowanie A, a wskaźniki okazują się naprawdę złe. Możesz być pewien, że jakość kodu jest zła. Mierzysz oprogramowanie B, a wskaźniki są w porządku, więc nie masz pojęcia o jakości kodu. Nie daj się zwieść myśleniu „metryka dobra = kod dobry”, gdy tak naprawdę jest to po prostu „kod dobry => metryka dobry”.
Zasadniczo możesz używać wskaźników do znajdowania problemów z jakością, ale nie samej jakości.
