Come argomentare contro l'abbassamento degli standard di qualità per il codebase legacy? [chiuso]

Il codice è solo un mezzo per raggiungere un fine. Che fine potrebbe essere varia, ma in genere è un profitto.

Se è un profitto; quindi per discutere con successo di tutto ciò che vuoi dimostrare che migliorerà il profitto - ad es. aumentando le vendite, riducendo i costi di manutenzione, riducendo i costi di sviluppo, riducendo i salari, riducendo i costi di riqualificazione, ecc. Se non puoi / non dimostri che migliorerà il profitto; quindi stai solo dicendo che sarebbe un modo divertente per buttare soldi nel water.

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

Presumo che gli sviluppatori originali siano lontani e non disponibili per la discussione. Quindi nessuno è in giro che capisca il perché e il perché dello stile di progettazione e di codifica. Correggere centinaia o migliaia di violazioni non sarà questione di riscrivere poche righe di codice qua e là. Invece, richiede indubbiamente il refactoring / re-functional-decomposition. Provi a farlo a qualsiasi grande base di codice esistente, senza capire a fondo il suo attuale design, e sei tenuto a introdurre un nuovo set di bug / problemi / ecc. Solo un nuovo barattolo di vermi è ancora peggiore di quello 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 ...

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

Se non riesci a vedere la tua strada attraverso un codice del genere, allora potresti non essere la persona migliore per mantenere il codice legacy. Alcune persone possono iniziare con una schermata vuota e scrivere programmi belli, ma non possono iniziare con una grande base di codice del codice di altre persone e mantenerla. Altre persone possono mantenere il codice, ma non possono iniziare da zero. Alcuni possono fare entrambi. Assicurati che le persone giuste mantengano il tuo codice legacy.

Le volte occasionali che potresti voler riprogettare e riscrivere da zero il tuo codice di base legacy è quando i requisiti aziendali (o di altro tipo) cambiano a tal punto che i "ritocchi" dei posti non possono essere modificati requisiti più a lungo. E a quel punto, potresti anche iniziare scrivendo un nuovo documento sui requisiti funzionali, assicurandoti che tutte le parti interessate siano a bordo. È fondamentalmente un gioco completamente nuovo.

Il one-and-only > > wrong < < la cosa da fare è provare a considerare la manutenzione del codice legacy nello stesso modo in cui avresti fatto per il nuovo sviluppo. E quella cosa sbagliata sembra essere esattamente la strada che vorresti andare giù :) Credimi, non è quello che vuoi fare.

La domanda non è quanto sia buono o cattivo quel codice. La domanda è quanto beneficio si ottiene da quanto investimento.

Quindi hai uno strumento che trova migliaia di cose che non gli piacciono. Hai la possibilità di ignorare i risultati dello strumento o di investire il lavoro per cambiare migliaia di cose. Sono molte cose. Le persone non saranno focalizzate, non mentre apportano le modifiche, non mentre le esaminano, e questo non sarà testato correttamente perché ci vogliono secoli per capire come testare (o solo per provare) ogni cambiamento, quindi ci saranno dei bug. Quindi, fino a quando non hai trovato e corretto questi bug, hai investito molto tempo e denaro con il risultato complessivo negativo.

D'altro canto, 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. Quindi, attivare gli avvisi del compilatore uno alla volta, controllando se sono utili (non tutti sono utili) e la correzione di questi avvisi può essere utile.

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ì, rompe tutte le moderne convenzioni di codifica. Sì, è scritto in FORTRAN-77 con un wrapper in C, quindi può essere richiamato 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, lascia stare! Se la modifica richiesta è piccola, mantienila più piccola e locale possibile. Qualunque altra cosa corre il rischio maggiore di rompere qualcosa che non ha bisogno di essere riparato.

Certo, a volte si scopre che è davvero un kluge irrinunciabile e che l'unico modo per accontentare la "piccola" modifica è riscrivere da zero. Nel qual caso devi tornare da chiunque chieda il resto e dirgli quanto costerà (sia in dollari che in man-ore per la riscrittura, e con sangue sudato e lacrime per gli inevitabili nuovi bug).

