Come devono essere gestiti gli script "usa e getta"?

The only other option that I can come up with is to let developers store the scripts in a special part of version control, in which there is no quality control (much like GitHub Gists). The risk is that others will not be able to use the code because they cannot find or understand it.

How could this problem be solved? Or should it not be solved?

Il problema non può essere risolto.

C'è una grande differenza tra la condivisione del codice in base al passaparola quando senti che un collega si trova di fronte a una particolare difficoltà e lo condividi semplicemente inserendolo in una libreria a cui tutti hanno accesso.

La differenza è che, nel primo caso, stai interpretando il ruolo del creatore e del bibliotecario con conoscenza implicita del problema e del codice che hai, il che lo risolve, mentre nel secondo caso, quei ruoli non sono presenti.

I tuoi standard generali di codice possono essere progettati per eliminare il ruolo del bibliotecario nella tua azienda e assicurare che la biblioteca rimanga accessibile da tutti.

Con un enorme edificio di codice di lunga durata (come caratterizza la maggior parte dei prodotti software di base), il tempo e lo sforzo sono giustificati per preservare la capacità di più generazioni di lavoratori di continuare a lavorare con l'intero edificio. Nelle aziende con un elevato turnover di personale, una "generazione" di personale può essere ridotta a uno o due anni.

