Quando dovremmo smettere di lavorare e creare uno strumento?

I "make tools" quando uno di questi è vero:

1. L'attività 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 costruire un piccolo strumento di solito è piccolo, quindi se tutto ciò che si salva è il rischio di eseguire nuovamente una build di 10 minuti una volta alla settimana, di solito si ripaga molto velocemente.

Cerco di rendere gli strumenti il più piccoli possibile: basta semplificare l'operazione ora e magari migliorare la volta successiva.

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

Con l'esperienza ho scoperto che solo spingere al massimo il lavoro da grugnito è solitamente il più efficiente in termini di tempo. Fare uno strumento è spesso allettante. Rinuncio resistendo quando:

• Lo strumento ha più di uno scopo. Un buon giocatore di scacchi ha compiuto due cose a ogni mossa: blocca un pezzo avversario e libera un alfiere. Un principiante avrebbe probabilmente bisogno di due turni per farlo. Allo stesso modo, considero se lo strumento farebbe solo una cosa, o con un piccolo sforzo extra fare due, ad es. aiuta a correggere alcuni file di dati grezzi e anche a creare dati di test artificiali.
• utilità futura. Potrebbe farmi risparmiare tempo per il lavoro di questa settimana, ma è probabile che mi salvi o qualcuno a tempo per un nuovo progetto la prossima settimana?
• È un buon momento per imparare una nuova lingua, una biblioteca, una tecnica di progettazione o qualsiasi altra cosa, e ho il tempo di farlo. Lo strumento è un utile effetto collaterale di fare qualcosa di educazione, usando il tempo già concesso per l'educazione.
• Quando abbiamo problemi seri nel far funzionare le cose. Come paracadutismo senza paracadute, dovresti davvero prendere il tempo per fare o comprare un paracadute. Se non riesci a ottenere risultati sperimentali significativi, o la nuova app Web non funzionerà affatto, devi solo interrompere e creare o acquistare uno strumento per misurare ciò che non puoi vedere, guidare i componenti o sostituire una parte del sistema. Quando il lavoro è completamente sospeso e necessita di uno strumento, non mi interessa l'uso futuro o l'uso multiplo. La necessità pesa abbastanza.

La mia regola generale è che quando devo fare qualcosa per la terza volta, è tempo di scrivere un piccolo script per automatizzarlo o di ripensare il mio approccio.

Non sto facendo uno "strumento" completo a questo punto, solo un piccolo script (di solito bash o python, anche perl funzionerebbe anche, o anche PHP) che automatizza quello 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 qualche verità comune che condividono, e che la verità deve essere scomposta e archiviata in un unico punto centrale. È fantastico se riesci a risolverlo internamente tramite il refactoring, ma a volte non è fattibile, ed è qui che arrivano gli script personalizzati.

Successivamente, lo script potrebbe non evolversi in uno strumento completo, ma di solito inizio con uno script molto specifico con un sacco di cose codificate in esso.

Odio lavorare con passione, ma credo anche strongmente che sia un segno di design cattivo o errato. Essere pigri è una qualità importante in un programmatore, ed è meglio che tu vada di gran lunga per evitare il lavoro ripetitivo.

Certo, a volte il saldo è negativo - trascorri tre ore a refactoring del codice o scrivendo uno script per risparmiare un'ora di lavoro ripetitivo; ma di solito, il saldo è positivo, soprattutto se si considerano i costi non direttamente evidenti: errore umano (gli umani sono veramente cattivi nel lavoro ripetitivo), basebase più piccola, migliore manutenzione a causa della ridotta ridondanza, migliore autodocumentazione, futuro più veloce sviluppo, codice più pulito. Quindi, anche se il saldo appare negativo adesso , il codebase crescerà ulteriormente e quello strumento che hai scritto per generare moduli web per tre oggetti dati funzionerà ancora quando hai trenta oggetti dati. Nella mia esperienza, l'equilibrio è generalmente stimato a favore del lavoro dei grugniti, probabilmente perché i compiti ripetitivi sono più facili da stimare e quindi sottovalutare, mentre il refactoring, l'automazione e l'astrazione sono percepiti come meno prevedibili e più pericolosi e quindi sovrastimati. Di solito risulta che automatizzare non è poi così difficile.

