So che molti disprezzano il KLOC perché alcuni manager tentano di correlarlo con la produttività. Ma quando parliamo solo confrontando le dimensioni dei progetti usando gli stessi linguaggi e gli stessi standard di codifica, nonché lo stesso strumento per il calcolo LOC. A differenza dei punti storia, questo sembra un modo più ragionevole per confrontare le dimensioni di due progetti.
La risposta a questa domanda dipenderà dagli standard di codifica. Più sono rigidi, meno variazioni ci possono essere nel codice prodotto da due sviluppatori, quindi più vicino sarà il conteggio KLOC per la stessa soluzione di persone diverse.
Ma supponiamo che tu lavori per un'azienda che non impone ogni minimo dettaglio e consente un certo grado di auto-espressione durante la scrittura del codice. Per fare un esempio, considera i seguenti due modi di scrivere un metodo in C # per il gioco fizzbuzz:
Versione 1
IList<string> GenerateFizzBuzzList()
{
var fizzBuzz = new List<string>();
for (var i = 1; i <= 100; i++)
{
var entry = "";
if (i % 3 == 0)
{
entry += "Fizz";
}
if (i % 5 == 0)
{
entry += "Buzz";
}
if (entry == "")
{
entry = i.ToString();
}
fizzBuzz.Add(entry);
}
return fizzBuzz;
}
Versione 2
IList<string> GenerateFizzBuzzList()
{
var fizzes = Cycle("", "", "Fizz");
var buzzes = Cycle("", "", "", "", "Buzz");
var words = fizzes.Zip(buzzes, (f, b) => f + b);
var numbers = Range(1, 100);
return numbers.Zip(words, (n, w) => w == "" ? n.ToString() : w).ToList();
}
Entrambe le soluzioni sono scritte nella stessa lingua (C #). Entrambe le soluzioni seguono le stesse regole sull'assegnazione di nomi, il layout della controventatura e varie altre convenzioni (es. Usando var ) che sono comuni negli standard di codifica. Eppure la versione 1 è quasi tre volte la dimensione della versione 2.
Ridimensiona questi due approcci fino a un'app moderatamente grande e potremmo avere 80.000 linee in un progetto e 220.000 in un altro. Ma quella differenza di linea di 140.000 è semplicemente dovuta all'approccio adottato, piuttosto che perché uno fa più dell'altro. KLOC può solo dirti le dimensioni comparative della funzionalità se per ogni progetto viene adottato esattamente lo stesso approccio alla scrittura del codice. In realtà, esattamente lo stesso approccio è usato solo da sviluppatori di scarsa qualità che non imparano mai nuove tecniche e modi di esprimere il codice, cioè in realtà KLOC è solo una misura del numero di linee di codice. Non misura nient'altro, quindi non serve a provare a misurare qualcos'altro.
KLOC è una misura neutrale della dimensione del codice, proprio come i chilometri sono una misura neutrale della distanza.
E proprio come KLOC, i chilometri non sono molto utili: un numero maggiore di km non garantisce che il viaggio sia più piacevole, più piacevole o più turistico. Anche i chilometri sono un cattivo predittore: non ti dicono quanto tempo ci vorrà per raggiungere l'obiettivo, né la quantità di carburante necessaria.
Tuttavia, i chilometri sono ancora l'unità di misura principale per la distanza. E certamente per ragioni simili, KLOC è ancora in uso per la misurazione delle dimensioni.
KLOC è un (molto) cattivo indicatore di produttività : la scrittura di una bella classe / funzione riutilizzabile e manutenibile può portare a un codice molto più piccolo, che a copiare / incollare / modificare e ripetere per sempre. Ma il codice più breve nello stesso tempo può sembrare meno produttivo, anche se a lungo andare è il contrario, dal momento che è necessario codificare meno grazie al riutilizzo, e sarà necessario testare di meno, come si può fare affidamento su già testati componenti.
Ma KLOC è una misura valida delle dimensioni . Come ogni unità di misura, presenta alcune carenze: non tutte le linee hanno la stessa complessità, e il layout e lo stile possono influenzare la quantità. Ma con un po 'di normalizzazione (come ignorare le linee vuote e le righe di commento, o applicare qualche bella stampa per neutralizzare le differenze di stile), su una base di codice estesa, avrà un significato statistico.
La dimensione misura solo una quantità. Può influenzare il tempo di compilazione o la revisione del tempo. È utilizzato nelle controversie sulla proprietà intellettuale, per misurare il grado di somiglianza tra due diversi codici sorgente. Ma non aspettatevi che sia un buon predittore di tempo, sforzo o complessità (10 privilegi di codice ricorsivo sono ancora più complessi di 50 linee di sillabazioni sequenziali).
I punti storia sono soggettivi per la squadra che ha fatto la valutazione: non puoi sapere per certo se questa metrica corrisponde alle dimensioni o allo sforzo.
Ci sono anche punti funzione che mirano a una maggiore obiettività. Ma questi non sono prontamente disponibili dal codice e richiedono un'analisi costosa con anche qualche spazio per l'interpretazione (anche se meno che con i punti della trama). Non sono nemmeno sicuro che siano ancora rilevanti in un mondo OO con GUI.
I punti storia e i punti funzione sono comunque stime dei requisiti e delle caratteristiche previste. Vengono valutati prima della scrittura del codice e, in generale, non verranno aggiornati se appaiono imprecisi. Possono dare un'idea della complessità, ma non della dimensione del codice che verrà prodotto.
Il problema con LoC per la stima è che non sai in anticipo quante righe conterrà il codice finale.
In termini di post misura della complessità e dimensione di un progetto è buono come qualsiasi altra misura.
Supponendo che le persone abbiano uno stile di codifica a cui generalmente si attengono e una velocità alla quale generalmente scrivono. Allora sì, puoi guardare indietro al codice che hanno scritto e vedere quali compiti sono stati facili e quali sono stati difficili dal LoC finale e il tempo impiegato dallo sviluppatore per scriverli rispetto alla loro velocità media.
Questo non ti aiuta molto a stimare il lavoro futuro però.
Stai confondendo due cose completamente diverse qui.
I manager si preoccupano della funzionalità , perché è quello che il marketing ha venduto. Non si preoccupano affatto delle dimensioni del progetto tranne che come indicatore della completezza della funzionalità. È un indicatore molto, molto debole, e solo i cattivi manager fanno affidamento su di esso se c'è qualcosa di meglio disponibile, ma succede.
I programmatori si preoccupano delle dimensioni del progetto perché questo determina quanto sia difficile gestire il codice base. Non si preoccupano (principalmente) delle funzionalità, tranne nella misura in cui questo è ciò che paga i loro assegni. A differenza dei gestori, i programmatori preferirebbero preferire una base di codice più piccola, a parità di altre condizioni.
Ciò significa che le due situazioni non sono affatto paragonabili. KLOC è una misura utile per giudicare le dimensioni del progetto e una misura davvero inutile per giudicare la completezza o la produttività. Non c'è contraddizione qui.
Leggi altre domande sui tag estimation metrics loc