Qui plus est, "amateur" (souvent aucune formation).
avec des enjeux très largement réduits
Mouais, enfin il faut être honnête : quelle est la proportion de résultats scientifiques publiés affectés par des bugs plus ou moins importants? Si c'est 80%, alors on est un peu payés pour rien. La qualité de la production scientifique, c'est maintenant avant tout la qualité et la reproductibilité du code pour l'analyse des données.
c’est du code plus ou moins "jetable",
Certes, mais "jetable" ne veut pas forcément dire "crado". Dans ce contexte, la stabilité des API n'a aucun intérêt en effet (puisque par définition on fait tout le temps évoluer le code jusqu'à la publication, et le code ne tournera probablement plus jamais après); les optimisations prématurées sont proscrites, on ne code que ce dont on a besoin au moment où on en a besoin. Mais ça n'empêche pas de documenter un minimum (on peut être relu et on doit pouvoir justifier chaque bout de code), ça n'empêche pas d'utiliser un gestionnaire de version, etc.
Ceci dit j’utilisais aussi à l’occasion du code plus professionnel,
Il est certain que les pratiques peuvent changer, et que ceux qui travaillent mieux peuvent s'en sortir. Mais ça dépend également des modes de financement (typiquement, il n'y a aucun financement possible pour la maintenance), des modes d'évaluation (est-ce que la qualité des logiciels est évaluée, est-ce qu'il est valorisable de contribuer à un projet libre, etc), et de la culture scientifique dans la discipline (valorisation du travail collectif vs. chacun dans son coin).
Une nouveauté de cette année, c'est le recrutement de "data editor" dans les journaux scientifiques (ceux des sociétés savantes hein, les grands éditeurs s'en fichent). Ils vont vérifier si les auteurs des articles mettent bien à disposition les données scientifiques et le code utilisé pour les analyses.
[^] # Re: Maintenance
Posté par arnaudus . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 6.
Qui plus est, "amateur" (souvent aucune formation).
Mouais, enfin il faut être honnête : quelle est la proportion de résultats scientifiques publiés affectés par des bugs plus ou moins importants? Si c'est 80%, alors on est un peu payés pour rien. La qualité de la production scientifique, c'est maintenant avant tout la qualité et la reproductibilité du code pour l'analyse des données.
Certes, mais "jetable" ne veut pas forcément dire "crado". Dans ce contexte, la stabilité des API n'a aucun intérêt en effet (puisque par définition on fait tout le temps évoluer le code jusqu'à la publication, et le code ne tournera probablement plus jamais après); les optimisations prématurées sont proscrites, on ne code que ce dont on a besoin au moment où on en a besoin. Mais ça n'empêche pas de documenter un minimum (on peut être relu et on doit pouvoir justifier chaque bout de code), ça n'empêche pas d'utiliser un gestionnaire de version, etc.
Il est certain que les pratiques peuvent changer, et que ceux qui travaillent mieux peuvent s'en sortir. Mais ça dépend également des modes de financement (typiquement, il n'y a aucun financement possible pour la maintenance), des modes d'évaluation (est-ce que la qualité des logiciels est évaluée, est-ce qu'il est valorisable de contribuer à un projet libre, etc), et de la culture scientifique dans la discipline (valorisation du travail collectif vs. chacun dans son coin).
Une nouveauté de cette année, c'est le recrutement de "data editor" dans les journaux scientifiques (ceux des sociétés savantes hein, les grands éditeurs s'en fichent). Ils vont vérifier si les auteurs des articles mettent bien à disposition les données scientifiques et le code utilisé pour les analyses.