E poi c'è il rischio di farlo troppo tardi: è facile da refactoring tre nuove classi di oggetti dati in forma e scrivere uno script che genera moduli Web per loro, e una volta che hai fatto, è facile aggiungere altre 27 classi che funzionano anche con il tuo script. Ma è quasi impossibile scrivere quello script quando hai raggiunto un punto in cui ci sono 30 classi di oggetti di dati, ognuno con moduli Web scritti a mano e senza alcuna coerenza tra loro (a.k.a. "crescita organica"). Mantenere quelle 30 classi con le loro forme è un incubo di codice ripetitivo e ricerca-sostituzione semimanuale, cambiare gli aspetti comuni richiede trenta volte il tempo necessario, ma scrivere una sceneggiatura per risolvere il problema, che sarebbe stata una pausa pranzo no -brainer quando il progetto è iniziato è ora un terribile progetto di due settimane con la temuta prospettiva di un mese di conseguenze consistenti nel correggere bug, educare gli utenti e, eventualmente, anche abbandonare e ritornare alla vecchia base di codice. Ironia della sorte, scrivere il pasticcio di 30 classi ha richiesto molto più tempo di quello che avrebbe avuto la soluzione pulita, perché avresti potuto guidare il comodo script per tutto quel tempo. Nella mia esperienza, automatizzare il lavoro ripetitivo troppo tardi è uno dei maggiori problemi nei progetti software di lunga durata.

L'ho appena ricordato:

Ilproblemaconquesto,naturalmente,èchenellasituazionedivitarealenonpuoifacilmentemisurarequeidatiperselezionarelacellagiustanellatabella.Ecomeèstatomenzionatoinaltrerisposte,cisonoaltrevariabili(ilrischiodierrore,ilcompitoètropponoiosoperfarloanchesolounavolta,...)ènecessarioaggiungereall'equazione.

Quindilamiarispostaèchedipendedavverodallasituazioneenonpuoisperarediottenereunarisposta"corretta" per tutte le situazioni. Dopo tutto, la vita sarebbe noiosa se avessimo libri di cucina per ogni cosa.

Questo è un grosso problema nella mia esperienza. Generalmente la costruzione di strumenti viene lasciata a uno sviluppatore motivato che interrompe il lavoro per creare 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 revisione. Molti di questi potrebbero essere stati rilevati da uno strumento. per esempio. conteggi 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 nel breve periodo in cui lo strumento è stato considerato ritardato.

L'intero team ha bisogno di fermarsi periodicamente per vedere dove ci sono sforzi manuali che possono essere automatizzati con la creazione degli strumenti.

Tutte le altre risposte sono buone, ma aggiungerei un altro motivo per cui è prezioso dedicare del tempo a creare piccoli strumenti (e personalizzare i tuoi .vimrc, .emacs ecc.):

A volte ti senti creativamente o motivatamente "bloccato in un solco" e facendo qualcosa, qualsiasi cosa, "farà scorrere nuovamente il succo" (per mescolare le metafore). Idealmente sarebbe un qualcosa che spinge in avanti il progetto in modo produttivo, ma se è un po 'tangenziale e che ti ispira, allora va anche bene.

Potresti non star fissando uno schermo vuoto, ma invece hai semplicemente difficoltà a vedere i progressi che stai facendo in un grande compito. In quella situazione spuntare qualcosa di tangibile può farti sentire come se non arrivassi 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 mettere tutta la tua energia nel compito principale ancora una volta.

Dipende da ciò che consideri come uno strumento. Probabilmente ne faccio un sacco in modi che altri sviluppatori considererebbero frivoli ... Perché li faccio per circa tutto tranne 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 avessi costruito qualcosa allora io (o qualcun altro) potrebbe voler riferirsi a come ho fatto settimane o mesi più tardi e mantiene il log del lavoro con il progetto.

Talvolta diventano strumenti più grandi e acquisiscono funzioni interattive, ma se non lo fanno hanno ancora un valore come record.