Quanto lontano quando standardizzare il codice [duplicato]

Question

Quanto lontano quando standardizzare il codice [duplicato]

#1 da (3 voti)

2

Il mio piccolo team e io abbiamo creato un'applicazione web di dimensioni decenti (~ 50k linee), con un'API completa, tutto in Perl. Come sanno noi hacker di Perl, è facile diventare sciatti. Abbiamo dovuto eseguire il porting su un sacco di codice legacy. Ne è conseguito il codice perl whale guts.

Per farla breve, eravamo sotto un vincolo di tempo abbastanza ristretto che ora è stato respinto, quindi abbiamo un po 'di tempo per tornare indietro e standardizzare il codice.

Abbiamo rapidamente scoperto quanto il nostro codice non fosse standard in quanto il nostro appaltatore stava sviluppando un'app iOS in cui abbiamo numeri di account di lunghezza 10 in alcuni luoghi, 12 in altri con dati predefiniti, ecc.

Dato che sto fissando i formati delle date e la formattazione dei dati, noto una tonnellata di variabili realmente non descrittive e la denominazione delle chiavi hash che proviene dal codice legacy - non è bello mantenendolo in vita.

Fondamentalmente, la mia domanda è: dato lo scenario sopra o la tua esperienza, quanto vai lontano quando pulisci e standardizzi? Vale la pena entrare e sostituire i nomi delle chiavi hash con quelli con cassa cammello più lunghi, i nomi delle variabili, il modo in cui i dati vengono gestiti nei risultati ecc.

So che molto più dolore può derivare dalla rottura del codice di lavoro, e potrebbe non valerne la pena .. ma come fai a sapere quanto lontano? Ripassare ora e poi paga più tardi, o semplicemente vivere con un po 'di "debito di codice"?

coding-style code-formatting api-design conventions standardization

posta Zach Leighton 09.02.2014 - 02:16

fonte

1 risposta

Leggi altre domande sui tag coding-style code-formatting api-design conventions standardization

ereditarietà e variabili finali statiche Come rilevare gli sprite in un SpriteSheet?

score 3 · Answer 1

TL; DR: utilizza il linting automatico e un riformattatore del codice hook di commit.

Quando lavoravo in Perl, decidemmo di inserire un controllore di lanugine nella nostra suite di test e un hook di commit che riformattasse automaticamente il codice. Abbiamo fatto in modo che in futuro non avremmo più debiti tecnici dovuti alla mancanza di coerenza del codice e ai problemi di sfilacciamento.

Non volevamo pagare il tempo necessario per portare l'intera base di codici al nuovo standard tutto in una volta, quindi li abbiamo sottoposti a grandfathering con eccezioni esplicite basate sull'errore preciso che il linter ha gettato (incluso il numero di riga). L'eccezione era volutamente fragile, così che la prossima volta che qualcuno toccava il file avrebbero dovuto portarlo agli standard stabiliti dal linter.

Nel periodo straordinario abbiamo esteso il nostro riformattatore di codice e linter con personalizzazioni basate sugli standard dei nostri team. Questo ci ha permesso di utilizzare i test automatici e l'integrazione continua per aiutare a eliminare i bug di linting. Quando il riformattatore è cambiato, lo eseguiremmo in massa e commetteremo le modifiche. Per quante più cose possibili abbiamo creato driver automatici per forzare la modifica (riformattare il codice) o catturare il problema (linting). Abbiamo finito con il guidare ad uno standard abbastanza completo per noi stessi. Certamente non abbiamo mai avuto un problema dopo un problema correlato su standardizzazione o coerenza. Forse alcuni su idiomi da usare e non usare, ma anche alcuni li hanno trasformati nelle estensioni dei pelucchi.