Molto tempo fa ci fu un'eruzione di guasti di una delle unità disco di Digital. Hanno finito per ricordare e sostituire tutti a Gord sa quale costo. Apparentemente c'era un blob di colla che conteneva un filtro all'interno dell'HDA. Il manifesto tecnico ha detto della colla "Non specificata parametricamente, NESSUN SOSTITUTO ACCETTABILE". 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 di servizio. Non è stato rotto fino a quando non ha riparato. Senza dubbio "era solo un piccolo cambiamento ..."

Non è assolutamente necessario ridurre il livello di qualità del codice legacy. Non è inoltre necessario correggere gli avvertimenti immediatamente. Assicurati solo che tutti i tuoi "nuovi" cambiamenti in ogni componente del tuo progetto seguano standard di alta qualità. Cioè nessun commit dovrebbe aumentare il numero di avvisi mai.

È un approccio uniforme e semplice e semplice.

Permette al vecchio codice legacy di funzionare così com'è (perché non vengono apportate modifiche inutili). 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 per l'utilizzo reale del software.
• È molto poco chiaro che il codice nella base di codice legacy di grandi dimensioni sia coperto da test di unità automatizzati.
• Quindi eventuali modifiche al freddo nella base di codice legacy di grandi dimensioni sono ad alto rischio.

Costo ....

• Rendere il codice passare un controllore del codice mentre stai scrivendo il codice è economico
• Farlo in un secondo momento è molto più costoso

Benefit

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

• Ma è molto improbabile che avere qualcuno che spende molte settimane per cambiare codice solo per rimuovere gli avvisi da uno strumento di verifica 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 venga diviso in metodi brevi da qualcuno che non lo capisce ....

Raccomandazione ....

• Se viene mostrata una sezione di codice che contiene molti bug o richiede molte modifiche per aggiungere funzioni aggiuntive, dedica il tempo al 100% a capire cosa fa.
• Passa anche il tempo aggiungendo un buon test unitario a quella sezione di codice, poiché ne hai una comprovata necessità.
• Potresti quindi prendere in considerazione la possibilità di refactoring del codice (ora lo capisci), così ha passato anche il nuovo controllo del codice.

Esperienza personale ....

• In altri 20 anni di lavoro come programmatore, non ho mai visto un caso in cui ciecamente cambiando vecchio per rimuovere tutta l'uscita da un nuovo correttore standard di codifica ha avuto qualche beneficio oltre ad aumentare il reddito degli appaltatori che sono stati istruiti a fare così.
• Allo stesso modo quando deve essere fatto un vecchio codice per passare le recensioni del codice (TickIt / ISO 9001 fatto male) che richiedeva che il vecchio codice assomigliasse al nuovo standard di codifica.
• Ho visto molti casi in cui l'utilizzo degli strumenti di controllo standard di codifica sul nuovo codice ha avuto grandi benefici riducendo i costi correnti.
• Non ho mai visto un'azienda fallire i costi di mantenimento del vecchio codice utilizzato in un prodotto con molti clienti.
• Ho visto fallire l'azienda a causa del mancato guadagno da parte dei clienti essendo troppo lento sul mercato ....

La discussione sull'abbassare le soglie dello strumento? ... o l'ho frainteso È scritto in modo confuso. Se non lo è, per favore scarta la mia risposta.

IMHO sarebbe una buona idea ridurre la sensibilità dello strumento. Perché? Perché evidenzierebbe i pezzi di codice più pelosi. L'alternativa è produrre report con migliaia di violazioni, diventando inutili per le sue dimensioni.

... a parte questo, parla solo con le persone coinvolte e ascolta anche le loro ragioni.

Vorrei provare a separare il codice legacy dal nuovo codice pulito. Ad es. Eclipse puoi farlo inserendoli in diversi progetti che si usano l'un l'altro. progetto "pulito" e "legacy" .

In questo modo è possibile analizzare entrambi i progetti in sonar con diversi standard di qualità. Gli standard dovrebbero differire solo per l'importanza delle regole. Le regole stesse dovrebbero essere le stesse. In questo modo puoi vedere in progetto "legacy" che cosa deve essere "fissato" per soddisfare gli standard del 'clean'-project .

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

Nel lavoro di tutti i giorni non è possibile ottenere risultati per sollevare ogni classe che si tocca con gli standard del progetto "pulito" a causa del lasso di tempo. Ma dovresti provare ad arrivarci in piccoli passi cercando di migliorare il codice legacy un po 'ogni volta che lo tocchi.