Come può uno sviluppatore valutare l'efficacia del suo flusso di lavoro? [chiuso]

2

Questa domanda è stata a mio avviso per probabilmente 10 anni. Da quando ho iniziato a programmare per vivere. E ho visto più discussioni sulla buona misura, distrazioni, essere nella zona, ecc. Ma non ho visto collegamenti ad alcune informazioni / ricerche che potrebbero dare una misura / strumento oggettivo di autovalutazione per capire come stai davvero facendo .

Ciò che costantemente mi infastidisce è che penso di non passare abbastanza tempo sulla programmazione e che le ore di lavoro effettive non sono 8 su 8, ma meno, con alcuni giorni addirittura super inefficaci, esattamente come in questo articolo .

Ci sono alcune metriche espresse come linee di codice al giorno, con alcune fonti che citano 1.5 essere buone e alcune fonti che indicano 500 al giorno come normali, ma questo, ancora una volta, è una metrica completamente non valida per quanto posso vedere.

Quindi alla fine della giornata, hai un incarico, lo fai, ma una parte del tempo evapora in un modo del tipo "wth stavo facendo" in un certo senso. E-mail, basta guardare il codice, pensare, dipingere un'immagine mentale del codice nella tua testa, fluttuare da qualche parte, ripensare a come le cose avrebbero potuto fare in modo più efficace, ecc.

E a causa di ciò, non sono mai sicuro di dover fare qualcosa al più presto, di mantenere i rilanci in arrivo, o sono paranoico, o è solo normale.

L'unica mezza misura che ho trovato fino ad ora, è vedere la quantità di codice prodotta da altri sviluppatori-vs-codice che produco. E questo di solito galleggia intorno allo stesso numero. Ma quando guardo il mio codice, o altri codice, ho sempre la sensazione che potrebbe essere fatto 10 volte più veloce.

Inoltre, il code crunching non sembra funzionare, o sembra causare un esaurimento se non gestito correttamente.

Quindi conosci un buon approccio di autovalutazione per vedere se sei inefficace / efficace? Come appesantisci il lavoro che hai svolto?

    
posta Coder 24.02.2012 - 05:03
fonte

5 risposte

3

Non so se esiste un "metodo migliore documentato", ma ti suggerisco di provare i test A / B personali. Scegli la tua metrica preferita - linee codificate, progressi verso gli obiettivi realizzati, funzionalità implementate, ecc. - e poi cambia le cose in un programma bisettimanale. Inizia a utilizzare la tecnica Pomodoro . Prova a utilizzare più monitor. Prova a bloccare l'accesso a Internet per perdere tempo. Prova a fare esercizio a metà giornata. Prova un po 'di bazillion o di mode che si promuovono aumentando la produttività e vedi quali funzionano per te.

Ci vorrà molto tempo, certo, ma è tutto durante il tuo normale lavoro comunque, e nel peggiore dei casi hai provato un sacco di cose diverse e ora sai che sei altrettanto (dis) produttivo importa quali usi.

    
risposta data 24.02.2012 - 05:09
fonte
2

Hai ragione quando le linee di codice sono una cifra completamente priva di significato. Come ha detto uno degli hacker barbuti UNIX: "Oggi è stata una giornata molto produttiva. Ho cancellato 1000 righe di codice".

Hai anche ragione sul fatto che la modalità crunch è per lo più controproducente. È possibile forzare se stessi a digitare più velocemente, ma questo inevitabilmente ha il costo di pensare al tuo codice. Costruirai un debito tecnico e dovrai pagarlo in un modo o nell'altro. La modalità di crunch permanente è una ricetta perfetta per codice non gestibile.

I tuoi problemi non sembrano essere di produttività, ma piuttosto di gestione. Sembra che tu sia gestito male, o per niente. È necessario un elenco di attività con priorità e stime di tempo. Le stime del tempo devono essere le tue (sei la persona più qualificata per stimare quanto tempo impieghi a fare qualcosa), la priorità deve essere fatta dalla persona responsabile della gestione del progetto. Con questi due in posizione, è sia chiaro quale sia il tuo prossimo compito, e quando avrai a che fare con il compito X. Assicurati di includere tutto il sovraccarico (pensare, fissare, ricercare, comunicare) nella tua stima. Inoltre, misura il tempo necessario per completare l'attività e utilizza queste informazioni per adattare le stime future: le tue stime saranno più affidabili nel tempo se lo fai.

