Quando dovremmo smettere di lavorare e creare strumenti?

Come ingegnere del software, siamo sempre desiderosi di ottenere strumenti efficaci per aumentare la nostra produttività. E nel nostro lavoro quotidiano, siamo spesso insoddisfacenti degli strumenti esistenti e vorremmo avere modi migliori come una migliore configurazione degli script GDB, Vim script e alcuni script Python per rendere automatiche le cose noiose.

Tuttavia, in realtà è un compromesso poiché la produzione di strumenti richiede anche tempo ed energia. Non fornisce immediatamente un aumento della produttività. Pertanto, come giudichi se è il momento di smettere di lavorare e di creare alcuni strumenti per alleviare il tuo dolore futuro?

"Costruisco strumenti" quando uno di questi è vero:

1. Il compito mi dà fastidio
2. Il rischio di errore umano nell'attività è troppo grande

Il "rischio" per la seconda opzione non deve essere enorme: il costo di costruzione di un piccolo strumento è generalmente ridotto, quindi se tutto ciò che risparmi è il rischio di eseguire di nuovo una build di 10 minuti una volta alla settimana, di solito si ripaga molto velocemente.

Cerco di rendere gli strumenti il ​​più piccoli possibile: rendi il compito un po 'più semplice ora e forse migliorerò di nuovo la prossima volta.

Ciò significa che ogni volta risolvi solo il dolore più grande e non crei soluzioni a problemi che non ti fanno davvero del male.

Con l'esperienza ho scoperto che solo spingere forte il lavoro grugnito è di solito il più efficiente in termini di tempo. Fare uno strumento è spesso allettante. Rinuncio a resistere quando:

• Lo strumento ha più di uno scopo. Un buon giocatore di scacchi ha compiuto due cose con ogni mossa: bloccare un pezzo avversario e liberare un vescovo. Un principiante probabilmente avrebbe bisogno di due turni per farlo. Allo stesso modo, ritengo che lo strumento farebbe solo una cosa, o con un piccolo sforzo aggiuntivo ne farebbe due, ad esempio aiutando a riparare alcuni file di dati grezzi e anche a creare dati di test artificiali.
• Utilità futura. Potrebbe risparmiarmi tempo per il lavoro di questa settimana, ma è probabile che risparmi tempo a me o a qualcuno per un nuovo progetto la prossima settimana?
• È un buon momento per imparare una nuova lingua, una biblioteca, una tecnica di progettazione o altro, e ho il tempo di farlo. Lo strumento è un benefico effetto collaterale del fare qualcosa di educazione, usando il tempo già concesso per l'educazione.
• Quando abbiamo seri problemi a far funzionare le cose. Come il paracadutismo senza paracadute, dovresti davvero prenderti il ​​tempo per fare o comprare un paracadute. Se non riesci a ottenere risultati sperimentali significativi o la nuova app Web non funziona affatto, devi semplicemente fermarti e creare o acquistare uno strumento per misurare ciò che non puoi vedere, guidare i componenti o sostituire parte del sistema. Quando il lavoro è totalmente sospeso e necessita di uno strumento, non mi interessa l'utilizzo futuro o multiplo. La necessità pesa abbastanza.

La mia regola empirica è che quando devo fare qualcosa per la terza volta, è tempo di scrivere una piccola sceneggiatura per automatizzarla o ripensare il mio approccio.

A questo punto non sto realizzando uno "strumento" completo, solo un piccolo script (di solito bash o python; anche perl funzionerebbe, o anche PHP) che automatizza ciò che ho fatto manualmente prima. È fondamentalmente un'applicazione del principio DRY (o del principio Single Source Of Truth, che è essenzialmente la stessa cosa) - se devi cambiare due file sorgente in tandem, ci deve essere una verità comune che condividono, e che la verità deve essere presa in considerazione e archiviata in un posto centrale. È fantastico se riesci a risolverlo internamente mediante il refactoring, ma a volte questo non è fattibile, ed è qui che arrivano gli script personalizzati.

Successivamente, lo script può evolversi o meno in uno strumento completo, ma di solito inizio con uno script molto specifico con molte cose codificate.

Odio il lavoro grugnito con passione, ma credo fermamente che sia un segno di design cattivo o errato. Essere pigri è una qualità importante in un programmatore ed è meglio essere il tipo in cui si fa di tutto per evitare il lavoro ripetitivo.

Certo, a volte il saldo è negativo: passi tre ore a riformattare il tuo codice o a scrivere uno script per farti risparmiare un'ora di lavoro ripetitivo; ma di solito, l'equilibrio è positivo, tanto più se si considerano costi che non sono direttamente evidenti: fallimento umano (gli esseri umani sono davvero pessimi nel lavoro ripetitivo), base di codice più piccola, migliore manutenibilità a causa di ridondanza ridotta, migliore autocertificazione, futuro più veloce sviluppo, codice più pulito. Quindi, anche se il saldo appare negativo in questo momento, la base di codice aumenterà ulteriormente e lo strumento che hai scritto per generare moduli Web per tre oggetti dati funzionerà comunque quando avrai trenta oggetti dati. In base alla mia esperienza, il bilancio è generalmente stimato a favore del lavoro grugnito, probabilmente perché i compiti ripetitivi sono più facili da stimare e quindi sottovalutati, mentre il refactoring, l'automazione e l'astrazione sono percepiti come meno prevedibili e più pericolosi, e quindi sopravvalutati. Di solito si scopre che l'automazione non è poi così difficile.

