Come convincere la gestione che la riformattazione l'intera base di codice Java è sicuro

https://stackoverflow.com/questions/2420174

19-09-2019
|

Domanda

Come si potrebbe fare per dimostrare al management che un riformattare lotto di tutti i file .java in una grande base di codice (per posizionare il codice in conformità con gli standard di codifica della società) è sicuro e non compromette la funzionalità.

Le risposte dovrebbero placare la non tecnico e l'egualmente tecnico.

Modifica: 2010-03-12 Chiarimento per il tecnico fra voi; riformattare spazio-only = bianco cambia - "riordino delle variabili membro, metodi, ecc" no "importazioni organizzazione" o

Modifica: 2010-03-12 Grazie per le numerose risposte. Sono una sorpresa che così tanti dei lettori hanno votato fino risposta di mrjoltcola poiché è semplicemente una dichiarazione circa di essere paranoico e in nessun modo si propone una risposta alla mia domanda. Inoltre, c'è anche un commento dallo stesso contribuente ribadendo la questione. WizzardOfOdds distaccati questo punto di vista (ma non si può avere leggere tutti i commenti per vederlo). -jtsampson

Modifica: 2010-03-12 Io posto la mia risposta personale a breve, anche se la risposta di John Skeet era proprio sulla soldi con il suggerimento MD5 (nota -g: nessuno per attivare il debug off). Anche se copriva solo gli aspetti tecnici. -jtsampson

2010-03-15 Ho aggiunto la mia risposta qui sotto. In risposta a ciò che significa "sicuro" significa, volevo dire che la funzionalità del codice Java non ne risentirebbe. Un semplice studio del compilatore Java mostra che questo sia il caso (con alcune precisazioni). caveat Thos erano "solo spazio bianco" e sono stati segnalati da diversi manifesti. Tuttavia questo non è qualcosa che si desidera cercare di spiegare a BizOps. Il mio obiettivo era quello di conoscere "come giustificare fare questo" tipo di risposte e ho avuto alcuni grandi risposte.

Diverse persone menzionate controllo del codice sorgente e il "divertimento" che va di pari passo con essa. In particolare mi non ha menzionato che, come tale situazione sia già ben compreso (nel mio contesto). Attenzione l'effetto "stazione di servizio". Vedere la mia risposta qui sotto.

Soluzione

Se si tratta solo di riformattazione, quindi che non dovrebbe cambiare l'output del compilatore. Prendere un hash ( MD5 dovrebbe essere abbastanza buono) della generazione prima e dopo la riformattazione - se è lo stesso per ogni file, il che significa chiaramente che non può aver alterato il comportamento. Non c'è alcuna necessità di eseguire test, ecc - se l'uscita è byte per byte lo stesso, è difficile vedere come i test avrebbero cominciato fallendo. (Naturalmente potrebbe essere utile eseguire i test solo per lo spettacolo di esso, ma non hanno intenzione di dimostrare niente che i binari identici non lo faranno.)

EDIT: Come sottolineato nei commenti, i file binari contengono numeri di riga. Assicurarsi che si compila con -g:none omettere informazioni di debug. Questo dovrebbe quindi essere a posto con la linea numerazione modifiche -. Ma se stai cambiando nomi questo è un cambiamento più serio, e uno che potrebbe effettivamente essere un cambiamento di rottura

Sto assumendo che possono riformattare e ricostruire senza che nessuno preoccuparsi - solo controllando il codice riformattato di nuovo in controllo del codice sorgente dovrebbe dare ogni caso di preoccupazione. Non pensare file di classe Java hanno nulla in esse, che dà una data di realizzazione, ecc Tuttavia, se il "formattazione" cambia l'ordine dei campi, ecc, che possono avere un effetto significativo.

Altri suggerimenti

In un ambiente aziendale, avete due sfide.

Tecnico
Politica

Dal punto di vista tecnico, reformatters sono una tecnologia matura. In combinazione con hashing / checksum, fino a quando la lingua non è uno spazio sensibile, si è tecnicamente sicuro di fare questo. Anche voi volete fare in modo di farlo nel corso di un tempo di inattività in cui grosse forcelle sono in attesa di essere uniti. I veri cambiamenti saranno impossibile separare dalla riformattazione, in modo da fare separatamente. Fusione può essere molto difficile per chiunque lavori su una forcella. Infine, vorrei fare solo dopo che ho implementato una copertura completa di test case. A causa della ragione 2 ...

