Références citables pour les meilleures pratiques logicielles

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.

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.

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:

• Qu'est-ce qui fait le succès des bibliothèques de logiciels open source de calcul?
• Meilleures pratiques pour le calcul scientifique

À 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 :)