Verifica la qualità del codice [duplicato]

Elimina quello "sfondo" dalla tua testa - è inutile per il compito che hai.

Per entrambi i programmi, fare lo stesso: leggere il codice, file per file, riga per riga. Tutto ciò che non sembra giusto, aggiungilo all'elenco dei problemi. Errori di battitura, codice duplicato o morto, cose difficili da capire, avvisi IDE / compilatori, qualsiasi cosa. Utilizza i commenti gratuiti, non preoccuparti della struttura in questo momento, riempi la lista con quello che attira la tua attenzione.

Dopo aver finito con l'elenco, rivederlo. Ricontrolla se le tue note sono corrette. Se riesci a vedere una sorta di struttura / raggruppamento nei problemi che hai notato, riorganizza l'elenco per adattarlo. Invia l'elenco a chi ti ha chiesto di farlo.

^{In passato progetto, il mio collega è stato detto di rivedere un componente che mi è stato assegnato per mantenere, 5 o 10 K LOC se la memoria serve. Lo esaminò e presentò una lista di 180 articoli (notati centoottanta ). Una settimana più tardi, la gestione mi ha dato un pieno potere e un tempo illimitato per rielaborare quel componente. Ho trascorso circa un mese, indirizzato a tutti gli oggetti elencati dal ragazzo. Cinque anni di utilizzo intensivo che sono passati dopo la revisione, c'erano due o forse tre bug inviati contro questo componente.}

Per me la tua domanda sembra un "incolpevole gioco" .

Il problema riguarda davvero la qualità del codice dei due provider di codici o di più sulla descrizione dell'interfaccia tra i due?

Requisiti scritti o test unitari potrebbero aiutare a risolvere questo tipo di problemi in futuro:

• Quali sono input / output validi cosa non sono?
• Come deve essere eseguita la gestione degli errori?

Se il tuo compito non è quello di trovare i veri bug, ma come dici tu, basta misurare la qualità, quindi avrai bisogno di un modo per misurarlo.

In C questo è abbastanza facile, puoi semplicemente verificare quanto bene il codice è conforme a uno standard di codifica noto. L'autorità più conosciuta e riconosciuta è probabilmente MISRA-C , ma lì è anche CERT C . Entrambi possono essere utilizzati, sebbene il primo sia più adatto per i sistemi ad alta integrità e il secondo per la programmazione PC. Entrambi gli standard si concentrano sul divieto di pratiche pericolose.

Da tale standard di codifica puoi scegliere una serie di regole che dovrebbero far parte della recensione. Ad esempio, avrebbe molto senso includere tutte le regole MISRA-C che vietano l'affidamento su comportamenti non definiti. Di conseguenza, dovresti ottenere una serie di regole che possono essere utilizzate come mezzo per misurare la qualità.

Quindi viene la recensione effettiva. Avresti certamente bisogno di farlo manualmente, ma il modo professionale sarebbe quello di utilizzare anche uno strumento di analisi statica. Ce ne sono molti che supportano MISRA-C e alcuni che supportano CERT C. Gli strumenti più elaborati possono anche trovare vari altri bug, come anomalie dei dati, sovraccarichi del buffer, complessità inutile ecc. Possono anche eseguire la copertura del codice, per vedere se c'è del codice nel programma che non verrà mai eseguito.

Per quanto riguarda VB, è molto più difficile. Probabilmente non esiste un'autorità ampiamente riconosciuta che tu possa citare, sebbene ci siano forse degli standard di codifica che puoi usare, forse questo ? (trovato in Google, non l'ho mai usato). Microsoft sarebbe la migliore autorità per citare, sembrano avere alcune linee guida vaghe e superficiali su come scrivere VB, ma quelle non saranno affatto professionali come gli standard di codifica C.

Mi sembra che quello di cui hai veramente bisogno sia una strumentazione per sedersi tra le applicazioni e spiare quali messaggi si passano l'un l'altro (a seconda di come comunicano questo potrebbe essere qualcosa che hai bisogno di scrivere te stesso o qualcosa già disponibile come wireshark)

una volta che puoi vedere i messaggi puoi decidere chi ha ragione e chi è sbagliato rispetto alle specifiche dell'interfaccia. ovviamente è possibile che la specifica sia ambigua, nel qual caso è necessario correggere le specifiche (e possibilmente sostenere ulteriori costi per le modifiche a uno dei componenti) o convertire lo strumento di spionaggio in uno shim di compatibilità

rivedere il loro codice non è certamente privo di meriti ma non ti aiuterà a tracciare problemi di interfaccia (specialmente se la specifica è sbagliata)