Politicamente, se non si sa come convincere la gestione, come fai a sapere che è sicuro? Più in particolare è sicuro per voi. Per un anziano, sviluppatore ben fidato-, che è in controllo dei processi in un negozio, si tratta di un lavoro più facile, ma per uno sviluppatore che lavora in una grande, politica, organizzazione rosso-registrato, è necessario assicurarsi di coprire tutta la vostra basi.

L'argomento che ho fatto nel 2010 è stato un po 'troppo intelligente, forse, ma parser, reformatters, stampanti belle sono solo software; essi possono avere bug innescati da codebase, soprattutto se si tratta di C ++. Senza unit test ovunque, con una grande base di codice, potrebbe non essere in grado di verificare il 100% che il risultato finale è identico.

Come sviluppatore, sono paranoico, e l'idea mi mette a disagio, ma fino a quando si sta utilizzando:

Fonte di controllo
Una corretta copertura di test

allora sei OK.

Tuttavia, riflettere questo: Gestione è ormai consapevole del fatto che si sta gingillarsi in un progetto da un milione di linea con un "cambiamento di massa". Un bug in precedenza sconosciuto viene segnalato dopo riformattare. Si è ora principale sospettato per aver causato questo bug. Che si tratti di "sicuro" ha molteplici significati. Potrebbe non essere sicuro per voi e il vostro lavoro.

Questo suona banale, ma un paio di anni fa mi ricordo qualcosa di simile accada. Abbiamo avuto una segnalazione di bug venire in un giorno dopo una finestra di manutenzione notte in cui avevo fatto solo una riconfigurazione e il riavvio di un server IIS . Per diversi giorni, la storia era che devo aver avvitato, o implementato il nuovo codice. Nessuno ha detto che direttamente, ma ho ottenuto lo sguardo da un VP che ha detto così. Abbiamo finalmente rintracciarlo a un bug che era già in codice, era stato spinto in precedenza, ma non ha mostrato fino a quando una persona QA era cambiato un banco di prova di recente, ma onestamente, alcune persone non ricordo nemmeno quella parte; essi basta ricordare in arrivo il giorno successivo per un nuovo bug.

EDIT: In risposta a . La tua domanda non era su come farlo; è stato "Come convincere la gestione che è sicuro". Forse si dovrebbe avere chiesto, invece, "è sicuro? Se è così, come farlo, in modo sicuro." La mia dichiarazione è stata sottolineando l'ironia della sua domanda, in quanto si presume che fosse sicuro, senza sapere come. Apprezzo il lato tecnico della riformattazione, ma sto sottolineando che non v'è rischio coinvolti in qualcosa di non banale e se non si mette la persona giusta su di esso, si potrebbe ottenere muck up. Sarà questo compito sminuire altri compiti programmatori, li sidetracking per un paio di giorni? Sarà in conflitto con le revisioni non impegnate di qualche altro coder? È la fonte in fase di revisione a tutti? C'è qualche script incorporato che è uno spazio sensibili, come Python ? Tutto può avere un inaspettato effetto collaterale; per il nostro ambiente, sarebbe difficile ottenere una finestra di tempo in cui non c'è qualcuno che lavora su un ramo, e riformattazione di massa sta per rendere la loro fusione piuttosto brutto. Da qui la mia avversione per mass-riformattazione, a mano o automatica.

Utilizzare un approccio pragmatico:

L'applicazione.
Salvare l'applicazione.
Riformattare il codice.
L'applicazione.
Diff i binari.

Vorrei usare quattro parole.

Controllo del codice sorgente. Unit test.

Beh, non è affatto sicuro e si è improbabile per convincerli. Parlando come qualcuno che ha gestito un sacco di sviluppo non avrei mai prendere in considerazione in alcun codebase commerciale su cui eventuali entrate dipendeva. Non sto dicendo che non ci sono vantaggi a codice formattato come si vuole, ma le probabilità che la formattazione non comporterà alcune modifiche di codice è pari a zero. Questo significa che c'è un enorme rischio per molto poco guadagno. Se dovete farlo, farlo frammentario come bug fix il codice, non farlo in un grande successo. Può essere una buona decisione per voi come i programmatori, ma sarebbe una decisione terribile per loro come la gestione.

Cosa gestione stiamo parlando qui? Sono tech-savvy abbastanza per capire la formattazione del codice che cosa è e come Java gestisce gli spazi? Perché se non lo sono, non credo che siano qualificati per prendere una decisione così tecnico (vale a dire, queste domande dovrebbero essere delegate a qualcuno che è responsabile per il codice).

Ma se sono o si stanno cercando di convincere il vostro "architetto" o qualcuno simile, beh, allora si tratta di fidarsi di uno strumento di terze parti. Suggerisci un formattatore che ha una buona reputazione, diverso da quello che non è molto che si può fare, dal momento che non ha codificato il formattatore.