Informazioni sul problema "effettiva codifica vs. sovraccarico"; non aspettatevi di programmare attivamente 8 ore al giorno, semplicemente non è realistico. Spendere 1/3 o più del budget di un progetto sul design non è inusuale, e non è una cosa negativa neanche - le modifiche al design sono generalmente più economiche delle modifiche al codice. Aggiungete a questo overhead di autogestione, blocchi mentali (ne abbiamo tutti), interruzioni, sovraccarico di comunicazione, documenti, mantenendo aggiornato il vostro ambiente di sviluppo e tutte quelle altre fastidiose piccole seccature, e scenderete rapidamente sotto i 50 % della giornata lavorativa spesa per la programmazione. Di questi il 50%, probabilmente trascorri la metà o più pensando, leggendo il codice, ricercando, ecc., Quindi trascorrere tre ore o meno al giorno lavorativo sulla programmazione effettiva non è affatto insolito. La programmazione è un gioco mentale, non è un lavoro da catena di montaggio.

Quindi, come valuti la tua produttività? Le prestazioni del programmatore non sono generalmente quantificabili, quindi dovrai andare con le figure soggettive:

  • Soddisfazione del cliente
  • Soddisfazione del datore di lavoro
  • Affidabilità del software che scrivi
  • Correttezza (il tuo software soddisfa le specifiche? produce costantemente i risultati corretti?)
  • Robustezza (il tuo codice gestisce gli errori con garbo? contiene un numero basso di bachi critici?)
  • Mantenibilità del codice (è facile e sicuro cambiare il tuo codice?)
  • Usabilità (gli utenti trovano la tua applicazione facile da usare?)
  • Crescita personale (la qualità soggettiva del tuo lavoro aumenta nel tempo?)
  • ...
risposta data 24.02.2012 - 09:54
fonte
0

Non sembra riferirsi all'obiettivo del codice che stai scrivendo. Sono dell'opinione che, se vuoi valutare quanto sei efficace nello scrivere il codice, devi valutarlo in base a quanto bene corrisponde ai requisiti che ti vengono forniti. Non vedo questo come una valutazione del flusso di lavoro - una valutazione del tuo flusso di lavoro dovrebbe coprire a) ti lascia costantemente stressato, b) ti permette di scrivere un codice efficace che soddisfi le tue esigenze c) spendi un sacco di time firefighting / bug fixing d) progetta in modo efficace in anticipo e) dividi il tuo tempo per il design / codice / test in modo tale da ottenere un equilibrio che non ti costringa a impiegare molto tempo a correggere bug, antincendio e sottolineando. f) hai gli strumenti giusti per aiutarti a fare il tuo lavoro efficacemente e se non riesci puoi riconoscere ciò che manca

In breve, è necessario distinguere tra valutare il flusso di lavoro (processo) e l'output. Sono due cose diverse, anche se è probabile che un flusso di lavoro efficace migliori la capacità di generare output.

Il conteggio delle righe di codice è un pessimo modo di misurare l'output o il flusso di lavoro. È un'idea contabile che vede il codice come widget. Il codice non è un widget, tuttavia è un modo di fare le cose ea volte qualcosa di importante può essere fatto in 2 righe di codice in modo più efficace rispetto a 1000 righe di codice. Una metrica LOC fallisce sotto questo aspetto e non è raro

Lavoro su un sistema in cui brevità e velocità sono vitali. Ma a causa dei requisiti aziendali, non è sempre consigliabile utilizzare almeno LOC come parametro. Ciò che conta è l'efficacia rispetto ai requisiti aziendali e molte persone hanno difficoltà a misurarlo.

    
risposta data 24.02.2012 - 09:36
fonte
0

Puoi valutare una tecnica di miglioramento della produttività solo se, durante la tua sperimentazione, tutto il resto rimane costante. Questo è ovviamente impossibile se si ha un carico di lavoro vario.

Il mio consiglio sarebbe quello di trovare una serie di problemi di pari difficoltà (ad esempio, esaminando i problemi del progetto Eulero) e poi provare diverse tecniche su diversi problemi, misurando il tempo di completamento.

È importante che la tecnica che usi sia l'unica variabile che cambia, quindi cerca di eliminare ogni altra variazione. Forse potresti eliminare la vigilanza dall'equazione facendo solo uno o due problemi al giorno prima di qualsiasi altra cosa.

Ripeti finché i risultati non sono conclusivi.

    
risposta data 24.02.2012 - 09:37
fonte
-1

Il conteggio delle righe di codice è una delle metriche più inutili che riesca a pensare. Sembra che ci sia più un problema prioritario in gioco che efficacia.

    
risposta data 24.02.2012 - 05:40
fonte

Leggi altre domande sui tag