E poi c'è il rischio di farlo troppo tardi: è facile riformattare tre nuove classi di oggetti di dati in forma e scrivere uno script che genera moduli web per loro, e una volta fatto, è facile aggiungere altre 27 classi che lavora anche con la tua sceneggiatura. Ma è quasi impossibile scrivere quello script quando hai raggiunto un punto in cui ci sono 30 classi di oggetti dati, ognuna con moduli web scritti a mano e senza alcuna coerenza tra loro (aka "crescita organica"). Mantenere quelle 30 classi con le loro forme è un incubo di codifica ripetitiva e ricerca sostitutiva semi-manuale, la modifica di aspetti comuni richiede trenta volte il tempo necessario, ma scrivere una sceneggiatura per risolvere il problema, che sarebbe stata una pausa pranzo senza sforzo quando il progetto è iniziato, ora è un terribile progetto di due settimane con la terribile prospettiva di un mese di seguito che consiste nel correggere bug, educare gli utenti e forse anche rinunciare e tornare al vecchia base di codice. Ironia della sorte, scrivere il pasticcio di 30 classi ha richiesto molto più tempo di quanto avrebbe fatto la soluzione pulita, perché avresti potuto usare il comodo script per tutto quel tempo. Nella mia esperienza, l'automazione del lavoro ripetitivo via troppo tardi è uno dei maggiori problemi in progetti software di grandi dimensioni di lunga durata. perché avresti potuto usare la comoda sceneggiatura per tutto quel tempo. Nella mia esperienza, l'automazione del lavoro ripetitivo via troppo tardi è uno dei maggiori problemi in progetti software di grandi dimensioni di lunga durata. perché avresti potuto usare la comoda sceneggiatura per tutto quel tempo. Nella mia esperienza, l'automazione del lavoro ripetitivo via troppo tardi è uno dei maggiori problemi in progetti software di grandi dimensioni di lunga durata.

Ho appena ricordato questo:

Il problema con questo ovviamente è che nella situazione di vita reale non è possibile misurare facilmente quei dati per selezionare la cella giusta nella tabella. E come è stato menzionato in altre risposte, ci sono altre variabili (il rischio di errore, l'attività è troppo noiosa per farlo anche una volta, ...) è necessario aggiungere all'equazione.

Quindi la mia risposta è che dipende davvero dalla situazione e non puoi sperare di ottenere una risposta "corretta" per tutte le situazioni. Dopo tutto la vita sarebbe noiosa se avessimo libri di cucina per tutto.

Questo è un grosso problema nella mia esperienza. La costruzione di strumenti viene solitamente lasciata a uno sviluppatore motivato che interrompe il lavoro per costruire lo strumento. Questo spesso interferisce con lo sviluppo anche se fornisce valore. La costruzione di strumenti deve essere vista come parte integrante del "Processo" di sviluppo.

Ricordo di aver partecipato a recensioni di codice in cui errori di intestazione avrebbero comportato la pianificazione di un'altra recensione. Molti di questi potrebbero essere stati rilevati da uno strumento. ad es. conteggi sloc errati, requisiti mancanti, errori di formattazione. Il mio strumento scritto in perl ha generato l'intestazione dal codice consegnato e i requisiti convalidati da un database Oracle. Non faceva parte del nostro "Processo", quindi nella costruzione a breve termine lo strumento era considerato un ritardo nella consegna.

L'intero team deve fermarsi periodicamente e vedere dove ci sono sforzi manuali che possono essere automatizzati dalla creazione di strumenti.

Tutte le altre risposte sono buone, ma aggiungerei un motivo in più per cui è utile dedicare tempo alla creazione di piccoli strumenti (e alla personalizzazione di .vimrc, .emacs ecc.):

A volte rimani "creativamente o motivatamente" bloccato in una carreggiata e facendo qualcosa, qualunque cosa, "farà scorrere di nuovo i succhi" (per mescolare metafore). Idealmente sarebbe qualcosa che spinge in avanti il ​​progetto in modo produttivo, ma se è un po 'tangenziale e ti ispira, allora va bene lo stesso.

Potresti non fissare uno schermo vuoto, ma semplicemente avere problemi a vedere i progressi che stai facendo su un grosso compito. In quella situazione, spuntare qualcosa di tangibile può impedirti di sentire che non stai arrivando da nessuna parte.

Una variazione su questo è quando continui a pensare a qualcosa che dovrebbe essere sul "back burner" - solo prendere un momento e farlo lo toglierà dalla tua mente e ti libererà per rimettere tutta la tua energia nel compito principale.

Dipende da ciò che consideri come strumento. Probabilmente ne faccio un sacco in modi che altri sviluppatori considererebbero frivoli ... Perché li faccio praticamente per tutto tranne che per i comandi di base del filesystem.

Uso 2 razionali per supportarlo.

• È un'estensione del principio DRY. Se vogliamo ripetere qualcosa, lo sforzo manuale è l'uso meno efficace delle risorse umane.
• È un modo efficace per registrare ciò che ho fatto, quindi se ho costruito qualcosa allora io (o qualcun altro) potrei voler fare riferimento a come l'ho fatto settimane o mesi dopo e mantiene il registro del lavoro con il progetto.

Occasionalmente diventano strumenti più grandi e ottengono funzioni interattive, ma in caso contrario hanno comunque valore come record.