it-swarm.it

Come diventare un programmatore "più veloce"?

La mia ultima valutazione del lavoro ha incluso solo un punto debole: la tempestività. Sono già a conoscenza di alcune cose che posso fare per migliorare questo, ma quello che sto cercando sono altre.

Qualcuno ha suggerimenti o consigli su cosa fanno per aumentare la velocità della loro produzione senza sacrificare la sua qualità?

Come stimare le tempistiche e attenersi ad esse? Cosa fai per fare di più in periodi di tempo più brevi?

Qualsiasi feedback è molto apprezzato, grazie,

142
Nick Gotch

Spegni il computer. Prendi una matita e un po 'di carta. Disegna il tuo design. Revisionalo con i tuoi colleghi. Quindi scrivi il codice.

190
gatorfax

Qualche idea...

  • Evita la doratura: fai solo ciò che ti viene chiesto (in termini di requisiti)
  • Comprendi i requisiti aziendali e fallo bene la prima volta
  • Comprendi a fondo l'ambiente e gli strumenti
  • Diventa una dattilografa fantastica, usa le scorciatoie da tastiera anziché il mouse
  • Adotta un approccio iterativo e incorpora i controlli di integrità per assicurarti di essere sulla strada giusta
  • Non reinventare la ruota, considera di riutilizzare il lavoro passato e il lavoro di altri
  • Elimina le distrazioni, non continuare a controllare la posta elettronica, guardare fuori, parlare con i colleghi, ecc.
  • Non sovraccaricare te stesso - riconosci quando devi fare delle pause
149
Mayo

Il tuo desiderio di essere un programmatore "più veloce" da solo è lodevole. Tuttavia, non consegnare in tempo non significa che sei lento, significa che il progetto è stato pianificato male. Essere un programmatore "più veloce" non aiuterà; significa solo che supererai la scadenza più velocemente.

Tu (e la tua squadra) state commettendo uno dei seguenti errori (o tutti):

  • sottovalutando il lavoro che deve essere fatto;
  • mancante un grande requisito o pezzo di architettura durante la pianificazione;
  • confuso stime di lavoro con stime di calendario e non contabilità per cose come riunioni/telefono/altre spese generali;

Esistono diversi modi per affrontare uno dei tre precedenti. Ma prima di poter migliorare su uno di essi, devi sapere perché le cose stanno andando come stanno. Esegui un post mortem sulle ultime due o tre stime dei progetti rispetto al tempo effettivo impiegato e scopri dove è andato il tempo extra.

Lo ripeterò di nuovo - essere lenti nello scrivere il codice non farà perdere la scadenza, se l'hai pianificato correttamente per tenere conto di quel fatto.

132
Franci Penov

Davvero, impara davvero il tuo editor. Se usi un IDE assicurati di usare tutte le funzionalità che offre. Ottieni un cheat sheet per imparare le scorciatoie da tastiera per il tuo editor preferito. Se stai usando una configurazione Shell scorciatoie per le directory di uso comune

89
slashnick

"Qualcuno ha suggerimenti o consigli su cosa fanno per aumentare la velocità della loro produzione senza sacrificare la sua qualità?"

Molte, molte persone lottano per la qualità "finale" a scapito di qualcosa che sia (a) semplice, (b) affidabile e (c) corretto.

Il modo più importante per accelerare il tuo sviluppo è semplificare cosa stai facendo in modo che sia assolutamente il più semplice possibile.

La maggior parte delle persone che hanno problemi con la consegna in tempo stanno offrendo troppo, troppo. E i motivi addotti sono spesso sciocchi. Spesso sono solo requisiti percepiti, non requisiti reali.

Ho sentito molte persone dirmi cosa "si aspetta" il cliente. Questa è una cattiva politica.

Costruisci la cosa più semplice possibile. Se il cliente richiede di più, crea di più. Ma prima costruisci la cosa più semplice possibile.

38
S.Lott

Evita di lucidare il tuo codice alla perfezione, fallo funzionare. Questo è ciò che l'azienda si aspetta.

Ma spesso, aumentare la velocità implica sacrificare la qualità.

32
user8685

Riutilizzo: cerco di estrarre elementi intelligenti dai progetti precedenti, in modo da poterli riutilizzare in progetti futuri. Vale sempre la pena chiedersi "potrei usarlo di nuovo un giorno?"

29
Phil Jenkins

Mantienilo semplice.

Se usi TDD, dovresti seguire "rosso, verde, refactor":

  1. Scrivi un test fallito (rosso). (Spesso per funzionalità il tuo codice non ha ancora.)
  2. Commetti orribili crimini di codifica per far passare i test (verde). Hardcode se necessario.
  3. Refactor, probabilmente rompendo i test per un breve periodo, ma nel complesso migliorando il design.
24
bryanbcook

Scarica tutta la documentazione relativa alle lingue/librerie sul computer locale, quindi scollega il cavo di rete/disattiva Wi-Fi .

Non sto cercando di essere divertente qui. Questo mi aiuta davvero!

22
mcjabberz

Nota quando hai letto Stack Overflow per troppo tempo. La scusa "Compilazione" funziona solo per così tanto tempo. :)

20
Matthew Jones

Evita di cambiare attività troppo spesso. Distrazioni e cambio di attività possono uccidere un giorno, anche se usi strumenti come Mylyn per gestire le tue attività.

Capire una granularità (ad esempio, 30 minuti) e lavorare solo su cose relative all'attività da svolgere. Qualsiasi altra cosa (nuove segnalazioni di bug, e-mail su altri problemi, questioni procedurali non correlate) viene ritardata almeno fino al "prossimo checkpoint". Assicurati di disabilitare il pop-up delle notifiche e-mail in modo da non essere risucchiato.

È particolarmente efficace se hai un amico nella tua squadra che ti farà sapere se le cose si sciolgono davvero e richiedono la tua attenzione immediata.

20
Uri

Fallo nel modo migliore, la prima volta. Se ciò significa che devi fermarti e pensarci un po 'prima di iniziare, allora fallo. Funziona il 90% delle volte.

14
ck01
14
AJ Johnson

I fallo domani .

Getting Things Done è anche estremamente utile.

Ho comunque una breve soglia di attenzione, quindi questi libri mi aiutano a mantenere la concentrazione ... cosa stavo facendo di nuovo?

12
Matthew Jones

Pratica e duro lavoro.

Devi dedicare tempo e fatica. Man mano che diventi più a tuo agio e sicuro degli strumenti che dovrebbero seguire, velocità e creatività.

Se vuoi migliorare qualche particolare abilità, può anche aiutare a progettare esercizi che ti permetteranno di lavorare specificamente su quello. Se la tua lentezza è in fase di progettazione, prova a trovare problemi di progettazione su cui lavorare online. Ripetere lo stesso esercizio ti consentirà di completarlo più velocemente e di esercitarti nella velocità. Personalmente mi piace esercizi con algoritmo di TopCoder per esercitarmi nella velocità di programmazione. Hanno anche sfide di progettazione, ma non le ho provate.

12
DisplacedAussie

Scopri di più su The Zone, scopri come coinvolgerti e impara a riconoscere quando non ci sei.

