我喜欢我的代码井然有序，即格式正确、可读、设计、测试、检查错误等。事实上，我对此很狂热。 ( Maybe even more than fanatic... ) 但根据我的经验，帮助代码质量的行动很难实现。 (我所说的代码质量是指您每天生成的代码的质量。软件质量与开发过程等的整个主题要广泛得多，而不是这个问题的范围。)
代码质量似乎并不受欢迎。根据我的经验，一些例子包括
可能每个 Java 开发人员都知道 JUnit，几乎所有语言都实现 xUnit 框架，但在我知道的所有公司中，只有很少的适当的单元测试存在(如果有的话)。我知道由于技术限制或紧迫的截止日期，并不总是可以编写单元测试，但在我看到的情况下，单元测试是一种选择。如果开发人员想为他/她的新代码编写一些测试，他/她可以这样做。我的结论是开发人员不想编写测试。
静态代码分析通常在小型项目中使用，但并不真正用于强制编码约定或查找企业项目中可能的错误。通常，甚至诸如潜在空指针访问之类的编译器警告也会被忽略。
session 发言人和杂志会谈论很多关于 EJB3.1、OSGI、云和其他新技术，但很少谈论新的测试技术或工具、新的静态代码分析方法(例如 SAT 求解)、开发流程帮助为了保持更高的质量，如何对一些令人讨厌的遗留代码进行测试，...(我没有参加很多 session ，对于敏捷主题的 session 来说，它可能看起来有所不同，因为单元测试和 CI 等在那里具有更高的值(value).)
那么为什么代码质量如此不受欢迎/被认为很无聊？
编辑:
感谢您的回答。其中大多数涉及单元测试(并已在 related question 中进行过讨论)。但是还有很多其他方法可以用来保持较高的代码质量(请参阅 related question )。即使您无法使用单元测试，您也可以使用每日构建，向 IDE 或开发流程添加一些静态代码分析，尝试结对编程或强制审查关键代码。
最佳答案
对于 Stack Overflow 部分的一个明显答案是它不是一个论坛。它是一个问题和答案的数据库，这意味着试图避免重复的问题。
您能想到多少个关于代码质量的不同问题？这就是为什么没有 50,000 个关于“代码质量”的问题。
除此之外，任何声称 session 发言人不想谈论单元测试或代码质量的人显然需要参加更多 session 。
我也看过足够多关于持续集成的文章。
There are the common excuses for not writing tests, but they are only excuses. If one wants to write some tests for his/her new code, then it is possible
哦，真的吗？即使你的老板说“我不会因为你在单元测试上浪费时间而付钱给你”？ 即使您正在使用一些没有单元测试框架的嵌入式平台？ 即使您的工作期限很紧，试图实现某些短期目标，甚至以牺牲长期代码质量为代价？
没有。编写单元测试并不“总是可能”。它有很多常见的障碍。这并不是说我们不应该尝试编写更多更好的测试。只是有时候，我们没有机会。
就我个人而言，我厌倦了“代码质量”讨论，因为它们倾向于
- 过于关注假设的示例，并且往往是某些人的创意，他们实际上没有考虑过它对于其他人的项目或与他正在开发的代码库大小不同的适用性，<
- 倾向于变得过于情绪化，并给我们的代码注入(inject)太多的人类特征(想想术语“代码味道”，作为一个很好的例子)，
- 被那些编写可怕的臃肿、过于复杂和冗长的代码以及太多抽象层的人所主导，或者他们会通过“看起来我可以直接使用这段代码并在其中使用它”来判断代码是否可重用。一个 future 的项目”，而不是更有意义的“我实际上已经能够获取这段代码并在不同的项目中重用它”。
我当然对编写高质量代码感兴趣。我只是对那些通常谈论代码质量的人感到厌烦。
关于unit-testing - 为什么代码质量讨论会引起强烈反响？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1076575/