Od kdy je bugzilla měřítkem kvality projektu?
1) Netestuju vůbec -> 0 bug reportů -> HQ software.
2) Přepísknu to s testováním a dám code review akademickýmu pedantovi, najednou tam mám 5k bugů typu "uzavírací závorka funkce v modulu XYZ na řádku 123 nemá být odsazená". Z toho reálných je třeba jenom 50.
3) Pokud bugzillu používám i na návrhy vylepšení od zákazníků a zákazníci navrhují blbosti, tak ty blbosti zdůvodním a zavřu. Přece není bug, když třeba u pluginu - dekodéru formátu X bude někdo požadovat funkcionalitu na dekódování formátu Y a vysvětlím mu, že to už řeší jiný plugin a stačí, aby si ho instaloval... Pokud to nedělám, stane se z toho blob, který umí všechno a nic dobře.
Ohledně LOC, taky metrika trochu mimo. Příklad, projekt v C, psaný dle doporučení uncle Boba (průměr 5 řádků v těle funkce, počítejme jeden blok (cyklus nebo if) uvnitř funkce, 1000 funkcí v 50 modulech, každá funkce má prototyp.
1) Jak je to formátováno? Pokud dám styl K&R (s otvírací složenou závorkou na konci řádku), mám 8 kLOC, pokud otvírací závorku odřádkuju, mám 10 kLOC (jeden řádek je hlavička, jeden řádek mezera mezi funkcema).
2) Počítají se do toho komentáře? Pokud jo, tak ejenom hlavička souboru, kde je datum, copyright a stručný popis modulu na 20 řádků, udělá z 10 kLOC 11 kLOC (+ 50*20LOC)
3) Jak jsou odděleny funkce? Někdo mezi ně dává grafický předěl za dvou řádků komentářových hvězdiček a mezi tím název funkce, prázdný řádek pod. Z 11 kLOC je najednou 15 kLOC
4) Jestli je tam dokumentace v Doxygenu, tak na funkci vychází třeba 8 LOC dokumentace funkce + 50 LOC na modul, tak je z 15 kLOC najednou 25,5 kLOC.
5) A to se furt bavíme o tom samým kódu 1:1, jenom s různým formátováním a dokumentací. 8 nebo 25,5, to je trojnásobek! Co když třeba to samý místo bloku if-else s odřádkováním závorek (8 LOC) udělám přiřazením v ternárním operátoru na 1 LOC?
Prostě zase debata o hnědým mazlavým. Nemáte tam jinou metriku? Třeba usability skóre?
144 Odpovědí
41892 Zhlédnutí