Come pista laterale, mi permetta di condividere un aneddoto. Il nostro architetto ha deciso in un momento di riformattare tutti i file. Fuori di migliaia di file Java, è stata ancora trovata, non un solo errore (e questo era oltre la metà di un anno fa). Questo mi fa fido formattatore di Eclipse per il codice sorgente di Java. I vantaggi di questo formattazione sono stati:

Alcune classi mal formattati sono ora più facili da leggere.
stessa formattazione in tutto il mondo.

Ma ha avuto anche alcuni lati negativi:

in codice non è perfetto. A volte il codice formattato manualmente legge meglio. Il formattatore in particolare lotte con davvero male il codice (linee troppo lunghe, troppi se e nidificati, ecc).
Hai altri rami di codice, come una vecchia versione che ogni tanto ha bisogno di una patch? Poiché è possibile dimenticare la fusione tra i rami con stili di codice diversi (almeno quando si utilizza SVN).
si sta toccando tutti i file (e, talvolta, quasi ogni riga) e rovinando la storia di tutti i file in una sola volta. Mi fa male la tracciabilità.
V'è in realtà un piccolo beneficio dal fatto che ogni sviluppatore ha la sua formattazione del codice, perché si inizia l'apprendimento che la formattazione, e si può immediatamente identificare l'autore di un pezzo di codice

Personalmente penso che il negativo supera il positivo. Suona come una grande idea, ma in realtà non si guadagna tanto quanto si pensi. Quando vi imbattete in un codice terribilmente formattato, formattare solo quella classe o solo quel metodo e vedere come un piccolo passo verso il grande obiettivo.

fare il test di unità passano dopo la riformattazione? Se è così, allora hai venduto l'idea di gestione!

Se stai gingillarsi con il codice non testato, allora avrete un caso molto più difficile da fare.

Si desidera che il "Codice in conformità con gli standard di codifica della società" [sic] e vuole convincere l'amministrazione?

Trivial: install CheckStyle , lo rendono parte del processo, dargli da mangiare le vostre linee guida di codifica, e mostrare loro che l'intera base di codice miseramente NON sul CheckStyle .

Questo è un buon esempio della mancata corrispondenza tecnico-commerciale.

Il popolo tecnici vogliono farlo perché può rendere il codice difficile da leggere, ma, a meno che non si tratta di eccezionalmente male, il vero motivo è che offende la sensibilità tipicamente delicati e estetica del programmatore medio .

Gli uomini d'affari vogliono gestire il rischio. Il rischio può essere intrapreso se c'è qualche vantaggio e non v'è alcuna attività beneficio qui a meno che sostengono che sarà più economico, più veloce e / o meno rischioso per fare lo sviluppo futuro con il codice sorgente riformattato, che in tutta l'onestà è una vendita dura.

Quasi per definizione qualsiasi cambiamento è rischio connesso. Il rischio qui è remota, ma non è inesistente o (dal punto di vista della direzione) quasi senza testa.

C'è un altro aspetto da considerare troppo: questo tipo di cambiamento può svolgere il caos con controllo del codice sorgente. Diventa più difficile tenere traccia di chi ha cambiato cosa perché la più recente modifica a qualsiasi linea sarà la riformattazione quindi avrai bisogno di andare a confronto le revisioni, il che è un po 'più noioso di un semplice "colpa" o "annotare" comando.

Inoltre, se si dispone di diversi rami attivi una riformattazione del codice causerà il caos con i tuoi unioni.

E 'sicuro, nel senso che i cambiamenti di formattazione puri farà alcuna differenza per ciò che è compilato e, quindi, alcuna differenza per il comportamento del codice in fase di esecuzione.

E 'la pena ricordare che la riformattazione grosso del codice può portare a "divertimento" quando si tratta di controllo del codice sorgente in seguito - se più colleghi hanno il codice controllato, e un membro del team arriva e riformatta, poi tutte quelle copie sono fuori di data. Peggio ancora, quando si aggiornano le loro copie di lavoro, ogni sorta di conflitti stanno per apparire, perché quei cambiamenti di formattazione influenzeranno enormi porzioni di codice, e risolvendo che può essere un incubo.

Codice riformattazione è lo stesso di riformattare un documento in Word; cambia il layout e quindi la leggibilità, ma non il contenuto.

Se tutti i file sono formattati lo stesso il codice diventa più leggibile , il che rende la manutenzione di un po 'più facile e quindi meno costoso. Anche la revisione del codice può essere più veloce e più efficace.