Una volta che sono "nella zona", sono estremamente produttivo e il codice scorre appena fuori di me, spesso posso ottenere la codifica di 2 o 3 giorni in 1 giorno. Ma trovo che spesso è difficile arrivare in quel posto, mi trovo a rimandare, distratto da altre cose (Stack Overflow per esempio).

Citazione da trucchi-che-usi-per-entrare-nella-zona

11
Dustin Getz

Conoscere il tuo IDE e il framework bene. Dover ricorrere a Google per ogni piccola cosa richiede tempo.

10
Mike Hall
9
ZeroCool

Prima di iniziare a sviluppare:

  • Esci dalla tua casella di posta
  • Disattiva tutti i client IM
  • Chiedi cortesemente ai colleghi di darti il ​​tempo di concentrarti
  • Naturalmente, smetti di navigare in Internet

Ogni volta che vieni interrotto, rallenti perché ti ci vuole tempo per tornare in pista con i suoi pensieri. Ho sentito cifre che per ogni interruzione, la mente umana impiega 5-10 minuti per ripristinare il processo di pensiero che aveva prima dell'interruzione. Con così tanto tempo per interruzione, non ci vuole molto da perdere tutto il giorno.

Le persone della nostra azienda si sono effettivamente impegnate a bloccare il tempo nei loro calendari e poi a trasferirsi in una sala conferenze vuota per un paio d'ore al giorno.

8
dhable

Scopri il tuo sviluppo IDE dentro e fuori. Impara i tasti di scelta rapida. Impara a usare meno il mouse. Trovo che questo mi faccia risparmiare molto tempo.

7
D3vtr0n

Sei più lento dei tuoi colleghi o le tue stime sono più ottimistiche?

7
pjc50

Per produrre software più velocemente, ho scoperto che la cosa migliore da fare è imparare l'API di runtime nel miglior modo possibile. Non digitare la logica dell'elenco quando verrà eseguita un'estensione LINQ; non creare un gruppo di ascoltatori di eventi quando l'associazione funzionerà, ecc.

Per quanto riguarda la stima, ciò deriva dall'esperienza. Puoi utilizzare il software di stima là fuori per aiutarti a capire stime migliori.

Personalmente, ho trovato con gli sviluppatori di livello junior, prendere qualunque sia la loro stima iniziale e moltiplicarla per 2, quindi raddoppiarla. Ciò spiegherà tutto l'apprendimento, le riunioni, il tempo perso, ecc. Gli sviluppatori di livello più avanzato tendono a lavorare con un fattore 2 rispetto alle loro stime.

Spesso, la domanda non è se la tua stima fosse sbagliata. Ha fatto il tuo conto preventivo per tutte le cose giuste? Stai fornendo le tue stime e le scadenze in termini di sforzo di codifica o in termini di tempo di calendario? Pensa a tutto il tempo della tua giornata e a quanto è reale, codifica produttiva rispetto a riunioni, apprendimento, debug, ecc.

7
James Schek

Due cose che potrebbero essere implicite, ma non ho ancora visto tra le risposte qui che un aumento della produttività sono:

  • Usa una sorta di script di compilazione e distribuzione. Compilare, distribuire, riavviare il server delle applicazioni e non deve rischiare di perdere tempo o concentrazione, dovrebbe essere un tipo di cosa con un clic.

  • Avere una sorta di controllo della versione. Dover codificare senza riuscire a ripristinare un cambiamento è come provare a camminare sulle uova

7
Buhb

Mi vengono in mente un paio di idee:

  1. Ottieni altre opinioni sulle tue stime - Ci sono altri sviluppatori a cui potresti chiedere qualcosa del tipo "Ehi, pensi di poter realizzare questo tipo di funzionalità in questo lasso di tempo?" L'idea è che l'input di altre persone può aiutare con precisione in alcuni casi, in quanto qualcuno potrebbe notare un sacco di cose che hai perso nel fare la stima.

  2. Affina la tua abilità di stima: inizia a monitorare la tua stima e perché non lo sei: altri oggetti di lavoro fanno sì che le scadenze non vengano rispettate? Stai costantemente sottovalutando quanto è complicato qualcosa? Stai fornendo un'intera sequenza temporale quando non è pratica, ad es. ciò che viene chiesto è abbastanza vago che la semplice realizzazione di un prototipo richiederà settimane e quindi ci dovrebbe essere una rivalutazione di cos'altro si deve fare? Questo può aiutare di più a sviluppare quell'abilità in modo che se dici che qualcosa impiegherà x ore, puoi avere fiducia in ciò perché l'hai fatto più e più volte. Un modo alternativo per affermarlo è semplicemente pratica, pratica, pratica.

Probabilmente hai già preso in considerazione questi, ma ho pensato che valesse la pena affermarlo per quegli altri là fuori che potrebbero non aver preso in considerazione queste idee.

7
JB King
  1. Conosci la tecnologia dentro e fuori.
  2. Fermare! Pensare! Partire!
  3. Architetto per qualunque cosa possa sorgere, ma implementa solo ciò che è veramente richiesto.
  4. BACIO - Keep It Simple Stupid
  5. Se sta diventando troppo complesso, probabilmente, non è ben pensato. (Torna a 2 e 4)
  6. Non rimanere bloccato in 5. Spesso paga ricominciare da zero (Torna a 2 e 4)
  7. Torna a 1.
7
Rui Craveiro

Penso che la parola chiave qui sia "tempestività". Non hanno detto che eri troppo lento, piuttosto che non eri puntuale.

Nella gestione del progetto, è importante che il manager sia in grado di stimare quando gli articoli di lavoro saranno completi con precisione. Ho il sospetto che il motivo principale per cui i tuoi sforzi non sono stati ritenuti tempestivi è che spesso hai avuto articoli che non sono stati consegnati nei tempi previsti e sono stati consegnati molto più tardi del previsto.

Per migliorare la tua tempestività, potresti voler dedicare più tempo a capire quanto tempo ci vorrà per completare un particolare oggetto di lavoro date le tue abilità, esperienza e dominio. Ciò ti consentirà di fornire stime migliori al tuo project manager. La chiave qui è "migliore" ... si potrebbe consegnare in tempo più frequentemente riempiendo tutto con un fattore di sfumatura, ma ciò che si vuole davvero lottare è una stima più accurata.

Ne discuterò con il tuo manager per vedere se questo è effettivamente il problema. Altrimenti, potresti finire per programmare due volte più velocemente, promettendo cose nella metà del tempo che hai usato, e ancora essere criticato per la tua tempestività perché le tue stime avranno ancora lo stesso fattore di errore.

7
Larry Watanabe

Diventa stabile, resta stabile.

Costruisci qualcosa che implementa un po 'di funzionalità e assicurati che funzioni, end-to-end. Quindi, continua a funzionare mentre aggiungi nuovi bit di funzionalità. Sì, questa è in parte una pratica TDD, ma ha senso anche se non fai TDD.

La logica è che ogni volta che ho visto qualcuno con 2 settimane di codice che non era mai stato stabile, ci vogliono sempre altre 2 settimane per ottenere stabile.

