Références citables pour les meilleures pratiques logicielles

14

Je rédige actuellement ma thèse de doctorat. J'ai passé une fraction importante de mon doctorat à nettoyer et étendre le code scientifique existant, à appliquer les meilleures pratiques en génie logiciel qui n'étaient pas utilisées auparavant, et j'aimerais écrire à ce sujet dans ma thèse. Plutôt que de simplement dire "J'ai ajouté des tests unitaires", je veux pouvoir écrire quelque chose comme ceci:

J. Doe a inventé les tests unitaires en 1975 [ 23 ] . Une étude récente de Bloggs et al [ 24 ] a montré que les tests unitaires réduisent l'incidence des erreurs logicielles de 73% ... 234 tests unitaires distincts ont été ajoutés à la base de code, gérés par le cadre xUnit créé par Timpkins et al [ 25 ][23][24][25]

Je recherche des références académiques citables (de préférence des articles dans des revues à comité de lecture où je peux obtenir des DOI, BibTeX, etc.) aux meilleures pratiques de génie logiciel largement acceptées, en particulier:

  • tests unitaires
  • contrôle de version
  • modularisation / séparation des préoccupations
  • profilage / optimisation des performances basé sur les informations de profilage
  • suivi des bogues / problèmes

Je recherche des informations à la fois sur l'invention initiale et sur les évaluations ultérieures de l'efficacité. S'il y a un article de revue qui répertorie toutes ces choses en un seul endroit, tant mieux.

user1915639
la source
1
Est-ce que cela aide: plosbiology.org/article/…
akid
Si le but d'ajouter des références est de convaincre les lecteurs que les meilleures pratiques sont meilleures, il pourrait être plus logique d'expliquer pourquoi elles sont meilleures directement; donner simplement des références pourrait être moins convaincant. Gardez à l'esprit que beaucoup de ces choses sont courantes dans les cours de premier cycle en génie logiciel, peuvent être trouvées dans les manuels standard et ne sont pas nécessairement des recherches de pointe.
Kirill
Mon expérience est que vous avez besoin à la fois de motivation et de références. Hier, je viens d'avoir une conversation avec des collègues (qui sont tous deux des scientifiques praticiens) qui étaient d'avis que les méthodologies de test ad hoc fonctionnent mieux (réponse courte: elles ne le font pas). Il est important d'exprimer la motivation en termes de métriques qui semblent intéresser les informaticiens: des articles à impact plus élevé plus rapidement et des résultats plus corrects (voir le lien sur la recherche reproductible). Pointez sur les références car les gens vont vous combattre sur ces points en prétendant qu'il n'y a pas d'avantages significatifs.
Geoff Oxberry
Selon toute vraisemblance, les personnes qui examineront ma thèse seront des professeurs de chimie ou de science des matériaux plutôt que des experts en science informatique. Ils auront probablement une certaine expérience dans l'écriture de code, mais ils n'auront certainement pas fait de codage sérieux, car ils étaient eux-mêmes des étudiants ou des premiers post-docs. Ce dont j'ai besoin, c'est quelque chose qui dit "Cette année de mon doctorat que j'ai consacré à cela, je faisais quelque chose d'utile et pas seulement de relâche"
user1915639

Réponses:

13

Le livre de Steve McConnell, Code Complete, 2e édition, contient une bibliographie détaillée qui traite de ces questions du point de vue des développeurs de logiciels plutôt que des informaticiens. Le livre commence à devenir un peu daté, en ce sens qu'il approche d'une décennie, il ne couvre donc pas les méthodologies de test plus récentes comme le développement axé sur le comportement. Néanmoins, c'est la chose la plus proche d'un article de synthèse sur la construction de logiciels que je connaisse. Vous pouvez également rechercher des articles dans le logiciel IEEE.

