Come discutere contro l'abbassamento degli standard di qualità per la base di codice legacy? [chiuso]

Abbiamo qui una grande base di codice legacy con codice errato che non puoi immaginare.

Abbiamo definito ora alcuni standard di qualità e desideriamo soddisfarli in una base di codice completamente nuova, ma anche se tocchi il codice legacy.

E facciamo rispettare quelli con Sonar (strumento di analisi del codice), che ha già alcune migliaia di violazioni.

Ora è iniziata la discussione per ridurre quelle violazioni per l'eredità. Perché è eredità.

La discussione riguarda le regole di leggibilità. Ad esempio quanti if nidificati / per .. può avere.

Ora, come posso argomentare contro la riduzione della nostra qualità di codifica sul codice legacy?

Il codice è solo un mezzo per raggiungere un fine. Ciò che potrebbe essere tale fine varia, ma in genere è il profitto.

Se è profitto; quindi discutere con successo tutto ciò che si desidera dimostrare che migliorerà il profitto, ad esempio aumentando le vendite, riducendo i costi di manutenzione, riducendo i costi di sviluppo, riducendo i salari, riducendo i costi di riqualificazione, ecc. Se non è possibile / non dimostrare che lo farà migliorare il profitto; poi per lo più stai solo dicendo che sarebbe un modo divertente per buttare i soldi in bagno.

Io e me siamo stati produttori e manutentori del codice legacy. Se il tuo strumento sta generando "migliaia di violazioni" (o addirittura centinaia per quella materia), dimentica lo strumento, è inapplicabile alla situazione ...

Presumo che gli sviluppatori originali siano spariti da tempo e non siano disponibili per la discussione. Quindi non c'è nessuno che capisca perché e perché del design e dello stile di programmazione. Correggere centinaia o migliaia di violazioni non sarà una questione di riscrivere alcune righe di codice qua e là. Invece, senza dubbio richiede refactoring / ri-funzionale-decomposizione. Provi a farlo con qualsiasi base di codice esistente di grandi dimensioni, senza comprenderne intimamente il design attuale e sei obbligato a presentare una nuova serie di bug / problemi / ecc. Solo una nuova lattina di worm anche peggio di quella che hai ora (o peggio del tuo strumento >> pensa << ora hai).

L'unico approccio ragionevole per affrontare "migliaia di violazioni" sarebbe quello di riscrivere da zero. Uno sforzo lungo e costoso, e quasi impossibile da vendere alla direzione. E in questo caso probabilmente hanno ragione ...

Il codice legacy in genere richiede solo modifiche. Come per y2k, o quando le scorte sono passate dai 256 ° al decimale. Ho fatto un sacco di entrambi quei cr * p. E molte altre cose simili. In genere è piuttosto "preciso" in quanto è possibile "leggere" lo stile a volte cattivo, cattiva decomposizione funzionale, cattivo ecc, e individuare la raccolta di luoghi che devono essere modificati. E poi, ciò che accade "tra quei luoghi", cioè qual è il flusso di più alto livello, può rimanere un mistero per te. Assicurati solo di comprendere la funzionalità localizzata che stai modificando, quindi verifica, verifica, verifica eventuali effetti collaterali, ecc., Le tue conoscenze localizzate non saranno in grado di anticipare.

Se non riesci a vedere il codice come quello, allora potresti non essere la persona migliore per mantenere il codice legacy. Alcune persone possono iniziare con uno schermo vuoto e scrivere bellissimi programmi, ma non possono iniziare con una grande base di codice del codice di altre persone e mantenerlo. Altre persone possono mantenere il codice, ma non possono ricominciare da capo. Alcuni possono fare entrambe le cose. Assicurati che le persone giuste mantengano il tuo codice legacy.

Le volte occasionali in cui potresti voler riprogettare e riscrivere la tua base di codice legacy da zero è quando i requisiti aziendali (o di altro tipo) cambiano in misura tale che i "ritocchi" del posto di lavoro non riescono più a soddisfare i requisiti modificati . E a quel punto, potresti anche iniziare scrivendo un nuovo documento sui requisiti funzionali in primo luogo, assicurandoti che tutte le parti interessate siano a bordo. È fondamentalmente un gioco di baseball completamente nuovo.

