Dovrei essere disturbato se il mio rapporto LOC / giorno è troppo alto? [chiuso]

Attualmente sto lavorando a un progetto indipendente, quindi non ho esattamente il lusso di test umani o revisioni di codici esterni, tuttavia non vedo alcun bug difficile nel mio codice corrente (li aggiusto come li vedo e la maggior parte delle volte sono solo nomi di campi sbagliati e cose del genere, cose che risolvi in ​​un minuto o due), e lo collaudo dopo aver implementato qualsiasi funzione prima di inviarlo. Ultimamente il mio numero LOC era di circa 400 al giorno (per la cronaca, è C #), e non sto solo implementando nuovi sistemi, ma riscrivo anche cose che ho già scritto e risolto alcuni bug.

Dovrei essere disturbato? È il segno che devo interrompere e rivedere tutto il codice che ho scritto fino a questa data e rifattorizzarlo?

LOC è probabilmente una delle metriche più abusate e, di conseguenza, è probabilmente una delle misure più inutili della qualità del codice e una misurazione ancora più inutile dello sforzo di programmazione.

Sì, questa è un'affermazione audace per me da fare, e no, non posso indicarti studi che dimostrano il mio punto. Tuttavia, posso affermare con la dura esperienza acquisita che quando inizi a preoccuparti della quantità di codice che hai scritto, probabilmente ti preoccupi dei problemi sbagliati.

Devi prima chiederti cosa stai cercando di misurare o provare e se questa prova è semplicemente per interesse o per supportare un miglioramento della qualità più ampio e dove è necessario utilizzare queste informazioni per ottenere il buy-in dal tuo team / gestione per fare qualcosa al riguardo.

Una delle cose per le quali tendo ad usare LOC è un po 'un controllo di sanità mentale. Se mi ritrovo a scrivere molto codice, divento più interessato a LOC per metodo o LOC per classe, piuttosto che LOC su tutti. Queste misurazioni potrebbero essere indicatori che è necessario eseguire ulteriori refactoring se si avverte un leggero disturbo ossessivo compulsivo su quanto dovrebbe essere ben ponderato il codice. Le classi molto grandi potrebbero dover essere rifattorizzate in alcune classi più piccole, e potrebbe essere necessario suddividere i metodi multilinea lunghi in diversi metodi, altre classi, o potrebbe persino indicare una ripetizione che potrebbe essere rimossa. Si noti che ho usato la parola "potrebbe" più volte lì.

La realtà è che LOC fornisce solo un possibile indicatore e nessuna reale garanzia che il codice potrebbe dover cambiare. La vera domanda da porsi è se il codice si comporta come richiesto e come previsto. In tal caso, la tua prossima domanda è se sarai in grado di mantenere facilmente il codice e se avrai il tempo, ora o in futuro, di apportare modifiche al codice di lavoro per ridurre le spese generali di manutenzione in futuro.

Spesso, un sacco di codice significa che avrai più da mantenere in seguito, ma a volte anche un codice ben ponderato può estendersi a centinaia di righe di codice, e sì, a volte puoi ritrovarti a scrivere centinaia di righe di codice in un giorno. L'esperienza tuttavia mi dice che se sto sostenendo un output di centinaia di righe di nuovo codice ogni giorno, che spesso c'è il rischio che gran parte del codice sia stato tagliato e incollato in modo inappropriato da qualche altra parte e che di per sé possa indicare problemi con duplicazione e manutenzione, ma ancora una volta non è una garanzia, quindi tendo a fare affidamento su ciò che la mia esperienza e il mio istinto mi dicono in base a come sono stati completati i compiti da svolgere.

Il modo migliore per evitare il dilemma posto nella tua domanda IMHO è quello di dimenticare LOC e fare il refactor TUTTO il tempo. Scrivi prima il test del codice, implementalo per fallire, refactor per passare, poi vedi cosa può essere refactored lì e poi per migliorare il codice. Lascerai il compito sapendo che hai già ricontrollato il tuo lavoro e non sarai così preoccupato di ripensarti in futuro. Realisticamente parlando, se usi un approccio test-first come ho descritto, qualsiasi misurazione LOC / day sul tuo codice completato significherà davvero che hai scritto 3-5 volte l'importo misurato, con quello sforzo nascosto con successo dal tuo refactoring in corso sforzi.

Niente affatto - alcuni giorni stai risolvendo un bug difficile da trovare e cambiando solo una riga. Altri giorni stai aggiungendo un nuovo codice e scrivi diverse migliaia di righe.

Il LOC giornaliero non ti dice nulla tranne che le attività per quel giorno potrebbero essere eseguite con 400 righe di codice.

Ad alcune di queste risposte manca il punto, non stai usando LOC come misura della produttività (se lo fossi allora non ti preoccuperesti di essere troppo 'produttivo'), quello che stai effettivamente facendo è preoccuparti della qualità del tuo codice perché il codice è il nemico, questa è una buona cosa di cui preoccuparsi.

Sfortunatamente, l'unico modo per conoscere la qualità del codice è la revisione del codice, poiché sei un team unico, questo sarà difficile, anche se ti fermi a rivedere il tuo codice (e non vuoi davvero smettere, giusto?) il proprio codice non rivelerà tanto quanto un peer che sta esaminando il tuo codice. Ti suggerirei di provare a chiedere a qualcun altro di rivedere almeno un po 'del tuo codice in modo da poter capire se il tuo 400 LOC / day sta producendo in modo incomprensibile o meno. Anche una revisione indipendente del codice di un giorno aiuterà qui

Non dovresti preoccuparti del numero di LOC che produci al giorno.

Ma dovresti essere disturbato:

• se il tuo codice non è testato (se ad esempio non hai test unitari)
• se inizi a riscontrare problemi nell'aggiungere nuove funzionalità o modificare le funzionalità implementate (ciò significa che il refactoring non è corretto)
• se la tua esperienza non è grande e il tuo codice non viene esaminato (è probabile che un paio di occhi in più rilevi i problemi)

LOC è una misura "ufficiale" della produttività, ma gli argomenti a sfavore del suo valore potrebbero essere lunghi (un ORM potrebbe generare 50.000 righe di codice in 3 minuti, tuttavia, se la progettazione del database è errata, tutto quel codice potrebbe andare nel cestino).

Ti suggerisco di misurare i tuoi progressi monitorando% attività completate vs tempo vs.% attività pianificate per essere completate. Questo è ciò che conta. I clienti pagano per il codice di lavoro che fornisce valore commerciale non per i LOC.

Alcuni riferimenti su LOC

• Contro: LOC-Misura più insignificante

• Neutro in una certa misura: Wiki-LOC

• Pro (non sono d'accordo con la maggior parte, ma puoi dare un'occhiata): Diseconomie di scala e linee di codice

Stai misurando anche il numero di duplicati di codice ?

Se l'output elevato è perché hai un sacco di copia e incolla nel tuo codice, dovresti preoccuparti.

Motivo: nel caso in cui si sia verificato un errore nella copia e incolla-sorgente è difficile e soggetto a errori correggere tutti gli usi della copia e incolla

Se credi nel bellissimo codice funzionale, questa dovrebbe essere la tua unica misura

"Scorre? Sembra bello?"