Se rimani stabile, rimuovi quell'incertezza e, se necessario, ti dai anche un modo per scendere in campo vicino alla scadenza.

L'ovvio contro-argomento è che fare questo richiederà più tempo che scrivere semplicemente una volta, poiché farai un lavoro extra stabilizzando il codice non finale. Non lo compro per un secondo. Quando hai un codice che funziona, cambi 5 righe e qualcosa si interrompe, sai esattamente dove deve essere avvenuta l'interruzione.

Se hai 10.000 righe di codice che non hanno mai funzionato e devi trovare una pausa, hai una tonnellata di codice da cercare.

Piccoli cambiamenti incrementali su un sistema che è costantemente stabile FTW. Vai piano per andare veloce.

7
kyoryu

Per me, ottenere una buona produttività è avere un'idea chiara di ciò che stai cercando di ottenere e di come ci arriverai.

7
mdma

Praticamente tutte le risposte sono state dette a morte in numerosi luoghi qui e altrove. O almeno l'ho sentito morire. Impara il tuo IDE, impara a digitare più velocemente, usa i framework, usa la generazione del codice, ecc. Sì, certo, queste cose aiuteranno e dubito che ci siano molti programmatori che ne sono i padroni. Ma essendo il tipo di programmatore che pone queste domande e frequenta siti come Stack Overflow sapevi già queste cose. Volevi semplicemente ripeterli qui o volevi solo sfogarti un po '?

E se fossimo in grado di raggiungere quello stato? Intendo padroneggiare tutti questi suggerimenti? Cosa succederebbe allora? Bene. Immagino che i tempi saranno ridotti ulteriormente. E ancora, torneremo a una percezione della qualità. Voglio dire, il nostro mestiere è decisamente migliorato e diventa sempre più produttivo nel corso dei decenni. Ma la qualità è aumentata in questo periodo (esclusi ovviamente i primissimi anni)?

La mia risposta è semplice: il software di qualità richiede tempo! Puoi scambiare solo uno con l'altro (qualità/velocità). Ma sì, sappiamo tutti che, tuttavia, non siamo onesti riguardo al grado in cui tale compromesso finisce spesso per la velocità della scala. E siamo bugiardi ancora più grandi all'inizio dei progetti!

Dico che non sei in colpa qui. Il problema è che percezione le persone hanno di quanto tempo dovrebbe impiegare un software di qualità. Ci prendiamo in giro credendo di essere in grado di creare software di qualità con i tipi di linee temporali che i nostri manager o persino indoviniamo. Non realizziamo software di qualità. Scriviamo software che funziona ma a volte con lampi di qualità in determinati angoli di un'applicazione.

Quindi cosa possiamo fare al riguardo? Non possiamo semplicemente convincere i nostri capi che dobbiamo raddoppiare o triplicare l'investimento in ciascuno dei nostri progetti. Dico l'esempio. Crea un software davvero eccezionale come progetto secondario. Dedica il tuo tempo e non scendere a compromessi. Nel frattempo presta attenzione a come progredisci. Prendi nota delle attività apparentemente non correlate in cui hai dovuto trascorrere un periodo di tempo inatteso e vedi se riesci a giustificarlo. Contrasta questo con tutti gli altri progetti che hai lavorato. Sii brutalmente onesto con te stesso e tutti gli aspetti di questa analisi. Le cose extra che hai fatto con il tuo software di qualità possono essere trascurate in progetti "reali" al lavoro? Ma forse il tuo tentativo è fallito. Qual è stata la ragione? Ti sei annoiato e ti sei precipitato a fare le funzioni principali? Devo ancora fare qualcosa del genere, motivo per cui concludo questo pensiero con qualche dubbio, ma ho intenzione di provarlo. Vi terrò aggiornati :).

Infine, penso che la maggior parte (se non tutte) le valutazioni delle prestazioni siano distorte e straordinariamente manipolative. Non puoi limitare la qualità e la velocità al 100%. Il tuo capo dovrebbe farti segnare contro uno standard stabilito dall'organizzazione. Lo standard dell'organizzazione sul compromesso tra qualità e velocità. Immaginiamo che OrangeSoft Inc. si aspetti una qualità del 33% e una velocità del 66%. Quindi, se stai scrivendo un codice che ha forse un terzo dei test dell'unità, dovrebbe farlo, ma compensandolo con velocità e tempi di consegna ridotti, dovresti ottenere un punteggio vicino al 100% sulla tua recensione! (Queste sono analogie piuttosto approssimative, ma ottieni il punto). Ma invece, ciò che accade è che Bob scrive codice in modo estremamente veloce ma che è notoriamente difettoso. Quindi nella sua revisione delle prestazioni segnerà 3/5 per qualità e 5/5 per velocità. Carol invece scrive il codice molto più lentamente ma produce molti meno bug. Segna 5/5 per qualità ma 3/5 per velocità. In ogni caso, Bob e Carol sono ancorati al loro rilancio. È possibile per qualsiasi dipendente ottenere un punteggio perfetto? È giusto?

6
Thiru

La tecnica che uso è prototipazione evolutiva

Puoi cercare su Google ulteriori informazioni, ma se la necessità è quella di produrre rapidamente qualcosa, è l'unica strada da percorrere. Inoltre, ha il vantaggio che quando gli utenti dicono che gli piace, hai finito (... e puoi iniziare a fare la documentazione).

5
slashmais

Quali sono i colli di bottiglia del tuo tempo? Trovo che pensare sia il mio solito collo di bottiglia, quindi migliorare la mia velocità di battitura (già buona) non farebbe praticamente nulla. D'altra parte, se la digitazione non è veloce e naturale per te, potrebbe anche rallentarti.

Stai cercando di fare più del necessario? Di solito, un'azienda vorrà molto lavoro da parte tua piuttosto che un lavoro meno ma più raffinato, e l'aggiunta di funzionalità che non verranno utilizzate fa sprecare tempo e denaro senza alcun ritorno.

Sei troppo frettoloso? Sotto la pressione del tempo, le persone spesso risparmiano la progettazione e la pianificazione iniziali, sperando che funzionerà comunque. Spesso no.

Stai gestendo il tempo correttamente? Lo sviluppo richiede pezzi di tempo di pensiero ininterrotto, altrimenti sarai inefficiente e quindi lento.

5
David Thornley

Leggi l'eccellente libro di Neal Ford The Productive Programmer .

È pieno di molti consigli utili.


Modificare:

E, come menzionato altrove, leggi i documenti per i tuoi strumenti. Sto sempre imparando cose nuove per Vim leggendo i wiki di Vim. Allo stesso modo, solo leggere la pagina man di bash o zsh dà sempre nuovi trucchi da usare.

4
Rob Wells

Ho letto qualcosa molto tempo fa sull'ottimizzazione che mi ha davvero colpito. Non ricordo la fonte o le parole esatte, ma la sostanza era: "L'unico modo per far funzionare un programma più velocemente è farlo fare di meno. Qualsiasi altro piano è proprio quello." Lo stesso vale per gli umani. L'esercito ha anche un detto: "La fretta fa spreco". Fare le stesse cose che facciamo ora, ma più velocemente, creerà solo problemi. Ci sono molti piani diversi per diventare più produttivi là fuori e non sto dicendo che non siano efficaci, ma non saranno adattati alle tue esigenze. Stai meglio guardando ciò che fai e trovando le cose che fai che non sono produttive e tagliandole. Qualsiasi altro piano è solo una versione annacquata di quello.

