Utilizzare la guida di stile aziendale o cercare di far corrispondere i file sorgente errati? [duplicare]

Per prima cosa, dici che al momento ci sono due squadre che lavorano nel codice, quindi la risposta ovvia è "chiedi a chi è responsabile". Non ha senso fare lo sforzo di adattare il codice agli stili aziendali se anche gli altri team non tentano di adattarlo.

Se eri da solo a mantenere il codice vecchio di altre persone, probabilmente la maggior parte del tempo ne modifichi solo una piccola parte (ci sono parti di un IS che cambiano più di altre). Lì, vorrei andare in questo modo:

1. Prima di tutto, rendilo visibile. Parla con il tuo capo e chiedigli cosa fare; spiegagli che a volte durerai un po 'più a lungo, ma a lungo termine sarà redditizio. Deciderà se gli importa di più a breve o lungo termine.

2. Non farti risucchiare in un completo refactoring! Una buona regola empirica limita le modifiche ai metodi / classi che sono stati modificati come parte delle modifiche al sistema. Se devi eseguire modifiche "secondarie" a causa del refactoring (ad esempio, modificando l'altra classe perché hai cambiato il nome di un metodo a causa del refactoring), apporta le modifiche secondarie ma non tocchi più nulla.

3. Pulisci le parti dell'applicazione che modifichi prima. Non c'è bisogno di modificare il codice che "funziona" e nessuno leggerà di nuovo.

4. Dopo aver apportato le modifiche funzionali e prima di eseguire la pulizia, esegui un commit nel caso qualcosa vada storto (parentesi non corrispondenti, ecc.).

5. (Se il tempo di ricostruzione è sufficientemente basso) Se apporti modifiche che riguardano altre parti del codice (nome di classi o metodi), apporta le modifiche, ricompila il sistema e decidi se la modifica vale la pena di cambiare tutte quelle errore "simbolo non trovato".

6. Attenzione all'eredità! Ricorda che se modifichi un metodo in una classe, forse non ci sono errori symbol not found perché il compilatore sta usando l'implementazione della classe genitore di quel metodo!

Penso che dipenda da molti fattori sociali. Per uno, influisce anche su di te o sulla tua posizione se non aderisci alla guida di stile? Dopo tutto, un sacco di codice è stato scritto da altri con questa guida già in atto. Se non ti influenza veramente, vuoi (per qualsiasi ragione) voler sostenere la guida allo stile?

La maggior parte delle volte, ho scoperto che una volta che una guida di stile veniva ignorata da uno o più team senza gravi ripercussioni, allora la guida potrebbe anche essere rimossa. Semplicemente non è sufficiente scrivere un documento che spieghi la guida allo stile, bisogna anche applicarlo.

Quindi, qui è presente una questione più fondamentale: la guida allo stile della tua azienda ha ancora sostenitori e perché non l'hanno applicata?

Puoi pensarci al contrario: non ti saresti nemmeno preoccupato di questa domanda, se il tuo capo ti ha detto che deve scrivere qualsiasi codice per tutti i progetti in corrispondenza di questa guida di stile. Apparentemente, però, hai dei dubbi sull'applicabilità della guida.

In sintesi, cosa puoi fare? Considerato quanto sopra, ci sono alcuni modi possibili, ma alla fine spetta a voi scegliere:

1. Ignora completamente la guida allo stile, perché anche tutti gli altri lo fanno e, in effetti, non è più pertinente.

2. Applica in silenzio la guida di stile alle tue modifiche e, se qualcuno si lamenta, punta semplicemente alla guida. Non stai facendo nulla di sbagliato, ma non stai facendo molto di più del minimo.

3. Sostieni la guida allo stile. Risolve il problema che questo codice ha ignorato la guida e che questo fatto di per sé è un problema che dovrebbe essere affrontato. Fai sentire la tua voce e fai parte del gruppo che applica effettivamente la guida allo stile, perché ritieni che sia importante.

4. Sfida la guida allo stile. Quasi come sopra, ma non sei d'accordo con la guida e vuoi liberartene.

La conformità alla guida di stile è importante, ma se non si dispone delle risorse necessarie per adattare l'intero codice base allo standard su carta, potrebbe creare più disordine di quanto non rimuova. In generale, non riformatterei meno di un intero file semplicemente per conformarmi a qualsiasi standard, e solo se non è chiaramente una proposizione negativa sul valore del business (cioè costa più di guadagnerà mai in produttività).

Se tutto il codice è in uno stile coerente, o se il codice base è molto grande, o se non c'è budget, allora scelgo le battaglie che posso vincere e mi adattare all'altro stile.

Se non sono l'unica persona che sta lavorando attivamente al progetto, parlerei con gli altri sviluppatori e raggiungo un accordo condiviso.

Vorrei puntare a scrivere tutto il nuovo codice seguendo le guide. Qualsiasi linea che tocco dovrebbe seguire la guida di stile, ma non mischiare i commit dove cambio la logica in una riga e solo lo stile in un'altra parte del codice. Rende il processo di revisione molto noioso e confuso.

Se ho alcune vittorie facili (come trovare / sostituire), vorrei coordinarmi con il team che lavora attivamente sul codice e applicarle in blocco, quindi inviare una richiesta di pull contenente solo quelle modifiche. Questo dovrebbe essere unito al più presto, o potrei finire con tonnellate di conflitti.