Evoluzione degli standard di codifica, come li gestisci?

Come gestite l'evoluzione degli standard di codifica / la guida di stile in un progetto per la base di codice esistente? Supponiamo che qualcuno nel tuo team abbia scoperto un modo migliore di creare istanze di oggetti nel linguaggio di programmazione. Non è che il vecchio modo sia cattivo o difettoso, è solo che il nuovo modo è meno prolisso e sembra molto più elegante. E a tutti i membri del team piace davvero. Cambieresti tutto il codice esistente?

Supponiamo che la tua base di codice sia di circa 500.000 righe di codice. Vuoi ancora cambiare tutto il codice esistente? O lasceresti che il nuovo codice aderisca solo al nuovo standard? Fondamentalmente perdere coerenza?

Come gestisci un'evoluzione degli standard di codifica nel tuo progetto?

Esistono standard di codifica per rendere i team più produttivi. In teoria, rendono il codice più semplice da comprendere, modificare e testare. In pratica, possono creare una pericolosa quantità di meta-lavoro; i team riscrivono ripetutamente il codice esistente alla ricerca della soluzione più corretta ed elegante. Sfortunatamente, il problema del meta-lavoro sembra peggiore nei team in cui tutti sono coinvolti, appassionati e ossessionati dal fare la cosa giusta.

Come consulente che passa da un progetto all'altro, ho scoperto che un'eccellente disciplina con un rigido standard di codifica contribuisce molto meno al successo di un progetto rispetto agli eccellenti sviluppatori interessati ai risultati. Gli stili di codifica incoerenti sono una seccatura minore per gli sviluppatori straordinari. Sono produttivi con o senza coerenza. Certo, se incontrano un codice incoerente, chiederanno della correntestandard e attenersi ad esso. Tuttavia, non insisteranno sull'aggiornamento di ogni riga di codice nel progetto allo standard attuale. Non insistono perché hanno visto le migliori pratiche che vanno e vengono. Il modo corretto di fare qualcosa oggi non è lo stesso del modo corretto di fare qualcosa domani. Se lo fosse, i tuoi standard di codifica non si evolverebbero. Quindi, se il modo corretto di fare qualcosa cambia con il tempo, forse la nostra definizione di "corretto" è rotta.

Questo non vuol dire che gli standard non contano. Basta tenere presente che l'obiettivo degli standard è la produttività. Se non riesci a garantire che la riscrittura secondo un nuovo standard si ripagherà da sola a lungo termine, allora non perdere tempo. È molto più semplice giustificare un nuovo standard nel codice nuovo o refactored. L'eleganza è fantastica ma non è la stessa cosa dei risultati.

Quello che facciamo è l'evoluzione (non rivoluzione) anche per la base di codice, quando useremmo lo standard aggiornato;

• viene scritto un nuovo codice
• il codice è refactored
• i bug sono stati corretti
• nuove porzioni vengono aggiunte a una classe esistente

È importante che la tua base di codice sia coerente, quindi se la modifica apre una possibilità di confusione tra il codice di stile "vecchio" e "nuovo", potrebbe essere meglio riservare l'aggiornamento del tuo standard di codifica al prossimo progetto.

Prima di tutto, non includerei tali "migliori pratiche" nelle linee guida di codifica (parte obbligatoria). Potrebbero essere menzionati, per esempio in appendice, come un esempio di come si possa fare qualcosa, ma non che dovrebbe essere fatto in questo modo.

Detto questo, ci sono due casi da considerare per le modifiche a uno standard di codifica:

1. Modifiche che non influiscono sulla leggibilità, anche se il vecchio e il nuovo codice vengono mescolati senza aggiornare il vecchio codice.
   Queste modifiche possono essere aggiunte immediatamente allo standard di codifica e devono essere considerate valide per tutto il codice nuovo e modificato. Il vecchio codice dovrebbe essere adattato progressivamente quando il tempo lo consente e mentre vengono apportate modifiche in quell'area.
   Un esempio di questo tipo di modifica, che ho effettivamente riscontrato, è una modifica della dichiarazione sul copyright all'inizio di ogni file.
2. Modifiche che deteriorano la leggibilità se si mescolano codice vecchio e nuovo.
   Queste modifiche dovrebbero essere applicate all'intera base di codice in una volta sola o dovrebbero essere riconsiderate se sono realmente necessarie.
   Un esempio di questo tipo di cambiamento è un cambio di rientro o inserimento di parentesi graffe.

Questo deve davvero dipendere dal tipo di prodotto che stai creando:

• Per un'applicazione commerciale scritta internamente e distribuita ai clienti, l'obiettivo principale dovrebbe essere rappresentato dalle entrate. Finché il vecchio codice non è difettoso, non importa se i nuovi standard di codifica si sono evoluti, dovresti concentrarti sull'aggiunta di nuove funzionalità al tuo prodotto e sulla generazione di entrate. Ad ogni modo, adattare i nuovi standard di codifica per il nuovo codice, ma cambiare tutto il codice esistente sarebbe una perdita di tempo.
• Se stai sviluppando un prodotto open source o un prodotto in cui più aziende (forse anche i tuoi clienti) vedranno e lavoreranno sul sorgente, la leggibilità del codice diventa molto più importante e in questo caso, una decisione ragionevole dovrebbe essere presa in base esattamente quanto codice deve essere modificato e quali saranno i vantaggi a lungo termine. Sebbene a tutti noi piaccia il bel codice, la realtà è che per una società commerciale che si occupa di sistemi chiusi, l'adattamento costante di nuovi standard comporterà la perdita di entrate a lungo termine.

Personalmente, opterei per mantenere i vecchi codici così come sono, e seguire i nuovi standard da qualunque cosa tu faccia. Più specificamente, non userò i doppi standard in old.c. Ma se ho intenzione di creare new.c, può usare le sintassi più recenti e raffinate :)