Inoltre, dato un buon stile di formattazione, i bug possono essere trovati più facilmente in quanto non possono nascondere; pensare a se le dichiarazioni senza le parentesi graffe e 2 all'interno di tali dichiarazioni parentesi immaginarie.

Non essere intelligenti e controllare il codice in e contrassegnare la prima di riformattare, in modo da avere uno stato di tornare a (e dire alla gente quanto sia facile che sarebbe), riformattare e il check-in e la modifica ancora una volta, senza altre modifiche.

Rispondere a queste domande per la gestione, e avrete fatto molta strada di convincerli è un cambiamento di sicurezza?

Perché le buone cose di formattazione?
Quali cambiamenti sarà fatto? (Se non è possibile rispondere a questa, non si sa abbastanza circa la ri-formattazione di sapere che sarà al sicuro)
Riusciranno i nostri suite di test unità di provare le modifiche non ha avuto effetti negativi? (Suggerimento la risposta deve essere sì)
Sarà il codice esistente essere taggato in repository di origine in modo da avere un rapido roll back opzione? (Suggerimento la risposta migliore essere sì)

Che circa lo copre.

In realtà, probabilmente sarei dalla loro parte. Riformattare le unità come li si apre per le correzioni o la valorizzazione quando saranno stati esaminati meticolosamente prima di tornare in produzione. Essi avrebbero dovuto essere formattato correttamente la prima volta, ma se sono in produzione sembra inutile e sconsiderato riformattare loro solo per amore di stile.

La coerenza è buono, ma "una consistenza stolto è il hobgoblin di piccole menti".

Sto indossando il cappello manager ...

Per farlo come un grande progetto, non avrei lasciato lo fai, non importa l'argomento. Vorrei, tuttavia, essere aperti alle stime più lunghi sui cambiamenti perché si sta modificando i file esistenti per includere queste modifiche di formattazione. Avrei bisogno di effettuare la formattazione cambia il proprio check-in però.

Grazie per tutte le vostre risposte.

Il mio ultimo argomento per convincere gestione; Frammenti di tutte le vostre risposte inclusi. Grazie per l'assistenza.

tecniche:

Riformatta è costituito da variazioni bianchi Space (senza riordino importazione, nessun membro / metodo)
Riformatta utilizzerà [specificare strumento e di processo]
Riformatta avverrà il [specificare tempo all'interno di codifica di ciclo per minimizzare l'impatto merge]

Sia prima che dopo una riformattazione:

Tutti i test di unità passeranno
Tutti i test di integrazione passeranno
Tutti i test funzionali passeranno
Tutti i test SOAP-UI passeranno
Il codice byte è lo stesso (An MD5 dei file .class seguenti javac (-G: nessuno))

Business:

Scopo:. Per rispondere alle norme aziendali che prescrive che i nostri file di origine rappresentano con precisione la struttura logica del nostro codice

Modifica Riformatta vs. cambiamento di codice (Word documento di esempio come sopra)
Riformatta utilizzerà [processo generale]
Riformatta avverrà il [specificare tempo entro ciclo economico per ridurre al minimo l'impatto]

Test Pilot:

Confermato "Formato batch" ha portato in meno unire conflitti poi "Formatta come Codice". .
ha confermato che il codice eseguibile (4k + file .class) rimane lo stesso. (Test MD5)
funzionalità Confermato non sarà influenzato (test automatizzati / test di fumo)
impostazioni di formattazione Confermato riporti unicamente le modifiche spazio bianco.

Nota: Nel mio caso un test pilota è stato eseguito più di 6 mesi da un sottoinsieme degli sviluppatori utilizzando uno strumento automatico a "Format come codice" (come prescritto da alcune delle risposte di cui sopra) . Mentre alcuni percepito che la riformattazione ha causato più unire i conflitti, questo non era effettivamente il caso.

Questa percezione era di base sulla coincidenza temporale della riformattazione. Ad esempio, considerare la persona che non sanno nulla di automobili. Un giorno i loro freni sicuro. Per che cosa attribuiscono la causa? Il gas ovviamente. Era l'ultima cosa che hanno messo in macchina (l'effetto "stazione di servizio"?). Chiaramente tuttavia, freni e un sistema di alimentazione sono sistema disparati come sono di formattazione e modifiche al codice. Abbiamo scoperto che improprie check-in all'interno del contesto del nostro processo di generazione hanno commesso l'errore.

Ultimo speravo che qualcuno avrebbe fornito un buon collegamento a uno studio che mostra guadagni di produttività legati alla codice comune in quanto è difficile mostrare il ROI per il business. Anche se nel mio caso, dal momento che si trattava di una normale società che ho avuto "compliance" dalla mia parte. Ho solo dovuto dimostrare che era più tempo di "Format, come si Codice" vs "Batch Format"