L'unica cosa >> sbagliata << cosa da fare è provare a trattare la manutenzione del codice legacy nello stesso modo in cui andresti per il nuovo sviluppo. E quella cosa sbagliata sembra essere esattamente il percorso che vorresti percorrere :) Prendi la mia parola, non è quello che vuoi fare.

La domanda non è quanto sia buono o cattivo quel codice. La domanda è: quanti benefici ottieni da quanti investimenti.

Quindi hai uno strumento che trova migliaia di cose che non gli piacciono. Puoi scegliere di ignorare i risultati dello strumento o di investire lavoro per cambiare migliaia di cose. Sono molte cose. Le persone non saranno concentrate, non mentre effettuano le modifiche, né durante la loro revisione, e questo non sarà testato correttamente perché ci vogliono anni per capire come testare (o semplicemente provare) ogni cambiamento, quindi ci saranno bug. Quindi fino a quando non hai trovato e risolto questi bug, hai investito molto tempo e denaro con un risultato complessivamente negativo.

D'altra parte, gli strumenti possono trovare cose che non solo "non piacciono", ma che sono bug o potenziali bug. Se il codice legacy è ancora ampiamente utilizzato, lo strumento giusto può effettivamente trovare bug. Pertanto, può essere utile attivare gli avvisi del compilatore uno alla volta, verificando se sono utili (non tutti utili) e correggendo tali avvisi.

Se non è rotto, non aggiustarlo

Questo dovrebbe praticamente essere tatuato su ogni sviluppatore e manager di software in modo che non lo dimentichino mai.

Sì, infrange tutte le convenzioni di codifica moderne. Sì, è scritto in FORTRAN-77 con un wrapper in C, quindi può essere invocato da Python. Sì, quelli sono GOTO non strutturati. Sì, c'è una subroutine lunga tremila righe. Sì, i nomi delle variabili hanno senso solo per un croato. ecc ecc.

Ma se è stato testato con rabbia per oltre un decennio o più ed è passato, lascialo in pace! Se la modifica necessaria è piccola, mantenerla il più piccola e il più locale possibile. Qualsiasi altra cosa corre il rischio maggiore di rompere qualcosa che non ha bisogno di essere riparato.

Certo, a volte scopri che è davvero un kluge non mantenibile e che l'unico modo per soddisfare la "piccola" modifica è riscrivere da zero. Nel qual caso devi tornare da chiunque chieda il cambiamento e dirgli quanto costerà (sia in dollari o ore-uomo per la riscrittura, sia nel sudore del sangue e nelle lacrime per gli inevitabili nuovi bug).

Molto tempo fa si è verificata un'eruzione di guasti di una delle unità disco di Digital. Hanno finito per ricordare e rimpiazzarli tutti su gord sa quanto costa. Apparentemente c'era una goccia di colla che conteneva un filtro all'interno dell'HDA. Il manifesto dell'ingegneria ha detto della colla "Non parametricamente specificato, SENZA SOSTITUTI ACCETTABILI". Un bean-counter "salvato" sotto un centesimo per unità disco acquistando altra colla. Ha emesso un vapore all'interno dell'HDA che ha ucciso l'unità dopo un paio d'anni in servizio. Non è stato rotto fino a quando non l'ha riparato. Senza dubbio "è stato solo un piccolo cambiamento ..."

Non ha assolutamente senso ridurre il livello di qualità per il codice legacy. Non è inoltre necessario correggere immediatamente gli avvisi. Assicurati solo che tutte le tue "nuove" modifiche in ogni componente del tuo progetto stiano seguendo standard di alta qualità. Cioè nessun commit dovrebbe mai aumentare il conteggio degli avvisi.

È un approccio semplice uniforme e morto.

Permette al vecchio codice legacy di funzionare così com'è (perché non vengono apportate modifiche non necessarie). Assicura che il nuovo codice sia di alta qualità. Non sono previsti costi aggiuntivi.

