Come scrivere codice efficiente nonostante scadenze pesanti

Se è necessario mantenere il codice, spiegare che è necessario ulteriore tempo per rendere il codice più gestibile, il che farà risparmiare denaro sul back-end. In altre parole, rendere un codice gestibile un requisito.

Se a loro non importa, non penso che tu debba fare qualcosa di diverso, oltre a migliorare sempre e fare il meglio che puoi per incorporare le migliori pratiche ogni volta che è possibile.

Ok, questo può sembrare un po 'folle, ma giuro che funziona. Non è solo per la programmazione, è una ricetta per aumentare la creatività, la concentrazione e la memoria:

• mangia bene
• Meditate
• Dormi molto (7-9 ore a seconda della persona)
• Nap quando il tuo cervello è confuso
• Vai a dormire con un problema non risolto. Non finire la giornata con tutto completo. Lascia un compito difficile in sospeso: il tuo subconscio è straordinariamente efficace.
• Indossa abiti comodi
• Esercizio
• Prenditi del tempo per fare esercizi mentali meccanici - sudoku (non programmato), cruciverba, esercizi di matematica, puzzle spaziali, ecc.
• Esegui esperimenti obiettivi su te stesso per vedere quali dei tuoi comportamenti influenzano le prestazioni (avrai bisogno di un modo affidabile per testare il rendimento perché funzioni).
• Partecipa alla tua salute spirituale
• Mutande di cotone
• Partecipa alla tua salute sessuale
• Prendi tempo per la tua famiglia e i tuoi amici
• Diventa abile in qualcosa al di fuori della tua professione (musica, cucina, sport, ecc.) e socializza con altre persone facendo la stessa cosa
• Per alcune persone, un animale domestico è d'obbligo

Prima che tu te ne accorga, vedrai un netto miglioramento della produttività di programmazione e della qualità delle soluzioni (per non parlare dei miglioramenti in altre aree).

Fonti:

1. Il tuo cervello miracoloso: massimizza il tuo cervello, aumenta la tua memoria, solleva il tuo umore, migliora il tuo QI e la creatività, prevedi e inverti Invecchiamento mentale
2. The Quantified Self
3. Seth Roberts - in Scientific American

È contro-intuitivo, ma probabilmente devi rallentare. Quando implementi la prima soluzione che ti viene in mente, crei un sacco di lavoro extra per te stesso lungo la strada. Con "down the road", intendo già più tardi nel pomeriggio. I problemi che crei per te non richiedono mesi per svilupparsi. Considera le tue opzioni. Digita di meno e medita di più. Anche in un progetto breve, scoprirai che meno la codifica potrebbe accelerarti.

Se i tuoi clienti si raggruppano in settori specifici, prova a creare progetti con componenti riutilizzabili. Non scrivere codice è più veloce della scrittura.

Dal punto di vista del tuo cliente, questo ha un odore simile a " Veloce, buono ed economico, scegli due ". Certo, vogliamo tutti ciò che desideriamo immediatamente, ma i vostri clienti devono considerare se questo è il migliore a lungo termine. Cerca di articolare i compromessi e aiutali a prendere buone decisioni.

Cerca un altro lavoro.

Lo troverai dopo circa 6 mos. a un anno che non avrai orgoglio per il lavoro che hai svolto. Inoltre, non avrai speso tempo per imparare nuove tecniche, tecnologie o strutture - quindi dopo un anno non sarai più in grado di tenere il passo con le nuove tecnologie. Sarai un programmatore peggiore rispetto al mercato dopo un anno di quello che eri all'inizio.

Se passa troppo tempo (diciamo un paio d'anni o più), avrai un momento molto difficile essere assunto ovunque tranne per questi tipi di lavori frenetici in cui il codice di qualità non è apprezzato, solo la velocità.

Detto questo, come esperienza di apprendimento del "mondo reale", c'è qualcosa da dire per l'ambiente frenetico, ma direi che circa 6 mos. è abbastanza. Oltre a questo, dovresti cercare di connetterti con un paio di reclutatori e cercare un posto migliore. Sarai molto più felice, onesto.

Dai tuoi clienti l'efficienza del codice vista potrebbe non essere così critica e può essere piuttosto costosa. In questi giorni il tempo trascorso a fare il codice ha bisogno di risparmiare ore di tempo di CPU per giustificare un'ora del tuo tempo. Per la maggior parte dei programmi l'efficienza non è così importante. Anche per quelli dove è, la maggior parte del codice non ha bisogno di essere così efficiente. Data la scelta, la mia preferenza sarebbe per una soluzione di facile manutenzione piuttosto che per un codice più efficiente e più difficile da mantenere.

Prendendo tempo per pianificare la codifica prima di iniziare potrebbe darti il tempo di valutare le soluzioni e prendere in considerazione approcci alternativi. Questo dovrebbe farti risparmiare tempo nella codifica e un test. Ho trovato che il codice spesso più semplice è più efficiente.

Disegna il codice in modo pulito utilizzando tutte le linee necessarie. Il codice complesso può confondere l'ottimizzatore e può causare un codice più lento. I compilatori moderni sono molto bravi a ottimizzare il codice, credono che faccia il suo lavoro.

Accettalo che è abbastanza buono. Quando trovi approcci più efficaci, prendi nota di te stesso. Se hai tempo, confronta alcuni dei tuoi progetti più efficienti con quelli implementati. Provali nel piccolo (solo il codice effettuato) e nel grande (il programma che li usa). Questo ti darà un'idea di quando un approccio più efficiente è appropriato.

Molte persone considerano l'ottimizzazione prematura un approccio errato. Può essere costoso da implementare. Sfortunatamente, molte ottimizzazioni premature in realtà non sono efficienti come il codice che hanno ottimizzato. Per ottimizzare correttamente il codice, devi prima eseguire uno strumento con il codice prima e dopo la modifica per vedere se hai effettivamente migliorato l'efficienza.

Tecniche di studio che aiutano a scrivere codice più pulito con accoppiamento basso e alta coesione. In molti casi, ridurre la complessità aumenta l'efficienza. Le tecniche che ti aiutano a minimizzare i bug che devi risolvere durante lo sviluppo ti aiuteranno a consegnare più velocemente. Ciò potrebbe liberare tempo per testare approcci alternativi.

Robert ha coperto gli aspetti più importanti.

Ho lavorato in tali ambienti, in cui il codice non (non può) vivere per più di sei mesi. Ci sono alcune regole del pollice che posso pensare:

1. Utilizza librerie open source, soluzioni di terze parti, ecc.,. L'apprendimento coinvolto è ripagato da una minore manutenzione e debugging. Tuttavia, se sei bloccato con una libreria buggy, sei condannato.
2. Assicurati che il tuo design sia estensibile. Un requisito obbligatorio: la maggior parte del lavoro si presenta come miglioramenti, non costruisce nuove funzionalità.
3. Costruisci piani di test rigorosi. Ottieni un QA o automatizza i test per garantire i test di regressione.
4. Utilizza strumenti intelligenti: IDE, utilità di generazione del codice, ecc.,.
5. Mantieni le cose il più possibile configurabili. (Il rovescio della medaglia è un maggiore sforzo di test)
6. Migliora la velocità di battitura: -)

Nella fase di progettazione, parla con i colleghi .

Parla del tuo design e di come lo vuoi fare, e chiedi loro di esaminare attentamente le tue decisioni. Se e quando siete tutti d'accordo su ciò che è intelligente, avete un design molto più sano.

Practice. Esercitati a scrivere un buon codice finché non diventa una seconda natura. Quindi esercitati nella codifica più velocemente. Quindi pratica meglio la codifica. E quando hai finito ... pratica ancora un po '.

My issue is that i'd always write code for the first solution that comes to my mind, which of course I thought as best at that moment.

No, non è il tuo problema. Questa è una virtù. Sta facendo la cosa più semplice che potrebbe funzionare. Ma funziona solo se combinato con il refactoring. È un processo continuo: fare la prossima cosa più semplice che possa funzionare, più e più volte, in modo che il tuo sistema sia sempre espressione della tua attuale comprensione dello spazio della soluzione.

Il problema è che hai una gestione che non comprende il vero costo del ciclo di vita dei sistemi software. Il 90% di tale costo è la manutenzione, l'implementazione iniziale non . I test e il refactoring sono i nostri migliori strumenti per ridurre il totale costo del ciclo di vita di un sistema software. Se i tuoi dirigenti non ti permettono di fare queste cose, sono irresponsabili e devono essere riqualificati. O hai bisogno di trovare un nuovo lavoro.

Infine: come ho detto prima *, devi imparare come dire di no .

* Come codificare su molto programma ristretto?

Se hanno fissato la portata e il tempo, tutto quello che puoi fare per rendere la scadenza è la qualità della caduta.

Se possibile, elimina la qualità esterna, visibile agli stakeholder, non compromettere la qualità interna, elementi che danneggiano la tua abitabilità nella base di codice.

Non credo che l'auto miglioramento ti possa aiutare in questa situazione. Se non altro, mi dispiace dirlo, di solito è assertività.

Cerca di mettere piede nella porta quando il lavoro è stimato. Come può il tuo capo stimare quanto tempo impieghi a fare qualcosa?

Porta le scelte al tuo capo e / o cliente. Troppo spesso sono gli sviluppatori stessi a scegliere di eliminare la qualità senza comunicare nulla. I progetti / lavori tardivi sono molto comuni e in genere "gestiti". Agisci in tempo, avvisa le persone se vedi arrivare una scadenza mancante.

Non possono tagliare l'ambito o spostare la scadenza se non dici loro nulla.

Se hai intenzione di scendere a compromessi sulla qualità in qualsiasi forma, prova a lasciare che sia la loro decisione. Dare loro peso in modo che siano l'uno contro l'altro.

Alcune cose solo tu puoi decidere. Se hai appena finito di funzionare. Ma è molto intrattabile. Forse non sei sicuro che funzioni in tutti i casi. Non dire a nessuno che hai finito. Ripeti. Molto spesso è una decisione che solo tu puoi fare. O perché il problema richiede molto tempo per articolare o hai un manager non tecnico.

A volte è parte della tua etica del lavoro, potresti ricucire un paziente senza lavarti le mani perché 'non c'è tempo'?

Soprattutto, ricorda: non c'è più tardi.

Sono uno sviluppatore .Net che lavora su applicazioni web.

Le cose che ho iniziato a fare è -

Se è in codice C #, provo a scrivere quel codice in LinqPad prima (se possibile).

Se è un codice Javascript, prima scrivo quel codice e lo collaudo in jsfiddle / jsbin (se possibile).

Ho trovato che questo aiuta con la qualità del codice, ma non mi rallenta (e in molti casi, ho trovato che sia più veloce).