Un recente lavoro di Wilson et al (2014) ha evidenziato 24 Best Practices per la programmazione scientifica. Vale la pena dare un'occhiata. Mi piacerebbe sentire opinioni su questi punti da parte di programmatori esperti nell'analisi di dati scientifici. I consigli degli autori sembrano buoni, ma pensi che questi consigli siano utili e pratici? Come ammettono, l'introduzione di tutti loro può richiedere tempo e sforzi significativi. Ad esempio, inserendo asserzioni e implementando test unitari è sicuramente necessario codificare ulteriormente. Ciononostante, pensi che gli scienziati (come i biologi) che non hanno seguito la codifica dovrebbero generalmente seguire questi? Se alcuni di loro sono troppo, a che punto dovremmo andare e fermarci a seconda di cosa?
Wilson G, Aruliah DA, Brown CT, Chue Hong NP, Davis M, Guy RT, Haddock SHD, Huff KD, Mitchell IM, Plumbley MD, Waugh B, White EP, Wilson P (2014) Best Practices for Scientific Computing. PLoS Biol 12:e1001745.
http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.1001745
Box 1. Summary of Best Practices
Write programs for people, not computers.
(a) A program should not require its readers to hold more than a handful of facts in memory at once.
(b) Make names consistent, distinctive, and meaningful.
(c) Make code style and formatting consistent.
Let the computer do the work.
(a) Make the computer repeat tasks.
(b) Save recent commands in a file for re-use.
(c) Use a build tool to automate workflows.
Make incremental changes.
(a) Work in small steps with frequent feedback and course correction.
(b) Use a version control system.
(c) Put everything that has been created manually in version control.
Don’t repeat yourself (or others).
(a) Every piece of data must have a single authoritative representation in the system.
(b) Modularize code rather than copying and pasting.
(c) Re-use code instead of rewriting it.
Plan for mistakes.
(a) Add assertions to programs to check their operation.
(b) Use an off-the-shelf unit testing library.
(c) Turn bugs into test cases.
(d) Use a symbolic debugger.
Optimize software only after it works correctly.
(a) Use a profiler to identify bottlenecks.
(b) Write code in the highest-level language possible.
Document design and purpose, not mechanics.
(a) Document interfaces and reasons, not implementations.
(b) Refactor code in preference to explaining how it works.
(c) Embed the documentation for a piece of software in that software.
Collaborate.
(a) Use pre-merge code reviews.
(b) Use pair programming when bringing someone new up to speed and when tackling particularly tricky problems.
(c) Use an issue tracking tool.
Sono relativamente nuovo alla programmazione seria per l'analisi dei dati scientifici. Quando ho provato a scrivere codice per analisi pilota di alcuni dei miei dati l'anno scorso, ho riscontrato un'enorme quantità di errori sia nel mio codice che nei miei dati. Bug ed errori erano stati intorno a me tutto il tempo, ma questa volta era un po 'opprimente. Riuscii a scricchiolare finalmente i numeri, ma pensavo di non poter più sopportare questo casino. Alcune azioni devono essere intraprese.
Da allora, senza una guida sofisticata come l'articolo precedente, ho iniziato ad adottare uno "stile difensivo" di programmazione. Un libro intitolato "The Art of Readable Code" mi ha aiutato molto. Ho implementato meticolose convalide e / o asserzioni di input per ogni funzione, rinominato un sacco di variabili e funzioni per una migliore leggibilità e ho estratto molti bit come funzioni riutilizzabili. Di recente, ho introdotto Git e SourceTree per il controllo della versione.
Al momento, poiché i miei colleghi sono molto più riluttanti su questi problemi, le pratiche di collaborazione ( 8a, b, c) non sono state introdotte. In realtà, come hanno ammesso gli autori, poiché tutte queste pratiche richiedono un po 'di tempo e sforzi per introdurle, può essere generalmente difficile persuadere i vostri riluttanti collaboratori a rispettarle.
Penso di chiedere le tue opinioni perché soffro ancora di molti bug, nonostante tutti i miei sforzi su molte di queste pratiche. La correzione dei bug potrebbe essere, o dovrebbe essere, più veloce di prima, ma non ho potuto realmente misurare il miglioramento. Inoltre, gran parte del mio tempo è stato investito in difesa, il che significa che attualmente non ho fatto molta analisi dei dati (offesa). Dov'è il punto in cui dovrei fermarmi in termini di produttività?
Ho già distribuito: 1a, b, c, 2a, 3a, b, c, 4b, c, 5a, d, 6a, b, 7a, 7b
Sto per provare: 5b, c
Non ancora: 2b, c, 4a, 7c, 8a, b, c
(Non riuscivo a vedere il vantaggio di usare GNU make ( 2c ) per il mio scopo. Qualcuno potrebbe dirmi in che modo aiuta il mio lavoro con MATLAB?)