4
Imagist

Ecco cosa funziona per me:

  1. Suddividi il tuo lavoro in piccoli compiti che sono (1) definiti nell'ambito (2) breve - ad es. 2 ore.
  2. Inizia la giornata scrivendoli su un foglio, in ordine. Traccia alcune righe: cose che ti aspetti di fare prima di pranzo, cose che farai entro la fine della giornata, ecc.
  3. Lavora la tua lista, incrociando gli oggetti mentre vai.
  4. Casella di tempo: se qualcosa sta iniziando a trascinare, concediti un limite di tempo alla ricerca prima di chiedere aiuto o risolvere in modo più semplice.
  5. Se possibile, struttura il tuo lavoro in modo da impegnarti pubblicamente in questi tempi - inserendo stime nel tracciamento dei bug, ecc.
  6. Se ti sorprendi a dedicare tempo alla ricerca, alla lettura, ecc., Inverti l'ordine, ad esempio concediti un premio di 10 minuti se completi con successo un'attività di 1 ora nei tempi previsti.

Ho visto diversi commenti che dovresti dedicare meno tempo allo StackTranslate.it. Se lo stai usando bene, Stack Overflow dovrebbe renderti più efficiente, non meno. Evita le discussioni e concentrati sull'utilizzo per svolgere il lavoro.

3
Jon Galloway

Non ripetere te stesso

Riutilizzare le risorse dei vecchi progetti.

Prenditi un giorno per imparare il tuo IDE. Se non fornisce strumenti come snipet, completamento automatico del codice ... prendi in considerazione di ottenerne uno nuovo.

Inserisci scorciatoie per tutto in posizioni chiave in modo da poter accedere alle cose più velocemente.

Ottieni una seconda schermata se non è già così.

Non controllare le tue e-mail troppo spesso.

Prova a concentrarti su una sola attività alla volta. Se ciò non è possibile, tieni traccia di ciò che stai facendo e non perderti tra 15 attività non correlate.

Usa la carta. Quando lavoro ho sempre una versione stampata dei miei compiti su cui posso prendere appunti, cancellare e così via. È molto più veloce di andare su uno schermo diverso per leggere qualcosa o scrivere qualcosa. Alla fine della giornata mi prendo 10 minuti per copiare tutto nel sistema. Mi sono reso conto che mi ha fatto risparmiare un po 'di tempo ogni giorno.

3
marcgg
  1. Sviluppati sempre più come programmatore, ogni giorno ... Scopri i modelli di progettazione!
  2. Usa TDD, ma in modo corretto, i bug che puoi avere nel tuo codice sono la cosa che richiede più tempo.
  3. sa ReSharper :)
3
Denis Biondic

Dal momento che molte delle altre risposte parlano del lavoro di progettazione, mi limiterò ad attenermi al puro aspetto meccanico della codifica più velocemente. La maggior parte di questo è probabilmente ovvio, ma lo dirò comunque poiché noto che molti dei miei collaboratori non fanno alcune di queste cose.

Rimappa la tua IDE scorciatoie da tastiera in modo da poter fare la maggior parte con la mano sinistra. Ciò libera la mano del mouse per una rapida e furiosa definizione del codice/refactoring.

Scopri come navigare nel cursore e selezionare il testo usando una combinazione di CtrlShift, tasti freccia, Home e End.

Di seguito è la mia configurazione C++ (Visual Studio con Visual Assist X). Ho una tastiera norvegese, quindi per favore abbi pazienza:

Alt-Z: cambia tra .h e .cpp

Ctrl-Maiusc- <: sensibile al contesto saltando tra i riferimenti. (<per me è la chiave sinistra di Z, voi ragazzi inglesi non ne avete una. Mappatela su Ctrl-Shift-Z allora.)

Alt- | : Metodo di implementazione. Scrivendo prima l'intestazione e premendo semplicemente Alt- | per tutto il tempo è possibile creare l'intera struttura in pochi secondi. (| per me è la chiave sotto Esc.) Ciò è particolarmente vero se si posizionano i file cpp e header uno accanto all'altro nell'editor di testo in modo che l'intestazione non vieni oscurato ogni volta che esegui l'azione.

Alt-R: Rinomina il simbolo sotto il mio cursore.

Alt-D: aggiunge un modello di documentazione per la funzione selezionata.

Questo, oltre al completamento del codice velocissimo, rende possibile il refactoring della mano sinistra.

3
Nailer

Frammenti di codice, esperienza e entusiasmo incessante. Leggi sempre cose: blog programmatori, libri, letteratura, codice errato di altre persone. Otterrai più veloce se avrai una visione più ampia delle cose. Se riesci a immaginare tutti i tipi di complessi processi in background coinvolti e conosci davvero tutta la complessità del sistema di destinazione.

Il Pragmatic Programmer's Handbook è piuttosto fantastico: riguarda le migliori pratiche e le principali insidie ​​di molti aspetti diversi dello sviluppo del software. L'anatra e la roba di gomma sembrano palesemente nerd e stupidi. Tuttavia, la natura della maggior parte dei problemi di programmazione è che tendiamo a pensare in modo troppo complesso. Sono un grande fan di soluzioni semplici e facili: niente grandi trucchi, niente hack super-eleganti: basta usare le soluzioni più semplici.

Se il tuo team è bravo puoi provare a lavorare in collaborazione: Bespin e alcuni altri framework al giorno d'oggi consentono di modificare un file insieme. È fantastico se ti piace davvero e vedi il tuo collega fare la magia;).

3
wishi

Prova a controllare le tue e-mail con intervalli più lunghi e smetti di usare strumenti social online come Twitter, Facebook, ecc.

Usa questo sfondo .

Prova a lavorare con la vista frontale aperta. Di solito uso la sala conferenze quando è gratis, mi aiuta a concentrarmi!

Prova a lavorare con altri programmatori intorno a te.

3
Adnan Memon

Il trucco non è scrivere il codice più velocemente, ma scrivere il codice di lavoro più velocemente.

Prima viene individuato un bug, minore è lo sforzo per risolverlo: questa è la cosa principale che influenza le prestazioni del programmatore.

Non si tratta della velocità di digitazione o della velocità del compilatore, ma della velocità con cui è possibile identificare i bug e correggerli mentre si procede.

Pertanto, suggerirei di programmare la coppia come un modo per essere più veloci - evita davvero i bug. Quello e lo sviluppo guidato dai test. Avere due paia di occhi rende il doppio più difficile per gli insetti (penso comunque).