Controllo del rischio ...

• Il codice nella base di codice legacy di grandi dimensioni è stato testato almeno dall'utilizzo reale del software.
• Non è molto gradito che il codice nella base di codice legacy di grandi dimensioni sia coperto da test di unità automatizzati.
• Quindi qualsiasi modifica al freddo nella base di codice legacy di grandi dimensioni è ad alto rischio.

Costo….

• Fare in modo che il codice passi un controllo del codice mentre lo scrivi è economico
• Farlo in un secondo momento è molto più costoso

Beneficiare

• Speri che il rispetto di standard di codifica porti a una migliore progettazione del codice.

• Ma è molto improbabile che avere qualcuno che trascorra molte settimane a cambiare codice solo per rimuovere avvisi da uno strumento di controllo standard di codifica, comporterà un miglioramento del design del codice.

• Il codice semplice è più chiaro e tende a essere più facile da capire, a meno che il codice complesso non sia diviso in metodi brevi da qualcuno che non lo capisce….

Raccomandazione….

• Se viene mostrato che una sezione di codice contiene molti bug o ha bisogno di molte modifiche per aggiungere funzioni aggiuntive, dedica il 100% del tempo a capire cosa fa.
• Passa anche il tempo ad aggiungere un buon test unitario a quella sezione di codice, poiché ne hai una comprovata necessità.
• Potresti quindi prendere in considerazione il refactoring del codice (ora capisci) in modo che passi anche il nuovo controllo del codice.

Esperienza personale ...

• In altri 20 anni di lavoro come programmatore, non ho mai visto un caso in cui cambiare ciecamente vecchi per rimuovere tutto l'output da un nuovo controllore standard di codifica ha avuto alcun beneficio oltre all'aumento del reddito degli appaltatori che sono stati incaricati di farlo.
• Allo stesso modo, quando è necessario creare il vecchio codice per superare le revisioni del codice (TickIt / ISO 9001 errate) che richiedono che il vecchio codice assomigli al nuovo standard di codifica.
• Ho visto molti casi in cui l'utilizzo degli strumenti di controllo standard di codifica su un nuovo codice ha avuto grandi vantaggi riducendo i costi continui.
• Non ho mai visto un'azienda fallire nei costi di mantenimento del vecchio codice utilizzato in un prodotto con molti clienti.
• Ho visto la compagnia fallire a causa del mancato guadagno dei clienti essendo troppo lento sul mercato….

La discussione sull'abbassamento delle soglie dello strumento? ... o l'ho frainteso. È scritto in modo confuso. In caso contrario, scartare la mia risposta.

IMHO sarebbe una buona idea ridurre la sensibilità dello strumento. Perché? Perché metterebbe in evidenza i pezzi di codice più pelosi. L'alternativa sta producendo segnalazioni con migliaia di violazioni, diventando inutili per le sue dimensioni.

... a parte questo, basta parlarne con le persone coinvolte e scoprire anche le loro ragioni.

Vorrei provare a separare il codice legacy dal nuovo codice pulito. Ad esempio, Eclipse potresti farlo inserendoli in diversi progetti che si usano a vicenda. progetto "pulito" e progetto "legacy" .

In questo modo è possibile analizzare entrambi i progetti nel sonar con diversi standard di qualità. Gli standard dovrebbero differire solo nell'importanza delle regole. Le stesse regole dovrebbero essere le stesse. In questo modo è possibile vedere nel progetto "legacy" ciò che deve essere "riparato" per soddisfare gli standard del progetto "pulito" .

Ogni volta che sei riuscito a portare un codice legacy a standard più elevati, puoi spostarlo nel progetto "pulito".

Nel lavoro quotidiano non puoi realizzare di elevare ogni classe che tocchi agli standard del progetto "pulito" a causa del ritardo del tempo. Ma dovresti provare ad arrivarci a piccoli passi cercando di migliorare un po 'il codice legacy ogni volta che lo tocchi.