Pratiche di stile industriale per aumentare la produttività in un piccolo ambiente scientifico

Question

Lavoro in un piccolo laboratorio scientifico indipendente in un'università negli Stati Uniti e ho notato che, rispetto a molte pratiche che sono apparentemente seguito nel settore, come il checkout giornaliero in un sistema di controllo delle versioni, l'uso di un singolo IDE/editor per tutte le lingue (come emacs), ecc., seguiamo pratiche di programmazione piuttosto scadenti.

Quindi, stavo pensando di riunire tutti i miei programmi, script, ecc. E di creare un ambiente semplificato per aumentare la produttività. Mi piacerebbe ricevere suggerimenti da persone su Stack Overflow per lo stesso. Ecco il mio piano principale: utilizzo gli script MATLAB, C e Python e mi piacerebbe modificarli, compilarli da un singolo editor e garantire il corretto controllo della versione.

(domande/cose per cui mi piacerebbe suggerimenti sono in corsivo)

1] Installare Cygwin, e farlo funzionare bene con Windows in modo da poter usare git o un sistema simile di controllo di versione (è c'è un DVCS che può funzionare direttamente dalla CLI di Windows, quindi posso saltare il passo di Cygwin?).

2] impostare Emacs di lavorare con i file MATLAB C, Python, e, quindi posso modificare e compilare tutti e tre in una volta da un unico editor di (diciamo, emacs)

(io non sono molto ho familiarità con il menu emacs, ma c'è un modo per impostare il percorso del compilatore per alcune lingue? So che posso Google, ma la documentazione di emacs si è dimostrata molto difficile da leggere finora, quindi mi piacerebbe se qualcuno mi ha detto in una lingua semplice)

3] Avviare il controllo del codice alla fine di ogni giorno o mezza giornata in modo da mantenere un percorso corretto di avanzamento del mio codice (due domande),

• puoi controllare i file direttamente da emacs?

• c'è un modo per eseguire il checkout dei file LabVIEW in un git come DVCS?

Infine, vorrei scusarmi per la natura piuttosto vaga della questione, e spero io imparare a fare domande meglio nel tempo. Sarei grato se le persone dessero i loro suggerimenti, tuttavia, e indicasse le risorse che potrebbero aiutarmi a imparare.

Answer 1

1) Sia git che mercurial funzioneranno in Windows in modo nativo - non c'è bisogno di Cygwin - un ambiente che eviterei se possibile.

2) Non capisco perché pensi di dover usare emacs.

3) Non si effettua il check-in del codice in una particolare ora del giorno o con una frequenza particolare: si effettua il check-in quando si è effettuato un cambiamento distinto che è stato testato e funziona. O se sei sul tuo ramo, quando è conveniente.

Answer 2

È fantastico che tu stia percorrendo questa strada. Ecco alcune cose da aggiungere all'elenco:

1) Aggiungere test al tuo ciclo di lavoro. Cioè, una volta che un segmento è stato scritto, altre persone che non hanno lavorato su di esso riesaminano il codice. Quindi scrivi test per assicurarti che il nuovo codice si integri bene con altri codici e produca i risultati che desideri vedere, e infine rendi questi test parte del processo di compilazione durante la notte.

2) Procurarsi un processo di costruzione durante la notte. O almeno un processo automatico che ricostruisce il tuo codice ogni volta che qualcuno controlla il codice. Avere eseguito tutti i test su quella build.

Answer 3

Cercare di seguire una sorta di best practice ti avvantaggerà molto, ma potresti scoprire che molte persone non sono realmente interessate a seguirle. Cerca di pubblicizzare i vantaggi in modo sottile in modo da non intimidire i tuoi colleghi, se a loro piace ciò che vedono potrebbero adottare alcuni dei tuoi suggerimenti.

Ambienti scientifici in cui molte persone si preoccupano solo di laurearsi velocemente o di ottenere approvazioni di finanziamenti sembrano corroborare uno stile da cowboy di codifica. Se riesci a far riflettere la gente sulla qualità e sulla riproducibilità, hai già vinto.

Quello che ho trovato utile:

• sempre cercare di rompere il codice in piccoli sottoprogetti che si può facilmente verificare. Esegui i tuoi test ad ogni check-in. Puoi utilizzare i sottomoduli di git per assemblare le tue "applicazioni".
• Se più persone possono impegnarsi nel repository utilizzare qualcosa come astyle per avere una formattazione coerente (probabilmente meno un problema per il codice Python).
• Imposta qualcosa come gitweb/cgit/... in modo che la gente possa ottenere tarball di codice e abituarsi all'idea che il controllo del codice sorgente sia utile.
• Prova a trovare un coding buddy nel tuo gruppo/comunità. La revisione del codice è molto difficile da fare in un ambiente in cui le persone sono inclini a "solo a farlo", gettando spesso buon stile/buon senso a bordo.

Answer 4

Come altri hanno già detto, il check-in a intervalli regolari non è molto importante. Fai il check in quando raggiungi un traguardo importante (hai apportato una modifica che funziona con il resto del codice e si costruisce in modo corretto. Le build automatiche sono molto più importanti. Convalidano di aver verificato tutte le modifiche rilevanti.

Penso che potresti essere un po 'confuso riguardo l'hosting del controllo del codice sorgente rispetto ai client per il controllo del codice sorgente.I client per CVS, SVN, Git e altri sono quasi universalmente disponibili per Windows L'hosting è disponibile da molte società di hosting web. una buona opzione, dato che potrebbe anche darti un backup offsite del tuo codice base per ~ 100 $/anno. In alternativa puoi semplicemente caricare il server su un PC di fascia bassa e metterlo in un armadio da qualche parte, anche se il costo dell'elettricità è probabilmente quanto si paga per l'hosting

Utilizzo di un singolo L'IDE per tutte le lingue non è affatto importante, la coerenza all'interno di progetti con la stessa lingua è importante. Probabilmente tutti i tuoi progetti in una lingua dovrebbero avere uno standard di codifica condiviso. Dovrebbero inoltre creare lo stesso compilatore e/o eseguire lo stesso interprete/VM e disporre di file di progetto aggiornati per qualsiasi IDE utilizzato (se applicabile).

Answer 5

c'è un modo per eseguire il checkout dei file LabVIEW in un git come DVCS?

Non c'è alcun motivo per cui i file LabVIEW non possano essere in un DVCS, sto usando Mercurial. Tuttavia, poiché i file LabVIEW sono trattati come file binari, le dimensioni del repository aumenteranno rapidamente.

Fuori dalla scatola LabVIEW fornisce solo 3-way merges, per usare una funzione diff tra due revisioni è necessario LV-diff, con un few tweaks per sostenere gli strumenti che cambiano solo la posizione dei file (ad es. Duplica i nomi di file).

Inoltre è importante aggiungere * .lvlps e * .aliases all'elenco di indirizzi ignorati, questi file non hanno un significato utile su un altro computer.