Se si utilizza Eclipse come piattaforma di sviluppo, è possibile caricare tutto il codice nello spazio di lavoro a livello locale. Dimostrare alla gestione non ci sono problemi, mostrando loro la scheda problemi.

Quindi, fare clic destro e Formattare ciascuno dei progetti uno per uno -. Dimostrando ancora vengono introdotti senza problemi

È possibile farlo sulla workstation locale, senza alcun danno a tutti per il vostro repository.

Onestamente se la gestione è così non tecnico come aver paura di formattazione del codice sorgente, quindi dimostrando che nessun problema visualizzati nella scheda problemi dopo un formato dovrebbe essere sufficiente a dimostrare che il codice è ancora valida.

Per non parlare avrete presumibilmente la vecchia versione taggato in giusto controllo del codice sorgente?

Una scuola di pensiero potrebbe essere quello di farlo senza chiedere e quindi essere in grado di andare "Ci vediamo!"

Naturalmente se si relitto il tutto? Allora ti licenziato. Si fa le vostre scelte ...

In alternativa, controllo del codice sorgente (o di backup semplici), allora si può sempre rotolare indietro.

Se il codice ha una copertura quasi abbastanza codice 100%, allora penso che il rischio può essere abbassato un po '.

Tuttavia, anche se la gestione ha convenuto che il codice di base è sicuro, penso che avrebbero avuto gli occhi su di dover giustificare pagare un dipendente per trascorrere ore di riformattare il codice solo per aderire a uno standard che (presumo) è stato introdotto lunga nel ciclo di sviluppo.

Usiamo Jalopy qui al mio lavoro attuale. Si tratta di un prodotto piuttosto solido e produce in uscita veramente pulito. Lo sviluppatore più anziano qui riformattato tutto il codice di base quando ha migrato da CVS a SVN, e doveva eseguire alcuni test per assicurarsi che avrebbe funzionato tutto il percorso dall'inizio alla fine, e ora abbiamo ganci per garantire che checked- in codice è formattato correttamente.

Detto questo, non credo che si può convincere chiunque che qualsiasi strumento è sciocco (o colpa) la prova, perché non c'è tale strumento. Se si pensa che il beneficio vale il tempo e il rischio (molto piccola), cercare di convincere la gestione il più grande vantaggio che si vede nel fare questo. Per me, il più grande vantaggio verrà se:

Tutti gli sviluppatori hanno le stesse impostazioni di formattazione;
La formattazione del codice sorgente viene verificata al momento del check-in da un gancio in SCM.

Perché se lo fai quanto sopra, se il codice è già formattato, quando si confrontano le revisioni nel SCM vedrete cambiamenti effettivi nella logica del programma, e non solo le modifiche di formattazione.

Se si dispone di una buona copertura di unit test, i risultati dei test prima e dopo sarà sufficiente.

A solo un teste specifiche up: se la vostra politica aziendale include membro alfabetico ordinamento, essere consapevoli del fatto che l'ordine dei campi statici non importa. Quindi, se si include una regola sul salvataggio o la pulizia che fa questo, si potrebbe rompere il codice.

Tecnicamente, durante la prima fase della compilazione, lexer spoglia tutti i commenti e gli spazi bianchi dalla sorgente. Questo è molto prima che la semantica del codice viene riconosciuto dal compilatore. Pertanto, qualsiasi spazi bianchi o commenti non possono cambiare nulla nella logica del programma. Al contrario, a che serve il linguaggio sarebbe essere e che vorrebbero usarlo se l'aggiunta di un paio di spazi o nuove righe sarebbe cambiare la semantica?

Sul fronte commerciale, si sta probabilmente andando a utilizzare alcuni strumenti specializzati per questo. Sono sicuro che la pubblicità sui loro siti web che funzionano molto bene.

Nota finale: se devi convincere la gestione di questo, forse si dovrebbe cercare di trovare un modo per lavorare con le persone più intelligenti

Vorrei chiedere di gestione qual è il loro attuale base per credere il codice funziona - quindi dimostrare che lo stesso strumento (test, documentazione, vocine ...) funziona esattamente come bene per il codice riformattato. Vorrei la loro risposta sia "prove" ...

So che le risposte precedenti sono tutte belle, ma qui è un altro possibile uno: Fare un CRC sulla versione compilata prima e dopo una riformattazione. Poiché compilazione sarebbe ignorare gli spazi, tabulazioni, linefeeds, ecc, quindi la versione compilata deve essere identico a quello originale, e che sarebbe rivelato quei manager semi-tecniche che tutto va bene.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow