Come scrivere codice efficiente nonostante scadenze pesanti


28

Sto lavorando in un ambiente in cui abbiamo molti progetti con scadenze rigorose sui risultati finali. Parliamo anche direttamente con i clienti, quindi svolgere i lavori in modo rapido e veloce è d'obbligo.

Il mio problema è che scrivo sempre il codice per la prima soluzione che mi viene in mente, che ovviamente ho ritenuto il migliore in quel momento. Tuttavia, finisce sempre brutto e in seguito mi accorgerei che ci sono modi migliori per farlo, ma non posso permettermi di cambiare a causa delle restrizioni temporali.

Ci sono suggerimenti con i quali potrei rendere efficiente il mio codice e consegnarlo in tempo?


11
Non concentrarti su un codice efficiente , ma piuttosto su un codice corretto . Quello va molte miglia di più. Risparmia la tua efficienza per le versioni successive.
Jesse C. Slicer,

Risposte:


23

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

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


3
Bene, sono d'accordo con tutto ciò, tranne per il fatto che raramente funziona così nella realtà. Il tuo capo vuole fare qualcosa entro X date e non si muoverà? Peccato, devi ancora farlo, o forse puoi trovare lavoro altrove, che spesso non è un'opzione.
Ed S.

4
@EdS. Trovare lavoro altrove è sempre un'opzione ... si chiama "mantenere la tua carriera" e ci vuole tempo e fatica per farlo.
Spoike,

17

Va bene, 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
  • Meditare
  • Dormi molto (7-9 ore a seconda della persona)
  • Fai un pisolino ogni volta che il tuo cervello è confuso
  • Vai a dormire con un problema irrisolto. Non terminare la giornata con tutto completo. Lascia in sospeso un compito difficile: il tuo subconscio è straordinariamente efficace.
  • Indossa abiti comodi
  • Esercizio
  • Prenditi del tempo per fare esercizi mentali fisici: sudoku (non programmato), parole crociate, esercitazioni matematiche, puzzle spaziali, ecc.
  • Esegui esperimenti oggettivi su te stesso per vedere quali dei tuoi comportamenti influiscono sulle prestazioni (avrai bisogno di un modo affidabile per testare le prestazioni affinché questo funzioni).
  • Presta attenzione alla tua salute spirituale
  • Mutande di cotone
  • Fai attenzione alla tua salute sessuale
  • Trova il tempo per la tua famiglia e i tuoi amici
  • Diventa esperto di qualcosa al di fuori della tua professione (musica, cucina, sport, ecc.) E socializza con altre persone che fanno la stessa cosa
  • Per alcune persone, un animale domestico è un must

Prima di conoscerlo, noterai un netto miglioramento nella produttività della programmazione e nella 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 creatività, previene e inverti l'invecchiamento mentale
  2. Il sé quantificato
  3. Seth Roberts - in Scientific American

6
Hai dimenticato: niente caffeina.
Christopher Mahan,

Hai dimenticato: non guardare PORN durante la programmazione! Grazie!
AmirHossein,

9

È controintuitivo, ma probabilmente dovrai rallentare. Quando si implementa la prima soluzione che viene in mente, si crea molto lavoro extra per se stessi lungo la strada. Con "in fondo alla strada" intendo già nel pomeriggio. I problemi che crei per te non richiedono mesi per svilupparsi. Considera le tue opzioni. Digita meno e medita di più. Anche in un breve progetto, scoprirai che una minore codifica potrebbe effettivamente accelerare.

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

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


Sono d'accordo con questo. Prendi in considerazione due o tre possibili approcci prima di iniziare a programmare. Quindi, basandoti su una combinazione di facilità di implementazione, facilità di test, efficienza ed estensibilità, fai la tua scelta.
Omega Centauri,

8

Cerca un altro lavoro.

Lo troverai dopo circa 6 mos. a un anno in cui non avrai orgoglio per il lavoro svolto. Inoltre, non avrai trascorso il tempo a 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 quanto non fossi all'inizio.

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

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


2
Cosa intendi con "mos". ?
Darius.V,

mos. = mesi. Ancora due personaggi ...
gnasher729,

Non ti conosco ma "mos" in persiano ha un cattivo significato. significa culo. ;)
AmirHossein il

3

Dal punto di vista dei clienti, l'efficienza del codice potrebbe non essere così critica e può essere piuttosto costosa. In questi giorni il tempo impiegato per creare il codice deve risparmiare ore di tempo della CPU per giustificare un'ora del tuo tempo. Per la maggior parte dei programmi l'efficienza non è così critica. Anche per quelli dove si trova, la maggior parte del codice non deve essere così efficiente. Data la scelta, la mia preferenza sarebbe quella di una soluzione facile da mantenere piuttosto che un codice più efficiente e più difficile da mantenere.

Prendere tempo per pianificare la codifica prima di iniziare può darti il ​​tempo di valutare soluzioni e considerare approcci alternativi. Ciò dovrebbe farti risparmiare tempo nella codifica e nei test. Ho scoperto che spesso il codice più semplice è più efficiente.

Disporre il codice in modo pulito utilizzando tutte le righe 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, fidati che faccia il suo lavoro.

Accetta che abbastanza buono è abbastanza buono. Quando ti vengono in mente approcci più efficienti, 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 utilizza). Questo ti darà un'idea di quando sarà appropriato un approccio più efficiente.

Molte persone considerano l'ottimizzazione prematura un cattivo approccio. 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 è necessario strumentare il codice prima e dopo la modifica per vedere se si è davvero migliorato l'efficienza.

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


1

Robert ha trattato 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 per il pollice che mi vengono in mente:

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

1

In fase di progettazione, parla con i colleghi .

Discuti del tuo progetto e di come lo desideri e fagli esaminare attentamente le tue decisioni. Se e quando siete tutti d'accordo su ciò che è intelligente, avete un design molto più solido.


1

Pratica. Esercitati a scrivere un buon codice fino a quando non diventa una seconda natura. Quindi esercitati a programmare più velocemente. Quindi esercitati a programmare meglio. E quando hai finito ... esercitati ancora.


0

Il mio problema è che scrivo sempre il codice per la prima soluzione che mi viene in mente, che ovviamente ho ritenuto il migliore in quel momento.

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

Il tuo problema è che hai un management che non capisce il vero costo del ciclo di vita dei sistemi software. Il 90% di tale costo è rappresentato dalla manutenzione, non dall'implementazione iniziale. Test e refactoring sono i nostri migliori strumenti per ridurre il costo totale del ciclo di vita di un sistema software. Se i tuoi manager non ti consentono di fare queste cose, sono irresponsabili e devono essere riqualificati. Oppure devi trovare un nuovo lavoro.

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

* Come programmare su un programma molto stretto?


0

Se hanno fissato l'ambito e il tempo, tutto quello che puoi fare per rispettare la scadenza è la qualità della caduta.

Se possibile, rilasciare la qualità esterna, visibile agli stakeholder, non scendere a compromessi sulla qualità interna, roba che danneggia la tua abitabilità nella base di codice.

Non credo davvero che il miglioramento personale ti aiuterà un po 'in questa situazione. Semmai, 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 per fare qualcosa?

Porta delle scelte al tuo capo e / o cliente. Troppo spesso sono gli stessi sviluppatori che scelgono di rinunciare alla qualità senza comunicare nulla. I progetti / lavori in ritardo sono molto comuni e generalmente "gestiti". Agisci in tempo, avvisa le persone se vedi arrivare una scadenza mancata.

Non possono ridurre la portata 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. Dai loro cose per pesare l'una contro l'altra.

Alcune cose che solo TU puoi decidere. Se stai per farlo funzionare. Ma è molto irraggiungibile. 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 prendere. O perché il problema richiede molto tempo per essere articolato o hai un manager non tecnico.

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

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


0

Sono uno sviluppatore .Net che lavora su applicazioni web.

Le cose che ho iniziato a fare sono:

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

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

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


questo post è piuttosto difficile da leggere (wall of text). Ti dispiacerebbe modificarlo in una forma migliore?
moscerino del

@gnat - grazie per il suggerimento. Aiuta a ricevere suggerimenti con il downvote. Spero che la formattazione sia migliore ora.
user637563,

Trovare una soluzione al di fuori dell'intero ambiente può avere i suoi vantaggi. Avrai qualcosa che funziona, quindi saprai che se non funziona nel sistema completo, il problema deve essere in conflitto con il resto del sistema. È quindi possibile provare a modificare la soluzione per rimuovere il conflitto mentre si è in grado di vedere se la soluzione funziona ancora al di fuori dell'ambiente completo. La tua sanità mentale potrebbe ringraziarti per questo.
Piegato il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.