是否有一个案例研究可以令人信服地证明干净的代码可以改善开发？[关闭]

我是程序员的第一份实际工作，我看到的只是“ Big Ball of Mud”代码（也没有有用的注释），但是我喜欢编写干净的代码，这对我来说很难编码办法。

我正在寻找一些研究案例，这些案例中使用干净的代码（这里看到了什么是干净的代码）改善了开发和可维护性。

快速（但绝不是全部）搜索的谷歌学术变成了很多这指的鲍勃·马丁的文章清洁守则，但我还没有亲自看到，包括“干净的代码”和改善发展之间的关系的任何文件。

但是，请暂时考虑您的问题。您在询问改进的开发，而它本身就是一个非常广泛的主题领域，不仅涉及编写更好的代码，还涉及许多其他因素，例如沟通，管理期望，方法和精简流程，测试，持续集成，以及当您考虑成功开发一个软件开发项目需要考虑多少因素时，更不用说对其进行改进了。

因此，您可能应该提出的问题是：编写干净的代码是否有助于改进软件开发？要回答这个问题，我唯一可以提供的“证据”完全是轶事，因此我认为“ 清洁代码”书将是一个很好的参考书，因为它不仅由鲍勃·马丁本人撰写，而且还撰写了许多章节。一些最聪明的软件开发人员。如果那没有帮助，那么也许可以应用一些冷酷的逻辑。

如果您在家里弄得一团糟，而又从来没有四处打扫，那么住在家里将变得很麻烦。如果您生活在肮脏的环境中，那么寻找事物变得越来越困难，走动起来也变得越来越困难，并且没有任何他们的正确想法愿意拜访您。代码也一样。如果您的代码混乱不堪，那么发现问题就更难了，更不用说解决它们了。证明可能无法解决问题的变通方法变得更容易了，但是，嘿，它肯定要克服所有这些旧的遗留问题，对吗？最后，就像从不整理您的房屋一样，让您的代码变得不整洁将花费您的时间和精力，并从长远来看给您造成困难。但是，保持代码整洁将为您提供一个更好的平台，使其工作，减少重构和调试工作，

不，我没有直接的证据可以提供给您，这些只是一个已经从事了很长一段时间的人的想法，并希望他们在此过程中获得了一点软件开发智慧。:-)

您需要了解的是，没有公司会着手编写平庸的代码。问题是，给出或接受的代码中有50％是由公司的普通程序员编写的。阐述纯净代码的好处时，您正在宣讲合唱团。诀窍是如何做到这一点。对诸如同行评审工具，静态分析，自动化测试，持续集成，TDD，Scrum，极限编程等之类的内容进行一些研究，并提出潜在的解决方案，而不仅仅是解释问题的严重性。

我知道这在这里是不利的，但是上市时间，正确的需求，正确的资金，良好的营销，正确的价格点和简单的好运对软件产品成功的影响远大于代码质量。

这是不是说代码质量应该被忽略，但是，你应该承认这只是众多因素之一。

在非常成功的产品中有许多简单的可怕代码示例（例如，最初的Apple OS将线程管理留给了应用程序）。

我想不出有什么漂亮的代码可以克服构思不好或价格过高的产品的例子。

因此，如果上市时间长于漂亮代码，上市时间应该优先考虑！

您必须将干净的代码与实际目标区分开：减少部署后修复缺陷的成本，并减少不必要的返工。当您谈论“编写简洁的代码以减少错误的数量”时，您在说宗教。当您谈论“将缺陷率降低10％，节省2个工作月的项目工作量”时，您是在谈论管理。干净的代码是一种用于提高代码库初始质量并从而降低总成本的工具，但它是众多工具之一。

以下论文从成本的角度解释了为什么第一次正确设置很重要：http : //www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

我不知道有任何具体研究，但请查看Steve McConnell的工作。

如果有人拥有，他会的。例如，两分钟的扫描发现了这一点（16岁，但今天仍然有意义）。

要添加到mattnz的答案中，如果您还没有的话，我想特别介绍一下Steve McConnell 撰写的《代码完整：软件构建实用手册》。除了可能会改善您的编码之外，他还引用了整本书中有关各种编码实践如何影响程序质量的大量研究。

作为一个例子（摘自本书）：

另一项针对450个例程的研究（这只是一个不寻常的巧合）发现，耦合/内聚比最高的例程的错误是耦合/内聚比最低的例程的7倍，而代价却是其最低20倍。进行修复（Selby和Basili 1991）。

同样，它曾经是该问题的第一答案，每个程序员应该读什么书中最有影响力的一本书？（尽管我看到这个问题的答案最近以一种me脚的方式进行了重组）