Altri consigli sarebbero

  • Cerca di ridurre al minimo i tempi di consegna dei test di codice, questo ovviamente dipende dalla tua piattaforma e dagli strumenti. Se stai lavorando su un sistema incorporato stupido con strumenti scadenti, i tempi di risposta potrebbero essere abbastanza significativi (ad esempio se devi ricostruire un'immagine di sistema e riavviare il dispositivo), VM o simulatori possono aiutarti qui.
  • Se non accoppiare la programmazione, chiedi ad altri occasionalmente revisioni informali del codice, ma solo a interruzioni logiche nel tuo (e si spera) nel loro flusso. Fallo in aggiunta al processo di revisione del codice formale che hai senza dubbio.
  • Mantieni la semplicità: non esagerare con l'ingegnere. Non ne avrai bisogno.
3
MarkR

Scrivi i tuoi strumenti di produttività. Inizialmente potrebbe richiedere del tempo per scrivere, ma il payoff può essere grande nel tempo.

Alcuni strumenti che ho scritto che uso sempre:

  • Un formattatore SQL.
  • Un generatore SQL automatico: basta selezionare le tabelle.
  • Un semplice prioritizzatore di attività, così posso vedere tutte le mie attività in una volta sola.
  • Un promemoria che mi assilla periodicamente.
  • Un'app che accetta testo delimitato e ti consente di trattarlo come un foglio di calcolo e come un testo.
  • Un formattatore di pagine PHP/Javascript/HTML. Una manna dal cielo quando si lavora con il codice degli altri.

Ho scritto molti altri piccoli strumenti ai miei tempi che sono caduti a margine, ma ne è valsa comunque la pena.

3
Jonathan Swift
  1. Mi piace davvero ascoltare la musica mentre programma perché sento che mi rilassa e posso concentrarmi.

  2. Una sedia comoda. Non uso mai i laboratori informatici della mia scuola per programmare perché le sedie da ufficio sono incredibilmente scomode.

  3. Mangia qualcosa in anticipo perché nulla uccide la mia motivazione come la fastidiosa fame.

3
Matt Phillips

Pratica. Quello e mettere le mani sugli strumenti di produttività che ti consentono di andare più veloce.

Ad esempio (non hai menzionato la piattaforma su cui lavori), nell'ambiente .NET, c'è Resharper.

2
Randolph West

Rinegoziare le stime e i tempi. Assicurati che t sia colui che dice quanto tempo impiegherà qualcosa e non soccombere a nessun suggerimento "beh, ne abbiamo bisogno prima" o "che ne dici di un target estensibile".

Leggi l'articolo sulle stime di Joel Spolsky, che sostanzialmente sostiene la suddivisione dell'opera in piccoli pezzi e stimale ciascuno. Se uno di questi viene contato in giorni, scomponili ulteriormente fino a quando non hai tutto stimato in ore.

2
harriyott

Tu e il tuo capo/valutatore dovete determinare quanto tempo dovete effettivamente programmare. Elimina le riunioni, le e-mail, la documentazione, i test e altre interruzioni dal momento in cui dovresti lavorare e vedi cosa rimane.

Prova a monitorare il tuo tempo per ottenere un benchmark di quanto tempo impiegano determinate attività. Ci saranno tempi produttivi (per me all'inizio della giornata o qualsiasi periodo di tempo che ottengo al lavoro senza interruzioni) e tempi improduttivi. Trova una media.

Puoi determinare che una determinata attività richiede 8 ore per programmare, ma dubito che lo farai in un giorno.

Vorrei anche provare a confrontarti con gli altri. La cultura aziendale potrebbe essere quella di impiegare molte ore.

2
JeffO

Beh, penso di non essere lento, ma il lavoro che mi viene dato tende a riempire il tempo disponibile.

Indipendentemente da ciò, spesso ascolto "Accidenti, hai fatto così in fretta", ma non è da essere un programmatore veloce, è da codificare meno.

Penso che il modo principale per codificare meno sia pensare come una DSL. Se non riesci a ottenere il codice generato per te da un preprocessore, allora scrivi un generatore di codice. Non deve essere elegante. L'obiettivo è, se ti viene dato un unico requisito autonomo, ridurre al minimo il numero di differenze di codice sorgente necessarie per implementare tale requisito. Idealmente, quel numero è 1. Se riesci a farlo scendere in media intorno a 3-6, è abbastanza buono. (Non è solo che stai scrivendo di meno. Più piccolo è questo numero, minore è il numero di bug che stai inserendo e che è davvero risparmia tempo.)

Per fare questo, ti consiglio di fare performance tuning , perché poi scoprirai quali pratiche di codifica portano ai maggiori rallentamenti e portano anche a un codice gonfio. In particolare, eccessiva struttura dei dati e programmazione in stile evento/notifica. Queste cose da sole contribuiscono in modo massiccio al volume del codice.

Oggigiorno gran parte del codice è dovuto all'interfaccia utente, soprattutto se è dinamicamente flessibile. Mi sono imbattuto in un modo per fare quella parte, chiamato Dynamic Dialogs , che ha una curva di apprendimento difficile ma riduce il codice dell'interfaccia utente di circa un ordine di grandezza.

Dovrai trovare la tua strada su questo, temo, ma buona fortuna.

2
Mike Dunlavey

Mantieni in ordine la tua vita personale. Dormi molto, mangia sano e assumi vitamine, soprattutto se hai una carenza di ferro. Stai lontano da "il drink" - se sai cosa intendo. E ricorda: "Sia il vino che le donne possono sviare un saggio".

Inoltre, crea modelli del tuo codice e un "generatore di codice" che funzioni usando schemi di espressioni regolari. SE ti ritrovi a copiare e incollare, quindi cercare e sostituire classi simili, automatizzare questo processo. L'ho fatto per i miei progetti PHP, in cui posso creare un'applicazione CRUD, completa di tutti i componenti MVC di base, in base alle mie tabelle di dati: i modelli di dati sembrano tutti uguali tranne che per il tabelle di dati che rappresentano, quindi sono configurate in modelli e utilizzate per generare il mio codice iniziale. Risparmia ore di digitazione.

Infine, informa tutte le persone coinvolte nel progetto che il codice impiegherà da 1/4 a 1/2 volte di più di quanto pensi. Negoziare più spazio per la respirazione per te, all'inizio. "In ritardo" è un termine relativo. Quando si verificano cambiamenti nel progetto, a metà flusso, fai sapere a tutti in anticipo che sono state aggiunte altre 8 ore di lavoro. Un sistema di tracciamento, come quello offerto in "FogBugz", può essere utile a te e ai tuoi manager per prevedere quanto tempo impiegherà a fare qualcosa, sulla base delle esperienze precedenti. Provo a prendere il tatto, "Non era tardi - ho usato la quantità di tempo necessaria per completare questa funzione - ci è voluto solo più tempo del previsto."

Un altro programmatore potrebbe dire: "Beh, avrei potuto farlo più velocemente ..." Forse, forse no, non è un punto su cui valga la pena discutere o battere te stesso - ci sarà sempre un ragazzo "intelligente" che cerca di premere quel pulsante. Ti rallenterà se ci pensi! È sempre una brutta situazione quando è il tuo capo, però. A quel punto, prenderei in considerazione la ricerca di un altro lavoro, perché quel tipo di capo è un JERK arrogante, nel mio libro.

2
JasonMichael

D: Cosa fai per fare di più in periodi di tempo più brevi?

A: Ogni giorno vieni in ufficio e scrivi ciò che vorresti finire su questo in (note adesive) note di Outlook. Inizia a lavorare su quell'ordine degli articoli. Credetemi alla fine, sentireste di aver fatto ciò che avevate programmato ed è una bella sensazione.

2
Cshah

Programma di accoppiamento - questo ha tutti i tipi di vantaggi:

  • ti costringe ad articolare/chiarire il tuo pensiero
  • ti dà un'idea di come funziona qualcun altro, molte idee che puoi adottare/provare
  • apprendere nuove tecnologie direttamente da qualcun altro che le conosce
  • raccogli piccoli consigli sulla produttività da altri. Vedi sempre qualcuno usare un comando di menu che non hai capito prima, o qualche utile comando Unix.
2
ndp

Scrivi meno codice.

Banish Not-Invented-Here e fare buon uso delle librerie/framework/toolkit esistenti per fornire funzionalità comuni (e generalmente non definitive) in modo che sia necessario solo scrivere le novità. Per le parti che devi scrivere tu stesso, costruiscile pensando al riutilizzo in modo da non doverle riscrivere per il prossimo progetto.

Anche se non aumenti il ​​numero di righe di codice di lavoro che produci al giorno, puoi comunque fare di più in meno tempo facendo in modo che ogni riga faccia di più.

2
Dave Sherohman

L'unica cosa chiara che ho scoperto che funziona è liberarsi dalla distrazione. Il che, in alcuni ambienti, è impossibile. Ma essere in grado di concentrarsi sul compito specifico e SOLO su quel compito probabilmente supererà qualsiasi altra cosa. Questi switch di contesto sono davvero dei grandi pozzi.

2
Joe

Giocoleria durante una pausa

Juggling

2
Cornelius

Bere Yerba Mate invece di Caffè

Yerba Mate

2
Cornelius

È sempre la stessa unica decisione, sviluppo veloce vs. qualità, leggibilità, estensibilità. Trascinamento di controlli e file code-behind infiniti (rapidi e sporchi) o modularità, schemi e pratiche (investimento a lungo termine)?

Secondo la mia onesta opinione, tutti devono investire nel modo di codificare a lungo termine. Col passare del tempo, anche lo sviluppo rapido sarà di grande qualità.

Tuttavia, nel caso in cui non avessi compreso la tua richiesta e tu stia cercando risposte in termini di aspetti pratici di sviluppo rapido, come strumenti, generatori di codice e altre cose, la mia opinione è di iniziare a utilizzare Resharper e apprendere il più possibile sul tuo = IDE :)

1
Aggelos Biboudis

UTILIZZA QUADRI !! Non preoccuparti di hardcoding!

1
Koosha

Prima di tutto, non dovresti progettare un sistema basato su alcune riunioni con gli utenti finali. In effetti, non dovresti essere coinvolto nella fase dei requisiti di un progetto, per consentire agli analisti aziendali e agli utenti finali di lavorare.

La seconda fase dovrebbe essere i tuoi requisiti tecnici, è qui che inizierai a lavorare con gli analisti aziendali per trovare una soluzione alle specifiche richieste.

Ora è la parte importante. Assicurati di comprendere sia i requisiti degli utenti finali sia i requisiti funzionali, non serve che tu inizi qualcosa solo per scoprire che non soddisfa le aspettative degli utenti. Parla se non capisci qualcosa.

Ora è tempo di colpire l'editor. Ma il mio approccio è non scrivere mai codice reale, scrivere sempre prima uno stack assoluto di commenti, farlo in pseudo codice se è facile per te, qualunque cosa non contenga, purché sia ​​chiaro e facile da leggere/comprendere.

Una volta che hai fatto i tuoi commenti, puoi iniziare a) scrivere i tuoi casi di test b) scrivere l'implementazione.

