Existe-t-il une étude de cas qui démontre de manière convaincante que le code propre a amélioré le développement? [fermé]

Je suis dans mon premier vrai travail de programmeur et ce que je vois, c'est juste le code "Big Ball of Mud" (sans commentaires utiles aussi), mais j'aime faire du code propre, et c'est vraiment difficile pour moi de coder dans un pire façon.

Je cherche un cas d'étude où l'utilisation de code propre (je vois différentes définitions ici de ce qu'est du code propre) a amélioré le développement et la maintenabilité.

Un rapide (mais non exhaustive) recherche de Google Scholar se présente beaucoup d'articles qui font référence à Bob Martin code propre , mais je n'ai pas personnellement vu des documents qui couvrent une corrélation entre « code propre » et le développement amélioré.

Cependant, réfléchissez un instant à votre question. Vous posez des questions sur l'amélioration du développement, et c'est en soi un domaine très large couvert non seulement par la rédaction d'un meilleur code, mais aussi par de nombreux autres facteurs tels que la communication, la gestion des attentes, la méthodologie et la rationalisation des processus, les tests, l'intégration continue, et vraiment toute la boîte et les dés lorsque vous considérez combien de choses sont nécessaires pour réussir un projet de développement logiciel, sans parler de l'améliorer.

Votre question devrait donc probablement être: l' écriture de code propre contribue-t-elle à améliorer le développement logiciel? Pour répondre à cela, la seule "preuve" que je pourrais fournir serait entièrement anecdotique, et pour cela je pense que le livre Clean Code serait une excellente référence, car il est écrit non seulement par Bob Martin lui-même, mais aussi avec de nombreux chapitres contribués par certains des développeurs de logiciels les plus intelligents. Si cela n'aide pas, alors peut-être qu'une petite logique dure et froide pourrait s'appliquer.

Si vous faites des dégâts dans votre maison et que vous ne vous en sortez jamais pour le nettoyer, alors vivre dans votre maison deviendra une corvée. Il devient plus difficile de trouver des choses, plus difficile de se déplacer, et personne de bon sens ne voudra vous rendre visite si vous vivez dans un environnement sale. La même chose aussi avec le code. Si votre code est un gâchis, vous avez plus de mal à résoudre les problèmes localisés, et encore moins à les résoudre. Il devient plus facile de justifier une solution de contournement qui pourrait ne pas faire le travail, mais bon, cela bat certainement d'avoir à parcourir toute cette vieille boue héritée, non? En fin de compte, tout comme ne jamais ranger votre maison, permettre à votre code de devenir désordonné vous coûtera du temps et des efforts et vous créera des difficultés à long terme. Garder votre code propre vous fournira cependant une plate-forme plus agréable pour travailler, faire du refactoring et du débogage moins une corvée,

Non, je n'ai pas de preuves directes à vous fournir, et ce ne sont que les pensées de quelqu'un qui fait ce genre de choses depuis très longtemps et qui, espérons-le, a acquis un peu de sagesse en développement logiciel en cours de route. :-)

Ce que vous devez comprendre, c'est qu'aucune entreprise ne se propose d'écrire du code médiocre. Le problème est que 50% du code, donner ou prendre, est écrit par les programmeurs inférieurs à la moyenne de votre entreprise. Vous prêchez à la chorale lorsque vous exposez les avantages d'un code propre. L'astuce est de savoir comment le faire. Faites des recherches sur des choses comme les outils d'examen par les pairs, l'analyse statique, les tests automatisés, l'intégration continue, le TDD, la mêlée, la programmation extrême, etc. et présentez des solutions potentielles au lieu d'expliquer simplement pourquoi le problème est grave.

Je sais que cela ira à contre-courant ici, mais le temps de mise sur le marché, l'obtention des bonnes exigences, le bon financement, une bonne commercialisation, le bon prix et une bonne chance ont beaucoup plus d'influence sur le succès des produits logiciels que la qualité du code.

Cela ne veut PAS dire que la qualité du code doit être ignorée, mais vous devez reconnaître que ce n'est qu'un des nombreux facteurs.

Il existe de nombreux exemples de code simplement horrible dans des produits extrêmement réussis (par exemple le système d'exploitation Apple d'origine qui a laissé sa gestion des threads aux applications).

Je ne peux penser à aucun exemple de beau code surmontant un produit mal conçu ou trop cher.

Donc, si son temps de mise sur le marché vs joli code, le temps de mise sur le marché devrait avoir la priorité!

Vous devez séparer le code propre des objectifs réels: réduire le coût de la correction des défauts après le déploiement et réduire les retouches inutiles. Lorsque vous parlez «d'écrire du code propre pour qu'il ait moins de bogues», vous parlez de religion. Lorsque vous parlez de "réduire le taux de défauts de 10% et d'économiser 2 hommes-mois d'efforts sur le projet", vous parlez de gestion. Le code propre est un outil pour améliorer la qualité initiale de la base de code et ainsi réduire le coût total, mais il est l'un des nombreux.

L'article suivant explique pourquoi le faire correctement la première fois est important du point de vue des coûts: http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

Je ne suis au courant d'aucune étude spécifique, mais consultez les travaux de Steve McConnell .

Si quelqu'un l'a, il le fera. Par exemple, une analyse de deux minutes a révélé cela (16 ans mais toujours d'actualité).

Pour ajouter à la réponse de mattnz, si vous ne l'avez pas déjà fait, je dirais de consulter spécifiquement Code Complete: A Practical Handbook of Software Construction par Steve McConnell. Outre le fait que cela améliorera probablement votre codage, il cite de nombreuses études tout au long du livre sur la façon dont diverses pratiques de codage affectent la qualité des programmes.

À titre d'exemple (tiré du livre):

Une autre étude portant sur 450 routines différentes (ce qui n'est qu'une coïncidence inhabituelle) a révélé que les routines avec les ratios de couplage sur cohésion les plus élevés avaient 7 fois plus d'erreurs que celles avec les ratios de couplage sur cohésion les plus faibles et étaient 20 fois plus coûteuses. à corriger (Selby et Basili 1991).

Autrefois, c'était la réponse numéro un à la question Quel est le livre le plus influent que chaque programmeur devrait lire? (même si je vois que les réponses à cette question ont été récemment réorganisées d'une manière boiteuse)