Du côté de la science computationnelle des choses, je pense que le meilleur article est probablement la version PLoS de la préimpression arXiv DavidKetcheson citée sur "Best Practices for Scientific Computing". Je dis ceci venant d'un milieu d'ingénierie, où moins de gens citent des références arXiv ou postprints arXiv, et donc, citant un "vrai article de journal" (en mettant de côté, bien sûr, tous les problèmes de publication scientifique qui sont actuellement débattus ) est considéré plus favorablement (et j'ai l'impression que c'est la raison pour laquelle ces auteurs ont choisi de le publier dans une revue).

Les auteurs de l'article PLoS que DavidKetcheson et moi-même citons font partie d'une organisation appelée Software Carpentry qui organise (généralement 2 jours) des «camps d'entraînement» pour enseigner aux scientifiques certaines des meilleures pratiques pour le développement de logiciels et des compétences informatiques utiles pour les scientifiques (pas seulement scientifiques informatiques). Le site Web de la menuiserie logicielle contient une bibliographie détaillée sur le développement de logiciels en science. Si ces questions vous intéressent, je vous encourage à les contacter; ils sont toujours à la recherche de plus de défenseurs des meilleures pratiques en développement logiciel pour faire du bénévolat à divers titres. ( Avertissement : je fais du bénévolat pour la menuiserie logicielle.)

Une autre justification courante pour s'engager dans les meilleures pratiques de développement logiciel est la reproductibilité. Victoria Stodden a organisé une longue liste de références de recherche reproductibles qui peuvent être intéressantes, selon ce que vous voulez dire.

Geoff Oxberry
la source
La liste de lecture "Menuiserie logicielle" semble utile.
user1915639
6

Je n'ai pas de références pour l'origine de chacune de ces idées / pratiques. Mais voici quelques références très récentes et pertinentes:

David Ketcheson
la source
J'appuie définitivement la première de ces références :-) C'est l'information complète est Wolfgang Bangerth, Timo Heister Qu'est-ce qui fait le succès des bibliothèques de logiciels open source de calcul? Computational Science & Discovery, vol. 6, article 015010 (18 pages), 2013
Wolfgang Bangerth
-2

À mon humble avis, je prendrais grand soin de citer les "meilleures pratiques" dans le contexte d'approches scientifiquement éprouvées. La plupart des pratiques sont dérivées de "ce qui semble fonctionner pour un ensemble de projets par une personne perçue comme un gourou impliqué dans ces projets", plutôt que de tests rigoureux de différentes approches. Il y a tout simplement trop de variables et de facteurs humains en génie logiciel pour affirmer qu'il existe une liste référençable de "meilleures pratiques" (par exemple, une pratique qui fonctionne sur un projet échouera complètement sur un autre).

Je l'aborderais en précisant ce dont votre projet avait besoin, pourquoi il en a besoin et en ajoutant des références aux méthodes utilisées et pourquoi vous les avez utilisées.

Je pencherais également en faveur de la communication de résultats quantifiables plutôt que de références pour exprimer votre point. Par exemple, si votre unité test a découvert 100 bogues, dont 10 suffisamment graves pour jeter le doute sur le résultat publié précédemment. C'est une déclaration beaucoup plus puissante à avoir dans votre doctorat qu'une déclaration que vous connaissez l'origine des tests unitaires.

edit: (faute de frappe fixe) - Répondre à ce qui suit - Je donne souvent l'éducation des enfants comme une analogie aux projets logiciels. Il existe de nombreuses méthodes et méthodes éprouvées pour les élever, en essayant d'élever vos enfants avec une méthode, car cela fonctionne pour la moyenne ou un sous-échantillon testé, fonctionnera tant que votre enfant sera le même que celui testé. Il est préférable de connaître de nombreuses méthodes et d'appliquer celles qui fonctionnent dans votre instance. Oui, les tests unitaires peuvent être prouvés, mais l'appliquer sur cette seule base pourrait signifier que votre projet arrive sur le marché tardivement et échoue donc à son objectif (si tel est l'objectif). Je dis qu'appliquer une méthode pour obtenir un résultat et donner le résultat de ce résultat, à mon avis, est mieux dans une thèse, que d'énumérer des choses que vous avez essayées sur la base d'autres projets - à moins bien sûr que le sujet de la thèse soit la mesure des méthodologies :)

internetscooter
la source
1
Des études ont, en fait, comparé des stratégies de détection de défauts telles que les tests unitaires, la programmation de paires, la progression dans un programme avec un débogueur et la révision formelle du code et évalué leur efficacité. Vous avez raison de dire que chaque stratégie a sa place. La communauté du développement logiciel reconnaît ce point dans la littérature et suggère ce qui pourrait fonctionner le mieux pour différents types de projets. Si «trop de variables et de facteurs humains» étaient vraiment un obstacle à la formulation des meilleures pratiques, nous ne les aurions pas en médecine ou dans d'autres domaines aux problèmes complexes similaires, et pourtant nous le faisons. Je n'achète pas votre argument.
Geoff Oxberry
« une bouillie de maïs déclaration plus puissante dans votre thèse » est une belle faute de frappe
denis