Qual è il modo giusto per gestire gli script degli sviluppatori?

Gli script per gli sviluppatori entrano anche nel controllo di versione, perché in genere questi script dipendono anche dagli elementi nel controllo di versione, ad es. percorsi di file.

Se questi script sono versionati, dovrebbero anche funzionare per tutti gli sviluppatori per evitare che ogni sviluppatore scriva il proprio set di script, che diventa un inferno per la manutenzione.

Inoltre, correzioni di bug o miglioramenti di questi script vengono automaticamente rilasciati a tutti gli sviluppatori tramite il controllo della versione.

Oltre alla risposta di @ simon.

Non tutto nell'ingegneria del software riguarda la programmazione, la progettazione o la modellazione. C'è una miriade di compiti che eseguiamo continuamente durante la giornata lavorativa. Hai già menzionato uno - costruendo il progetto all'esterno dell'IDE - ma ce ne sono molti altri.

Gli sviluppatori esperti / proattivi tendono ad automatizzare queste attività. Alcuni, persino creano strumenti quando questi compiti diventano parte dello SDLC e sono noiosi - e inclini a errore - da fare a mano. I programmi sono bravi a fare lavori ripetitivi, non importa quanto siano noiosi. Noi umani non siamo così bravi.

Questi strumenti / script hanno altri effetti collaterali positivi

1. Produttività
2. Trasferimento di conoscenza
3. Autonomia (per i nuovi arrivati)

Quindi, sì, gli script dovrebbero essere nell'SMM e dovrebbero essere uno strumento in più nella casella degli strumenti dello sviluppatore.

Per quanto riguarda la cartella /scripts direi che non ha importanza. Per semplicità li lascio nella directory radice del progetto in modo che tutti i percorsi dichiarati negli script siano relativi nella cartella del progetto. Se ho bisogno di accedere a cartelle o file esterni, creo collegamenti software .

Cose da considerare prima di controllare gli script in SCM.

• Per sicurezza, assicurati che gli script non abbiano credenziali hardcoded - idealmente, gli script dovrebbero essere ben parametrizzati -

• Assicurati che gli script non facciano cose strane al sistema, come ad esempio per eseguire comandi che non possono essere annullati (il più tipico rm -rf ).

• Poiché questi diventano parte della fonte del progetto, la documentazione è molto apprezzata.

• Lo scripting non è scienza missilistica. Rendere concisi le sceneggiature. Invece di uno per dominarli tutti ... e nell'oscurità legarli , rendere di più, più piccoli e concisi. Come se applicassi SRP.

Offro un'opinione un po 'più negativa. Da un lato, gli script degli sviluppatori che sono generici, efficaci e utili dovrebbero, ovviamente, essere condivisi con altri sviluppatori, e il modo migliore per farlo è farli sedere con il codice nello stesso repository.

Tuttavia imposterei una barra alta in cui inserire gli script per il commit. Gli script sono codice, proprio come il software stesso. Ciò significa che devono essere trattati in modo simile ad altri pezzi di codice:

• Esame della revisione del codice
• Testato e automatizzato se possibile
• Considerato quando si apportano modifiche alla base di codice (in particolare, se uno script viene utilizzato da molti sviluppatori, apportare una modifica che interrompa lo script causerà molte controversie)
• Mantenuto (con tutto ciò che comporta - prioritizzazione, tempo, documentazione ecc.).

Ci sono una serie di ulteriori considerazioni che si applicano più agli script che al software stesso:

• In primo luogo, è molto più difficile convincere la propria organizzazione e gli stakeholder a investire nel mantenimento di script che semplificano la vita degli sviluppatori. Ciò significa che è più difficile trovare il tempo per soddisfare i criteri sopra elencati: è facile scrivere uno script che funzioni per te nel tuo ambiente, ma parametrizzarlo, renderlo stabile, documentarlo richiede molto più tempo. Ciò significa che gli script possono diventare e diventare un codice morto a meno che uno sviluppatore non possa giustificare il mantenimento dello script corrente.
• È molto meno probabile che più sviluppatori abbiano familiarità con uno script complicato per mantenerlo o che più sviluppatori si sentano proprietari del codice. Quando lo sviluppatore originale se ne va, trovare qualcuno che ne diventi proprietario può essere difficile (e trovare e giustificare il tempo per loro per imparare come funziona lo script può essere ancora più difficile).
• È molto più probabile che uno script interagisca con la macchina degli sviluppatori e costruisca l'ambiente in qualche modo. È anche molto probabile che tu abbia più sviluppatori con più ambienti diversi. Se uno script rovina un ambiente perché non è stato mantenuto correttamente o non è stato considerato un caso d'angolo, non stai solo rompendo una build notturna del tuo software, stai potenzialmente pagando a uno sviluppatore un giorno o più di lavoro per ottenere il loro ambiente torna alla normalità. Questo può causare sangue baad e una perdita di fiducia.
• Poiché gli script sono spesso esterni al software stesso, il loro mantenimento può essere una sfida. Se gli script non vengono eseguiti tramite automazioni, è facile per loro diventare obsoleti o per essere dimenticati, a quel punto sono diventati codice morto e sono solo un debito tecnologico di cui qualcuno avrà bisogno di tempo per ripulire.

Per riassumere, gli script possono essere molto utili per un singolo sviluppatore, ma la condivisione come parte della stessa base di codice può essere un compito molto più difficile e può potenzialmente causare più problemi di quelli risolti.