Qual è il momento giusto per il refactoring del codice, non l'ottimizzazione?

3

Ho lavorato a un'applicazione basata su Python (Django) / JavaScript (AngularJS) da un po 'di tempo. (Ho imparato tutto questo sulla strada, in precedenza era stato un programmatore Java) e ho avuto momenti in cui il il codice era davvero ingestibile:

Single js script for the entire application, around two-dozen controllers, a dozen or so services and other components, all squashed into a single file.

Ho effettuato il refactoring che con successo, tuttavia, ha aggiunto un Grunt per minification e la generazione corretta del codice finale per l'applicazione, spostato a bower per la gestione dei pacchetti e, a sua volta, sostanzialmente mi ha semplificato la vita.

Solo se avessi ottimizzato le cose in precedenza nel ciclo di sviluppo, le cose sarebbero state più semplici. Quindi una cosa che mi stavo chiedendo è quale sarebbe il momento giusto per ottimizzare il mio codice? Settimanalmente, settimanalmente o solo quando e come valuto la qualità del codice ogni giorno, ogni volta che eseguo una build.

Ci sono probabilmente molti strumenti là fuori per quello che voglio fare, ma quello che voglio sapere è dove dovrei iniziare con questo e qual è il modo giusto per ottimizzare il codice sorgente per usare buoni standard di programmazione, dato che Python e JS sono linguaggi tipizzati in modo statico, senza particolari standard di codifica applicati per impostazione predefinita, rispetto a Java, dove ho trovato più facile scrivere un buon codice.

    
posta Divij Sehgal 11.07.2017 - 14:22
fonte

2 risposte

13

Prima di tutto, nessun Java non ha standard di codifica applicati. Qualunque cosa tu possa fare funzionare in JavaScript, posso anche lavorare ma sembrare peggio in Java. Lavorare, in qualsiasi lingua, non garantisce che sia scritto bene. Hai bisogno di prove? Vedi Code Golf .

Gli standard di codifica esistono in te. Non la lingua Probabilmente ti senti così perché hai guardato abbastanza codice Java a questo punto che ti aspetti come dovrebbe essere il codice Java. Non hai ancora sviluppato questo senso nelle tue nuove lingue.

È importante capire che gli standard up-to-coding NON sono uguali a quelli ottimizzati. Ottimizzato significa non sprecare memoria o cicli della CPU. Gli standard up-to-coding riguardano non sprecare tempo del programmatore con codice di difficile lettura.

Il miglior "strumento" per questo è un collega programmatore che può guardare il tuo codice e dirti quanto è facile da leggere. Chiamiamo questo una recensione del codice. Se non lo fai ogni volta che scrivi un nuovo codice, stai rendendo le cose difficili per chiunque voglia lavorare con il codice in seguito. Compreso te.

Quando refactoring?

Uno dei migliori tempi di refactoring è appena prima di aggiungere una nuova funzione.

Prima di avere una funzione reale in mente, non hai idea di come debba essere modificato il codice. È allettante generalizzare troppo. Il codice flessibile è buono ma sfortunatamente a volte tentiamo la flessibilità immaginando come cambierà e accoglierà il cambiamento immaginato. Questo crea codice inutile, astrazione inutile e indiretta inutile. Il risultato non è flessibile.

Tuttavia, dovresti aspettarti che il codice debba essere modificato. La chiave è ridurre al minimo le ipotesi che si fanno sul futuro. Le ipotesi che devi fare devono essere isolate l'una dall'altra. Prendi le decisioni in un unico posto in modo che il cambiamento possa avvenire in un unico posto.

Quando hai in mente una funzione reale, puoi rifattorici per creare un buon posto per questa funzione. Ad esempio, questo è un buon momento per un nome di classe con il suffisso Impl per ottenere un nome reale che lo differenzia dalla nuova classe di implementazione che stai per aggiungere.

Quindi, sì, subito dopo un test pass è un momento in cui potresti eseguire un refactoring. Assicurati di sapere perché stai procedendo al refactoring.

    
risposta data 11.07.2017 - 14:51
fonte
4

Dalla tua domanda, sembra che tu stia confondendo "refactored" con "ottimizzato" e in realtà ti riferisci al precedente.

Quando dovresti refactoring? È facile, subito dopo (mai prima d'ora) il tuo test precedente "diventa verde". Se non si sta usando TDD (e se no, perché no?), Allora raramente è il momento ideale per un refactoring sicuro in quanto si potrebbe rompere qualcosa nel farlo. Diventa un caso di "refactoring a proprio rischio". L'unica vera regola è "più a lungo lo lasci, maggiore è la possibilità di rompere le cose quando fai il refactoring".

    
risposta data 11.07.2017 - 15:20
fonte

Leggi altre domande sui tag