(Per quanto riguarda il codice, immergiti - è l'unico modo per impararlo)

Suggerirei di avere un'API per le due parti su cui lavorare (un contratto essenzialmente). Se sono conformi all'API, il codice dovrebbe funzionare insieme.

Molto simile a come è fatto con un WSDL nel mondo dei servizi Web.

Se possibile, disponi di una suite di test sull'API in modo da poter vedere che roba funziona. Altrimenti puoi giocare a giochi di tag per anni.

Fare recensioni di codice in un modo accettabile per tutte le parti coinvolte è difficile. Un buon processo aiuterà, oltre a uno standard obiettivo, che insieme assicurano che la revisione sia verificabile e ripetibile. Inoltre, l'analisi e l'acquisizione dei fatti tecnici sono una, riportando in un modo che risolve la situazione problematica, compresa la gestione delle diverse prospettive, posizioni, sentimenti, è un'altra.

Ispezionare visivamente e fare un elenco di tutte le cose che non sono corrette con il codice è in genere solo una buona idea, non ci sono limiti di tempo e di budget o il codice base è veramente piccolo. Altrimenti, le ispezioni stesse potrebbero essere troppo lavoro, o le correzioni che suggerireste potrebbero richiedere troppo tempo per essere eseguite. Per favore, tienilo a mente quando vieni consigliato.

Quali domande di ricerca ha il tuo cliente per la revisione del codice e cosa verrà fatto con i risultati?

Dipende molto da ciò che vogliono e significa dalla qualità del codice.

Ma in generale, il tuo obiettivo sarebbe quello di dare una recensione di come il codice si adatta in termini di:

• facilità di manutenibilità ed estensibilità,
• stabilità e sicurezza,
• prestazioni.

Quasi la maggior parte delle metriche rientra in queste categorie di porte-manteau (in realtà, non considererei nemmeno le prestazioni in generale, e la considero il più delle volte come un effetto collaterale bonus di buoni punteggi in termini di stabilità e manutenibilità, quindi buona progettazione del codice).

Ci sono alcune cose più assolute da cercare, come le certificazioni di codice che possono essere applicate direttamente e misurate su alcune codebase, ma non forniscono necessariamente una revisione dettagliata di queste categorie.

Ti consiglierei:

• apri un IDE e inizia a sfogliare il codice,
• inserire i punti di interruzione per sapere cosa succede in fase di esecuzione e identificare interessanti preoccupazioni trasversali e importanti colli di bottiglia,
• trova alcuni controllori del codice e fa in modo che vengano violati dal flag e identifichino "hotspot" nella base di codice,
• eseguire alcuni profili sull'applicazione per identificare i colli di bottiglia,
• guarda anche gli strumenti utilizzati e la build del sistema (non quello che hanno chiesto direttamente, ma alcuni possono essere dedotti da quello, e può aiutare a identificare altri problemi),
• definisce il processo e le pratiche per poi iniziare a migliorare le metriche identificate e spiega in che modo ciò gioverà al codebase, agli sviluppatori e al prodotto finale.

So che hai taggato vb , ma solo per darti un esempio, Sonar sarebbe un buon esempio di uno strumento che può aiutare enormemente a quantificare la qualità di una base di codice in molti aspetti, dalla qualità del codice da un punto di vista tecnico o persino dal punto di vista del business, collegando (più o meno accuratamente) alcuni indicatori ai costi aziendali. Vuoi trovare uno strumento equivalente o una serie di strumenti che ti consentano di ottenere risultati simili nella tua zona. Sonar ha un plugin C, se vuoi, e sono abbastanza sicuro che Visual Studio ha alcuni analizzatori di buona qualità del codice integrati o esterni, per VB.

Quanto tempo ti è stato assegnato - a meno che l'ordine di grandezza non sia il 20% - il 50% del tempo di sviluppo per le app che stai rivedendo, stai sprecando il tuo tempo e compiendo un esercizio politico per far sentire bene qualcuno esso.

La maggior parte delle cose suggerite da cercare sono (anche se il migliore che conosciamo) un modo inaccurato per determinare la qualità del software, e molto improbabile che si registri su un esame rigoroso. Considera attentamente quello che scrivi nella tua relazione: potresti finire per doverlo difendere in una cassetta dei testimoni: fino a dove andrà questa disputa, e quanto denaro è in gioco, le parti che vogliono trovare una soluzione o una colpa?

Supponendo che tu sia un programmatore, non un analista forense con una specializzazione di programmazione (nel qual caso sapresti di non aver fatto questa domanda in un forum pubblico), se fossi in te rifiuterei l'incarico nel modo più strong poteva. Ti stai preparando a fare una caduta - vendendo i software contro l'altro con nient'altro che la tua opinione ..... Se uno di questi venditori trova questo Q & A, come ti farà sembrare ....

Prima di completare la segnalazione, è necessario essere certi di cosa verrà utilizzato. Assicurati che sia formulato con affermazioni come "appare" e "credo" piuttosto che assoluti come "il codice è schifo". Se devi fare affermazioni, sarà necessario fare riferimento agli standard pubblicati e ampiamente accettati. per esempio. "Il codice non soddisfa gli standard specificati nelle linee guida MISRA per C" è un dato di fatto, ma affermare che è dovrebbe soddisfare tali linee guida non sarebbe (a meno che il vostro contratto non lo abbia detto o hanno affermato di averlo fatto).

Tira un dado a 6 facce. 1-3 è il codice VB, 4-6 è il codice C. Prendi una vacanza di 2 mesi e di 'a tutti che il codice è cattivo dopo il tuo ritorno. Sei in una lotta politica che sembrerebbe.

O meglio ancora, digli che stai andando a rivedere il codice, ma non farlo. Torna con correzioni di lavoro a entrambi i set di codice che consentono loro di lavorare insieme.