J'analyse généralement les données des expériences et bien que j'ai un schéma général des étapes que je dois faire, je pourrais avoir besoin de les ajuster aux spécificités des expériences ou aux questions sous-jacentes. Je suis généralement le seul à coder.
J'ai regardé wikipedia mais je ne sais pas quelle méthodologie je peux utiliser, en partie parce que je n'en ai jamais suivi, et en partie parce que j'explore parfois les données, pour voir à quoi elles ressemblent, et d'autres fois, je veux juste une réponse. (Et parce que je ne suis pas trop attendu pour tester ou avoir une certaine qualité sur mon code)
J'ai été invité à poser cette question après une heure ou deux en découvrant que la fonction r tabledépend de l'ordre des vecteurs et non du nom des éléments auxquels les comparer. Ensuite, je pensais que j'aurais dû tester le comportement et les fonctions où j'ai utilisé avec des données fictives. Mais j'ai utilisé le tableau après que d'autres analyses aient entraîné un manque d'informations, donc je n'aurais pas pu suivre la méthodologie de développement pilotée par les tests (si j'avais bien compris). Cependant, je pense qu'avec une certaine amélioration de la façon dont je fais face au projet, je pourrais être plus efficace, en plus de détecter les erreurs plus tôt, mais aussi comment et quoi rechercher en cas de doute sur un résultat, alors veuillez ne pas vous concentrer uniquement sur cet exemple d'erreur.
Quelle méthodologie logicielle convient le mieux à la recherche?
Je demande essentiellement comment garantir la qualité et les progrès dans le temps ainsi que conserver la spécificité de la recherche.
Exemple de fonctionnement:
Un biologiste a en tête une question et sait que faire une expérience conduira à avoir des données d'intérêt (c'est-à-dire des niveaux d'expressions géniques dans deux conditions), puis il / elle a défini l'expérience et recueilli des échantillons de 10 personnes / souris / rats. Maintenant, je dois analyser ces données pour ces 10 échantillons en utilisant les bibliothèques et tests existants (ou en implémentant de nouveaux tests) mais en tenant compte de la question que le biologiste avait en tête (c'est-à-dire quels gènes sont plus exprimés dans une condition que dans d'autres). La structure est la même que dans les expériences précédentes (qui impliquaient 6 conditions et un autre animal) mais le test statistique, les normalisations, la structure des données peuvent changer. J'ai donc l'habitude de copier une version précédente et de l'adapter aux besoins actuels.
Réponses:
Ce qui est nécessaire n'est peut-être pas une méthodologie logicielle, mais un changement politique dans le monde universitaire qui résout le problème du manque de reconnaissance du rôle joué par le développement de logiciels dans le domaine scientifique.
Le Software Sustainability Institute (UK) est l'organisation la plus proche de ce que vous recherchez: comment plaider pour une utilisation plus consciencieuse de la programmation informatique dans la recherche scientifique.
Il fournit également des pointeurs d'information pour ceux qui s'intéressent aux méthodologies de développement logiciel.
Cependant, je dois souligner que les méthodologies régissent généralement les équipes de programmeurs de logiciels, avec des itérations et un raffinement progressif des objectifs du projet, et fonctionnent avec des bases de code stables qui durent longtemps. Ils concernent des projets qui sont des ordres de grandeur plus complexes que ce que vous faites.
Quant à savoir pourquoi cette chose très clairement correcte (utilisation plus consciencieuse de la programmation informatique dans la recherche scientifique) n'a pas été accomplie et toujours confirmée, voici la vérité qui dérange: dans les environnements administratifs académiques, les scientifiques peuvent être vus dégrader l'importance jouée par l'ordinateur programmation. Parfois, on peut les voir se regrouper pour nier la reconnaissance des contributions des personnes impliquées dans le logiciel, même si la nature de cette contribution s'inscrit dans la discipline scientifique.
Sur votre lieu de travail, il y a des choses qui manquaient et des choses que vous pouvez faire.
Les choses qui manquaient:
En bref, la culture générale est que les personnes concernées ne sont pas vraiment intéressées par ... vous l'avez deviné ... une utilisation plus consciencieuse de la programmation informatique dans la recherche scientifique.
Choses que vous pouvez faire:
Pour les développeurs de logiciels de carrière, des directives de cette nature peuvent être trouvées dans:
Ceux-ci sont considérés comme les exigences de base pour gérer une entreprise de développement de logiciels. Cependant, lorsque vous menez une guerre d'apathie, seul, vous devez établir des priorités. Améliorer les outils, noter et maintenir les informations, conserver les versions du code source sont le strict minimum pour un environnement unique.
la source
Ne vous embêtez pas tant sur la méthodologie mais essayez de vous concentrer davantage sur ce dont vous avez besoin pour garder une trace de vos besoins pour le développement logiciel lui-même.
Ayant effectué un court séjour dans une position relativement similaire à la vôtre, voici ce que je peux extraire de mon expérience personnelle.
Exactitude algorithmique
Probablement l'aspect le plus important, vous devriez pouvoir prouver que votre logiciel fait ce pour quoi il a été conçu. Ici, les tests automatisés sont votre meilleur allié. Je me rends compte qu'il peut être difficile de se passer d'un ensemble de données approprié, mais en fait, vous devriez prendre l'habitude de créer vos propres ensembles de données. Leur objectif est cependant quelque peu différent, vous n'essayez pas d'extraire la tendance des données mais assurez-vous que le logiciel produit des résultats prévisibles et corrects à partir d'un ensemble de données connu. Ainsi, pour la reconnaissance des formes, par exemple, vous n'avez pas besoin d'une composition génétique multi-gig, quelques lignes de texte suffisent pour garantir que l'algorithme détecte la forme.
J'avais l'habitude de créer mes données pour représenter des cas d'angle, des cas impossibles. J'avais tendance à me concentrer davantage sur les extrêmes que sur la norme attendue. Plusieurs fois, je me souviens avoir testé quelque chose d'impossible uniquement pour voir cette situation se produire dans l'ensemble de données réel. Si je ne l'avais pas testé, je n'aurais pas mis en place les détections d'erreurs et l'enregistrement nécessaires pour identifier les corruptions ou erreurs potentielles dans l'ensemble de données. TDD est un bon ajustement pour cette partie, bien que la création d'un bon ensemble de tests soit, je pense, plus importante, que vous le fassiez avant ou après le code réel.
Versioning
Trop souvent, cette partie est omise. Un bon schéma de version pour votre code et les packages / exécutables produits vous aidera énormément à maintenir votre progression dans l'ordre. Être capable de récupérer exactement le code qui a été utilisé pour créer les résultats précédemment obtenus peut aider lors du suivi des bogues ou des écarts. La ramification peut également aider lors de l'expérimentation de différentes approches ou algorithmes.
Assurez-vous de baliser le code utilisé dans les calculs réels, consultez la version sémantique si vous avez besoin d'aide pour nommer les versions.
Construction automatisée
Un corollaire au point ci-dessus. Assurez-vous d'automatiser autant que possible le processus de construction et d'empaquetage de votre logiciel. Vous n'avez pas besoin de passer au complet, juste assez pour rendre trivial la création du système final à partir des sources et des dépendances. Le but ici est de vous faire gagner du temps mais aussi d'avoir un moyen reproductible pour recréer le logiciel à partir de la source, y compris les dépendances et autres externes. Groovy, Maven, ant, Scons, cmake, ne sont qu'un petit échantillon d'outils d'automatisation de construction et de systèmes de script qui peuvent vous aider.
Si vous voulez aller plus loin, installez Jenkins ou teamcity ou tout autre système d'intégration continue. Bonus supplémentaire si vous devez maintenir plusieurs serveurs ou travailleurs pour l'informatique distribuée. La plupart de ces systèmes auront des moyens d'aider à la maintenance. De plus, vous serez en mesure d'automatiser complètement les exécutions de test afin que vous n'ayez pas besoin d'attendre les résultats avant de continuer, validez et recevez un courrier plus tard. J'ai eu un système qui a mis des heures à passer les tests. Mettre en place cette automatisation a été le meilleur investissement de mon temps. Surtout si vous avez déjà les scripts en place pour tout construire.
Isolement de l'environnement
Les chercheurs passent énormément de temps à isoler un ou plusieurs petits ensembles de variables d'intérêt de systèmes complexes par le biais de leurs protocoles. Cela devrait également être étendu à vos pratiques de développement logiciel. Vous pouvez également vérifier la conteneurisation avec Docker ou Vagrant. Il vous donnera un meilleur contrôle sur l'environnement dans lequel le logiciel est exécuté.
Vous n'avez pas besoin d'avoir une grande équipe avant que cela porte ses fruits, j'étais la plupart du temps seul mais j'ai grandement profité de leur mise en place. La tranquillité d'esprit et le gain de temps que cela m'apportait dépassaient de loin les frais généraux que cela m'avait coûté.
la source
Pouvez-vous utiliser R? C'est pour ça.
Gardez votre code simple . Optez pour la lisibilité et ne vous inquiétez pas des performances, sauf en cas de problème. Des méthodologies existent pour essayer d'empêcher les équipes de programmeurs de se mettre des bogues dans le code de l'autre, même si l'équipe est une seule personne.
Cela dit, la discipline du codage est super importante. J'ai vu du code de scientifiques et de mathématiciens avancés hautement qualifiés, et c'est affreux . Ils ignorent totalement le formatage. Ils écrasent le code ensemble comme s'il était emballé sous vide. Leurs noms de variables sont totalement mystifiants. Ils n'écrivent pas de commentaires, ou ils écrivent des commentaires impénétrables, ou les commentaires disent une chose tandis que le code en dit une autre. Ne fais pas ces choses. Pensez toujours à l'avance aux changements futurs que vous ou d'autres pourriez devoir apporter.
la source