A seconda del tuo ambiente, sarebbe meglio iniziare con (a), ma purtroppo la maggior parte inizia con (b) e quindi provare a forzare i test per soddisfare l'implementazione. Parlando francamente, se fossi parte di una grande azienda, ci sarebbe un dipartimento che scriverà i casi di test prima di iniziare a fare qualsiasi cosa.

1
Brett Ryan

Tutti dicono "controllare la posta elettronica", ma considera il tempo che passi a scrivere email altamente tecniche. Posso facilmente passare un'ora a scrivere una singola email. Per risolvere il problema, potrei o 1) non scrivere così tanto, o 2) rimandare le cose tecniche (e quelle che mi richiedono di leggere il codice per rispondere) fino a quando non è assolutamente necessario.

1
Shin

Quando si scrive effettivamente codice, CodeRush aiuta parecchio soprattutto quando si hanno padronanza delle scorciatoie. Inoltre è gratuito: D

1
GaiusSensei

Trascorro un po 'di tempo ogni settimana solo alla ricerca di nuovi modi creativi per fare cose che potrebbero o meno essere direttamente correlate a ciò su cui sto attualmente lavorando. Spesso troverò nuovi trucchi o strumenti di cui non ero mai a conoscenza e che accelerano il mio flusso di lavoro.

1
fscmj

Acquisisci familiarità con il tuo IDE.

Se il tuo IDE è Visual Studio, allora consiglio vivamente il libro di Sara Ford .

1
Jim G.
  • imparare i modelli di design. Ti aiutano a capire i problemi, ti rendono un programmatore migliore -> ti permetteranno di programmare molto più velocemente poiché hai già in mente soluzioni per diversi problemi
  • estrarre parti ripetitive nel programma. Se esiste una logica che si ripete in diversi programmi che scrivi, considera di generalizzarli ed estrarli in una libreria di classi che puoi riutilizzare su nuove applicazioni che scrivi. Standardizza cose: dedica un po 'di tempo a scoprire come certe attività ripetitive vengono eseguite al meglio. Documentare i passi da compiere. La prossima volta saprai esattamente come risolverli/applicarli.
  • Principio KISS
  • La generazione del codice sarà utile (quando sarà disponibile uno strumento utile). I generatori iniziano a guadagnare popolarità, di recente.

Nota: È solo peggio far funzionare le cose !! Come alcuni citano solo per hackerare le cose fino a quando funzionano, ti renderà più veloce solo per il momento. Verranno comunque presenti dei bug che in qualche modo contano anche in termini di velocità di programmazione. Se devo scrivere un po 'di funzionalità e investo a scriverlo bene, avere un buon design, possibilmente ben testato (con i test unitari) e dire che avrò bisogno di mezza giornata. Ma supponi che fosse così e la tua funzione funzioni e non devi toccarla di nuovo. Un altro programmatore, appena focalizzato su un rapido raggiungimento del suo obiettivo, renderà (probabilmente) un cattivo design, a causa della mancanza di test che non considererà (essere consapevoli) del limite, casi eccezionali. Avrà bisogno di 2 ore (diciamo). Arriveranno dei bug, dovrà nuovamente toccare il codice, correggerlo, eventualmente estenderlo (le ore verranno investite di nuovo). Il codice sarà difficile da mantenere, ecc ... riprendendo: alla fine passerà molto tempo e la frustrazione sarà maggiore.

1
Juri

Utilizzare un layout di tastiera ergonomicamente ottimizzato . Alcuni sono persino rivolti ai programmatori, tramite caratteri speciali molto accessibili.