Ma ovviamente, il raggiungimento di questi standard "senza bibliotecari" ha il prezzo di un enorme dispendio di tempo e risorse per coloro che creano la biblioteca in primo luogo e richiede ancora tempo e sforzi significativi da coloro che in seguito verranno a utilizzare e navigare libreria (sebbene non lo stesso sforzo di ricreare da zero l'intero edificio, che potrebbe aver già richiesto più generazioni).

D'altra parte, la maggior parte di questi script veloci e sporchi verrà scritta per ottenere rapidamente operazioni semplici, magari su base una tantum. Non sono creazioni complesse o robuste.

Dici che "risparmiano tempo", ma naturalmente questo rimane vero solo quando non sono scritti secondo standard molto più elevati, senza bibliotecari. Sono le maschere di costruzione personali di coloro che le hanno create: le leve temporanee e l'impalcatura dello sforzo umano, non il prodotto finale durevole.

Dovrebbe essere possibile controllarli in controllo di versione, in modo che il creatore abbia un posto dove archiviarli e conservarli sistematicamente - ma dovrebbe anche essere chiaro che rappresentano il prodotto su cui il creatore ha ancora supervisione.

Se puoi leggere il loro codice e vedere immediatamente cosa fa, tanto meglio. Ma è la biblioteca personale del creatore e non sono tenuti allo standard che le altre persone devono essere in grado di vedere ciò che fa senza fare riferimento al creatore.

Questo non è un "rischio" a carico della squadra, tanto più che la disposizione degli effetti personali in casa è un "rischio" per coloro che potrebbero voler chiedere di prenderli in prestito. Al contrario, dover indicizzare l'intero contenuto della tua casa, disporli in un modo prestabilito e fornire un manuale di istruzioni per ogni articolo, è un serio rischio per il tuo uso efficiente in corso della casa.

Sento il tuo dolore. Direi che avere una parte separata del repository è probabilmente l'opzione per la memorizzazione di questi script. Tuttavia, questo risolve solo una parte del problema. Ora li hai archiviati da qualche parte, ma non è un buon modo per i tuoi colleghi di sapere che ci sono.

Nella mia esperienza di consulente per un'azienda in cui gli script sono abbondanti e scritti per diversi clienti e di solito sul sito, scoprire cosa è già lì è difficile!

Dovresti trovare un modo per condividere ciò che hai creato.

Nella nostra azienda, poiché non siamo così grandi, controlliamo le cose come gli script nel nostro repository, ma inviamo anche un'email a livello aziendale per informare i nostri colleghi di una nuova soluzione. In questo modo, almeno tutti sanno cosa c'è già là fuori e chi contattare se ne hanno bisogno.

Altri hanno già spiegato come e perché assicurare che i tuoi script 'usa e getta' possano essere fatti abbastanza bene da andare nel repository. Devo solo entrare e dire che è altrettanto importante garantire che, se non sono abbastanza bravi da andare nel repository, devono essere buttati via.

Per dirla in un altro modo, sono abbastanza buoni da andare nel repository o non lo sono e devono essere buttati fuori. Se non vengono buttati fuori, diventano un onere di manutenzione non gestito e, alla fine, ingestibile.

Innanzitutto vorrei iniziare dicendo che se i tuoi sviluppatori sono riluttanti a fornire codice a causa dei tuoi standard, i tuoi standard sono troppo rigorosi o dovresti migliorare la qualità e l'etica del lavoro dei tuoi sviluppatori. Se questi sono piccoli script, non ci dovrebbero essere molto sforzo supplementare richiesto di mettere un paio di commenti in. Gli sviluppatori dovrebbe essere la scrittura di codice leggibile per default, e se non lo sono, il problema vero sta nella vostra personale.

Per rispondere alla tua domanda, hai alcune opzioni:

1. Se gli script sono abbastanza generici, è possibile ospitarli in un repository separato. Se gli script sono molto incentrati sul progetto, questo potrebbe non funzionare.
2. Ospita gli script nello stesso repository in una directory a parte loro. Per esempio, alla mia azienda i nostri progetti di solito hanno una directory cli/ che contiene una manciata di script della riga di comando, di solito pensati per essere eseguiti una tantum per inizializzare ambienti, importare alcuni dati, e così via.
3. Questa potrebbe essere una pessima opzione a seconda di quali sono le tue esigenze, ma se hai qualche ragione non puoi impegnare codice che non segue espressamente i tuoi standard e / o hai sviluppatori che non sono disposti a scrivere script se devono seguire quegli standard, è possibile ospitare i file su un'unità condivisa o qualcosa di simile. Questa potrebbe non essere la soluzione migliore se hai bisogno di tutti i benefici del controllo del codice sorgente - tuttavia può essere utile in alcune circostanze (grazie a Doc Brown per questa modifica)

Con una delle due prime opzioni, puoi scegliere di applicare più standard di codifica rilassati sull'altro repository o sulla directory.

Inizia a formalizzare i tuoi processi.

Non fornisci molti indizi su ciò per cui questi script vengono utilizzati, ma presumo che tu abbia varie varie attività di implementazione e manutenzione, o correzioni di dati comuni che vengono distribuite agli sviluppatori perché sono quelle con sufficiente conoscenza per sistemare le cose?

Dovresti cercare di diventare più professionale a riguardo.

• Scrivi quali sono queste attività e i passaggi per completarle.
• Pubblica quel documento su qualche sito Web o intranet interno
• Registra la frequenza con cui viene eseguita l'attività e quanto tempo impiega in un sistema di biglietteria.
• Automatizza i passaggi manuali con un programma, ma non saltare il controllo del codice sorgente, test, supporto ecc. Sviluppa uno strumento di amministrazione adatto.
• Cerca di utilizzare strumenti di terze parti anziché sviluppare le tue soluzioni laddove possibile. Renderà più facile per i nuovi assunti

L'obiettivo è rendere il processo una funzione puramente ripetitiva che chiunque può eseguire seguendo il documento o eseguendo lo strumento.

Quindi puoi trasferire i tuoi sviluppatori sulle funzionalità di scrittura del tuo prodotto e assumere uno staff di supporto per affrontare i problemi quotidiani

Quasi tutti gli script possono avere un potenziale riutilizzo in un modo o nell'altro. Ma quel potenziale non apparirà inizialmente - che è esattamente il motivo per cui è considerato buttato all'epoca.

Offri al tuo team la soluzione di repository Github Gist-like, senza alcun controllo di qualità, per incoraggiarne l'uso e prevenire la perdita di tale potenziale.

Ma hanno anche uno o più repository per strumenti / utilità condivisi, con un controllo di qualità appropriato.

Solo quando gli script memorizzati in quel repository usa e getta vengono referenziati, il loro potenziale di riutilizzo inizia a sbrogliare. Questo è il momento in cui il riuso formale dovrebbe entrare in azione, indotto dai singoli sviluppatori che riconoscono quel potenziale o da te se i riferimenti si verificano in un contesto di squadra. Può accadere al primo riferimento, o forse a quelli successivi (cioè quando il potenziale di riutilizzo è confermato essere più alto), a seconda dell'abilità, della pianificazione, del carico, ecc. Della squadra

The risk is that others will not be able to use the code because they cannot find or understand it.

Il riferimento stesso si occupa del problema find . L'autore della sceneggiatura e / o la persona che fa il riferimento potrebbe essere in grado di aiutare con il problema di understand . In caso contrario, il potenziale di riutilizzo non è realmente lì o la comprensione del codice sarebbe solo una parte dello sforzo / costo di riutilizzo convenzionale.

Una volta intiato, lo sforzo di riutilizzo formale dovrebbe andare sullo schermo radar della squadra e il risultato dovrebbe finire nel repository condiviso di strumenti / utilità. In questo caso è possibile eliminare gli script di estrazione equivalenti da cui è stato originato il riutilizzo (se il loro potenziale era esaurito).

Concentrarsi specificamente su codice scritto male ma funzionale; c'è un argomento molto strong per non metterli in un repository.

Ho una collezione di frammenti nella mia cartella personale Dropbox. Contiene cose che trovo utili:

• Esempio di repository EF generico
• Un semplice serializzatore / deserializzatore
• Una piccola applicazione che incrocia i due file CSV e genera un nuovo file CSV.

Tuttavia:

• L'esempio EF manca di un'unità di implementazione del lavoro e non contiene nient'altro che le opzioni CRUD più rudimentali.
• Il serializzatore si basa sul vecchio XmlSerializer ed è quasi impossibile sostituirlo con qualcos'altro. Ha anche un enorme problema di riferimento circolare.
• L'applicazione è hardcoded per cercare a.csv e b.csv nella directory dell'applicazione, ed emette un ab.csv codificato in modo hard nella stessa directory. Non ci sono controlli se i file esistono, non esiste una gestione di riferimento nullo.

Mentre continuo a usare questi frammenti regolarmente quando ho bisogno di implementare rapidamente qualcosa, essi non sono in alcun modo riutilizzabili o ben costruiti. Ci sono molte ragioni per cui questo non può essere inserito nel controllo della versione della nostra azienda:

• Non auto-documentante.
• Poco o nessun altro stile di codifica diverso dal mio hackstyle.
• Nessuna gestione degli errori.
• Non tutte le insidie sono ovvie (ad esempio i riferimenti circolari nel serializzatore)

Ma il tratto più comune di tutti questi frammenti:

• Anche se dovessi creare documentazione, probabilmente ti richiederebbe più tempo per leggerlo e comprenderlo piuttosto che fare qualcosa tu stesso!

Questi frammenti sono buoni per me da usare, perché ricordo personalmente per cosa sono stati utilizzati, come usarli e tutte le insidie che ho incontrato.
Ma se dovessi dare a qualcun altro l'accesso a questi frammenti, senza che io sia presente, allora non penseranno che questi frammenti siano in alcun modo utili.

I frammenti sono solo un'estensione dell'esperienza mia come sviluppatore. Senza di me, questi frammenti sono spazzatura. Io uso solo i frammenti perché non sono in grado di ricordare la sintassi dell'intera classe fino all'ultimo carattere. Ma ricordo le intenzioni e le insidie, anche a lungo dopo aver usato per ultimo lo snippet.

Pensaci in questo modo:

Il nastro adesivo è incredibilmente versatile, può risolvere molti problemi. Tuttavia, le cose che sono state risolte usando nastro adesivo sono generalmente considerate sgradevoli. Se IKEA dovesse includere nastro adesivo per condutture in tutti i suoi pacchi piatti, mentre potrebbe effettivamente aiutare alcune persone che ne hanno bisogno, farebbe anche una dichiarazione strong sulla fiducia di IKEA nella qualità dei mobili che ti hanno venduto.

Per lo stesso motivo, le aziende non dovrebbero consentire agli hacker snippet nel loro controllo di versione, in quanto chiama in causa la qualità del prodotto complessivo.