Quali sono i 5 consigli di uno sviluppatore produttivo?

Guardando alcune delle risposte, sono stato ispirato ad aggiungere qualche altro suggerimento. Ecco una lista che ho.

• Scrivere blocchi di codice puliti e brevi - Non c'è niente di peggio che cercare di capire cosa avete fatto 2 mesi fa e come deve essere cambiato. Quando si hanno metodi e classi enormi, può essere molto difficile capire quale fosse la logica originale. I nomi di variabili, metodi e classi sono vitali per capire il codice. Avvolgere le cose in blocchi di codice più piccoli permette di fare nomi più significativi. Il nostro cervello non può contenere la logica complessa di un metodo di 400 linee e spesso risulta in bug difficili da individuare. Consiglio vivamente Clean Code di Robert C. Martin.
• Seguite il principio DRY - Non ripetetevi e se ne avete bisogno, è il momento di rendere riutilizzabile quel codice specifico. Non c'è niente di peggio che cercare di mantenere del codice che è stato duplicato più volte. È un'enorme perdita di tempo e senza dubbio creerà bug. Un programmatore è molto più produttivo se un cambiamento non ha bisogno di essere applicato in 20 posti diversi. È anche una perdita di tempo per tutti gli altri sviluppatori che non sono a conoscenza della duplicazione. Ho avuto casi in cui ho perso giorni a caccia di codice duplicato mentre facevo un banale cambiamento.
• Pensa alle cose - Non intendo tutto quello che fai, ma a volte è meglio prendersi un momento e pensare a come vorresti implementare qualcosa. Tanti sviluppatori si buttano a capofitto nella scrittura del codice solo per rendersi conto che il loro approccio è inflessibile, sbagliato o difficile da capire. Sedersi e pensare al design del sistema vi farà risparmiare un sacco di tempo in futuro.
• Torna indietro e rifattorizza - Nessuno scrive codice perfettamente la prima volta e i requisiti cambiano sempre. Prendetevi il tempo di tornare indietro e pulire il codice mentre è ancora fresco nella vostra mente. Rinominate le variabili, spezzate il codice strettamente accoppiato, ecc. La qualità del codice migliorerà notevolmente e vi ringrazierete 2 mesi più avanti quando sarà necessario apportare dei cambiamenti.
• Automatizza i tuoi test, cattura i bug in anticipo - Quando il sistema diventa più grande, gli sviluppatori passano più tempo a correggere i bug. Alla fine si arriva al punto in cui lo sviluppatore non è affatto produttivo. Uscire da questa situazione è una sfida enorme e molti sviluppatori semplicemente optano per correggere costantemente i bug. C'è una ragione per cui l'integrazione continua (CI) ha preso piede così rapidamente negli ultimi anni. Permette agli sviluppatori di catturare molti bug non appena si verificano. Scrivere i test e poi avere un build server che prende, costruisce il software ed esegue i test. TDD e CI richiedono tempo per abituarsi e rallentano il processo di sviluppo; ma si spende molto meno tempo a risolvere i bug. Non è perfetto e si dovrebbe ancora testare nel modo tradizionale (fare clic sul pulsante vero e proprio), ma può fare molta strada.