1
knittl

Lavoro da casa. Quando ho una scadenza rigida e devo concentrarmi completamente su un problema, dico al mio capo che lavoro da casa. Questo mi consente di impostare il mio ambiente in modo ottimale, riduce le interruzioni e mi consente di concentrarmi come un raggio laser sul problema.

1
Pedro Estrada

Aumenterai la tua esperienza e memorizzerai l'API molto di più.

I miei giorni di ricerca nel web di frammenti di codice sono molto più brevi ora che ho imparato a programmare meglio.

Oh, potresti anche provare a usare concetti di programmazione funzionale e lamda per abbattere il tuo codice :)

1
Vince

Essere entusiasti di ciò che stai facendo è un ottimo modo per aumentare l'efficienza. Assicurati che sia divertente!

1
Jakob

Penso che abbozzare la tua idea su carta, ricordare quella roba, sia un ottimo modo per concretizzare alcune idee. Come programmatori, professionisti o hobbisti, passiamo moltissimo tempo a fissare lo schermo, che avere un altro sbocco su cui mettere le tue idee è buono. Trovo che grattarsi le cose, disegnare linee affrettate che collegano idee, cerchiare cose, sottolineare, ecc. Si aggiunga all'enfasi su un'idea e può davvero aiutarti a risolvere un'idea molto più velocemente del tentativo di strutturarla subito o dentro qualche forma assistita da computer.

Un'altra cosa che aiuta è la prototipazione di piccole parti. Ho ascoltato un podcast audio TED ieri sera in cui l'oratore stava discutendo della costruzione di piccole strutture con bastoncini di spaghetti e Marshmallow, apparentemente questo è uno studio abbastanza ampiamente usato per testare le capacità di costruzione sociale di piccoli gruppi ... comunque, i gruppi che hanno sempre fatto meglio, oltre agli architetti che capivano il rinforzo e la costruzione di edifici erano bambini perché hanno usato un flusso di feedback costante per ottenere risultati. Penso che puoi anche buttarlo in un'idea di programmazione in cui vedi che fare piccole cose e ottenere risultati non è solo più produttivo, ma molto più divertente e utile rispetto alla costruzione di un gigantesco costrutto e quindi a passare giorni a debug ... che viene ucciso alcune delle mie idee "divertenti" in passato sicuramente.

1
dscher

Quando sono in ufficio e devo mantenere la concentrazione, chiudo il mio client di posta elettronica. Nulla distrugge l'efficienza per me più velocemente della costante tentazione di "dare una rapida occhiata" a qualunque messaggio sia appena arrivato. Ho anche giocato con la tecnica Pomodoro per gestire le interruzioni e mantenere la concentrazione.

1
Tim Trout

Usa generatori di codice ogni volta che è possibile. A volte anche Microsoft Excel (o OpenOffice Calc) risulta essere un potente strumento per la generazione di codice.

0
Canavar

In poche parole, lavagna bianca -> suddivisione in requisiti verificabili in attività (ho usato Team Foundation per tenere traccia di ogni attività e quanto tempo dovrebbe impiegare.)

Usa i test per assicurarti di ottenere ciò che è richiesto, niente di più niente di meno. (Non preoccuparti ancora delle prestazioni.)

Passare da un requisito all'altro e testare dopo ogni operazione. Al termine di ogni attività, è necessario disporre di una stima accurata del tempo rimanente.

Al termine di tutti i requisiti, tornare indietro e "lucidare".

Fare il lavoro delle gambe prima costringe a appianare tutti i requisiti che fanno risparmiare tempo facendo le cose bene la prima volta.

Se eseguito correttamente, ciò dovrebbe consentire di dedicare più tempo allo Stack Overflow :)

In bocca al lupo

0
Brad8118

Ci sono un sacco di grandi idee qui. Per aiutarmi ad entrare nella "zona" uso un timer impostato a intervalli di 27 minuti. Trovo che quando sono in modalità di lavoro è facile lavorare ben oltre il cicalino e lavorare con il flusso è indolore. Arrivare è difficile però.

0
Daver

L'unica cosa che ho notato che influenza maggiormente la mia velocità è la motivazione e il divertimento. Questo può sembrare sfocato, ma quando sono motivato e faccio qualcosa che trovo divertente posso essere estremamente efficace. D'altra parte quando non sono né io mi sento davvero come se dovessi spingere fuori da me ogni singola riga di codice.

Trova i tuoi punti forti, cosa ti motiva davvero e che tipo di attività ti piace fare? E puoi influenzare la tua pianificazione in modo da poterlo fare? Per me è quando riesco a risolvere problemi e problemi di progettazione e quando sento di avere una parte del progetto.

Qualche mese fa avevamo un piccolo progetto che era stato assegnato al nostro piccolo team ed era una scadenza molto importante e molto irrealistica. Tuttavia eravamo tutti molto motivati ​​e ci siamo divertiti molto a farlo e lo abbiamo fatto in tempo, con un cliente felice. La ragione della mia motivazione era che eravamo molto coinvolti nel progetto e dovevamo trovare idee creative per questo. Devo anche fare le parti che mi piacciono molto.

Tuttavia, recentemente sono stato coinvolto in un progetto in cui sono fondamentalmente una scimmia di codice, sto solo facendo compiti anestetizzanti e frustranti, o sto solo avendo roba a correzione rapida il modo più veloce possibile, che so che tornerà e mi morderà duro qualche volta in un futuro prossimo, ed è stato dolorosamente lento.

Allora, quali sono i tuoi punti deboli?

0
Runeborg
  1. Sapere cosa vuoi fare e interessarti
  2. Dedica qualche ora alla ricerca del codice su come farlo
  3. Copia e incolla il codice per ottenere il risultato finale
  4. Lavora su una GUI di base per portare a termine il lavoro, NON SPENDERE IL TEMPO PER FARLO SEMPLICEMENTE
  5. Test e debug
  6. Lavora su una bella gui
0
Matt S.

"Tempestività" non è la stessa cosa di "veloce". Se quello era il problema, la tua valutazione avrebbe dovuto solo dire "lenta". Quindi, prima di prendere la strada che proponi, assicurati di sapere cosa ci si aspetta da te.

Potrebbe significare qualsiasi cosa; potrebbe anche significare che non entri in ufficio fino a 20 minuti dopo i tuoi colleghi o che hai una cattiva gestione del tempo. Potrebbe non avere nulla a che fare con la tua "velocità di programmazione".

Probabilmente passo la maggior parte del tempo a progettare e pianificare; è più facile pianificare le attività da una buona analisi e progettazione, e quindi fornirai stime migliori che si crederanno. Inoltre da un buon design, la codifica diventa un processo molto più semplice e diretto. Inoltre, consente di dividere un'attività e distribuirla tra altri sviluppatori.

0
Clifford

Ho praticamente triplicato la mia velocità di codifica C con VIM .

0
Liran Orevi

CodeRush! Prendilo! Lo adoro!

0
Bobby Ortiz

Scegli editor veloce, compilatore veloce e scrivi software con tempi di esecuzione rapidi. In questo modo puoi commettere dieci volte più errori del normale programmatore e diventare ancora migliore di altri. Questo è probabilmente uno dei motivi per cui le applicazioni Google sono così popolari. Lo sviluppo web è pieno di bug cattivi e scrivere più software su piattaforma buggy è doloroso. Ma il tempo di risposta tra la modifica del codice e la visualizzazione dei risultati è così rapido che è ancora più facile far funzionare quella montagna di spazzatura piuttosto che estendere i programmi c ++. :)

0
AareP

Trascorri più tempo a mettere insieme le cose nella tua mente che di fronte all'IDE. Quando hai un piano, hai già quasi tutto il lavoro già fatto. L'implementazione è solo l'altro 20%. Se rimani bloccato durante la scrittura del codice a causa di problemi specifici della piattaforma, segui il piano e continua a implementare e testare il resto. Alla fine, affronta tutti i punti che hai lasciato alle spalle, risolvendoli uno per uno - è possibile che alcuni siano collegati e risolverne alcuni potrebbe essere sufficiente per capire il resto. In genere utilizzo soluzioni alternative per tali problemi, aggiungendo commenti "// TO CHANGE" in determinati punti del codice e riscrivo quelli che hanno il maggior impatto sulla qualità e sulle prestazioni alla fine, se non ho tempo per risolvere tutto di loro entro la scadenza.

0
luvieere

Costruisci la tua libreria di codici

Ogni volta che codifichi una nuova funzionalità, cerca di mantenerla il più generica possibile, ma non troppo generica. A breve termine questo sarà un po 'più lento, ma a lungo termine man mano che la tua libreria di codice diventa più grande, ogni nuovo progetto sarà completato più velocemente poiché molte applicazioni aziendali hanno esigenze simili (non sempre) ma abbastanza vicine che molte il codice può essere riutilizzato.

0
Darknight

Più veloce non significa meglio. Se riesci ad essere un programmatore più veloce e migliore. Tutto si riduce all'equilibrio. Quanto tempo puoi farlo? Il pensiero, la pazienza e la pianificazione ripagano sempre. A volte "veloce" nel mondo dello sviluppo potrebbe portare a risultati peggiori.

0
Ryuken

Deconstruct. Rompi tutto ciò che stai costruendo in funzionalità più piccole che puoi implementare in più fasi. Quindi, ogni volta che hai fatto uno di quei pezzi più piccoli e hai testato per confermare che non si rompe nulla, dispiegalo e mostralo ai Poteri che sono.

L'uso di piccole iterazioni ti aiuterà spesso a completare il progetto più grande in modo più rapido e migliore, perché ricevi feedback mentre procedi e non dovrai tornare indietro e ripetere altrettanto. Ma anche se non lo fai, stai mostrando progressi costanti, il che ha un solido beneficio psicologico e ripristina la fiducia del tuo manager o cliente.

Anche lo sviluppo guidato dai test aiuta molto con questo approccio. All'inizio può sembrare che scrivere test rallenta prima le cose, ma guadagna quel tempo in bug che eviterai e, a seconda di come li scrivi, i test stessi potrebbero essere un risultato che puoi mostrare ai Poteri che sono e confermare il comportamento dell'app anche prima di scrivere tutto.

0
SFEley

Se stai programmando in C, allora imparare bit hack è un must per diventare un programmatore più veloce. Leggi anche le pratiche di codifica dei migliori ranking su Topcoder.com. Il loro codice è molto piccolo ed efficiente.

0
avd

Diventa più veloce programmatore rallentando durante la progettazione e la programmazione.

  • Pensa a cosa stai facendo.
  • Considera le implicazioni del tuo design.
  • Esegui correttamente la prima volta (prova il tuo codice vigorosamente).

Potrebbe sembrare più lento, ma il tuo throughput sarà più veloce di quei fantini di codice che girano un'iterazione in 4 ore e quindi hanno bisogno di 6 round di QA prima del loro il codice passa.

0
mmc

Ri: Come stimare e attenersi ad esso:

Durante la stima, ricorda legge di Hofstadter e questa battuta: "Tutto richiede più tempo di quanto non faccia". Pensa a quanto tempo dovrebbe durare qualcosa, quindi raddoppia o triplica prima che esca dalla bocca. Ci saranno complicazioni, battute d'arresto, distrazioni, cose che dimenticherai, ecc. Meglio promettere e consegnare troppo che viceversa.

Attenendoti alle stime, fai del tuo meglio per completare il tuo lavoro in modo efficiente. Quando si presentano problemi, comunicare tempestivamente i ritardi. Questo dà a tutti il ​​tempo di adattare le proprie aspettative. Se la tua spiegazione è ragionevole, potresti ricevere più tempo o assistenza o avere distrazioni (come un vicino rumoroso) rimosso dal tuo percorso.

0
steamer25

Le seguenti pratiche sono ben note ma spesso trascurate per vari motivi, spesso a causa di scadenze ravvicinate, quindi meritano di essere menzionate qui (in effetti, si tratta di un meccanismo per passare il tempo in anticipo per evitare di spendere altro dopo):

  • Do sviluppo test-driven; ti aiuterà a scrivere solo la quantità di codice effettivamente richiesta e ti aiuterà a evitare l'introduzione di bug quando aggiungi funzionalità o refactoring

  • Scrivi commenti, ma solo dove il codice è abbastanza complesso da giustificarlo

  • Refactor e semplifica il tuo codice spesso

  • Usa software di controllo del codice sorgente decente (come Git o Mercurial) -se il tuo datore di lavoro usa qualcos'altro, usa il tuo localmente-

  • Commit il codice cambia spesso: per ogni funzione o refactoring, esegui un commit, poiché il ripristino sarà meno costoso per te se qualcosa va storto

  • Non abbiate paura di ramo; Git ha in particolare un meccanismo di ramificazione molto veloce e "sicuro" (ad esempio rispetto a Subversion)

0
Nick Toumpelis

Personalmente penso che sia tutto sulla riusabilità del codice. A meno che tu non faccia ogni volta cose completamente personalizzate, dovresti avere una libreria di funzioni di uso comune a cui puoi rivolgerti. Ho un utils.php in cui ho un'intera "discarica" ​​di funzioni che ho usato su progetti precedenti. Risparmia un sacco di tempo quando devo fare qualcosa di simile.

Buona fortuna e non scoraggiarti. Penso che ci siamo sentiti tutti lenti o "stupidi" a volte. So di averlo fatto!

0
Code Monkey

Utilizzare strumenti di analisi statica.

Ti aiutano a trovare più bug in fase di compilazione che altrimenti dovresti rintracciare in fase di esecuzione.

Soprattutto quando si creano applicazioni multithread sono un vero aiuto.

0
Oliver Weiler

Questi sono tutti buoni suggerimenti. Aggiungerei la mia tecnica di produttività che è sapere come fare le cose non solo con un codice minimo ma con un codice di ridondanza minimo.

In genere ciò significa che minore è la struttura dei dati, meglio è.

Realizzare un codice con una ridondanza minima richiede creatività e volontà di fare le cose in modi che potrebbero imporre una curva di apprendimento. Questo è il prezzo della produttività. Ecco un esempio.

0
Mike Dunlavey