为什么代码质量不受欢迎？

Question

我喜欢我的代码是有序的，即格式正确，可读，设计，测试，检查错误等。事实上我对它很狂热。 （Maybe even more than fanatic...）但根据我的经验，帮助代码质量的行动很难实现。 （通过代码质量，我的意思是你每天生成的代码的质量。软件质量与开发过程等的整个主题要广泛得多，而不是这个问题的范围。）

代码质量似乎并不受欢迎。我的经验中的一些例子包括

• 可能每个Java开发人员都知道JUnit，几乎所有语言都实现了xUnit框架，但在我所知道的所有公司中，只有很少的正确单元测试存在（如果有的话）。我知道由于技术限制或紧迫的截止日期，并不总是可以编写单元测试，但在我看到的情况下，单元测试可能是一种选择。如果开发人员想为他/她的新代码编写一些测试，他/她可以这样做。我的结论是开发人员不想编写测试。

• 静态代码分析通常在小型项目中进行，但并不真正用于强制执行编码约定或在企业项目中发现可能的错误。通常甚至会忽略像潜在空指针访问这样的编译器警告。

• 会议发言人和杂志会谈论很多关于EJB3.1，OSGI，云和其他新技术，但几乎没有关于新的测试技术或工具，新的静态代码分析方法（例如SAT求解），开发过程的帮助为了保持更高的质量，遗传代码的一些讨厌的野兽如何被测试，...（我没有参加很多会议，它可能看起来不同于敏捷话题的会议，因为单元测试和CI等具有更高的价值。）

那为什么代码质量如此不受欢迎/被认为无聊？

修改
谢谢你的回答。其中大多数涉及单元测试（已在related question中讨论过）。但是还有很多其他的东西可以用来保持高代码质量（参见related question）。即使您无法使用单元测试，也可以使用每日构建，向IDE或开发过程添加一些静态代码分析，尝试结对编程或强制执行关键代码的审核。

Answer 1

Stack Overflow部分的一个明显答案是它不是一个论坛。它是一个问答数据库，这意味着可以避免重复的问题。

您能想到多少关于代码质量的不同问题？这就是为什么关于“代码质量”没有50,000个问题。

除此之外，任何声称会议发言人都不想谈论单元测试或代码质量的人显然需要参加更多的会议。

我还看到了关于持续集成的文章。

  

没有共同的借口   写测试，但他们只是   借口。如果有人想写一些   测试他/她的新代码，然后是   可能的

哦，真的吗？即使你的老板说“我不会因为你在单元测试中浪费时间而付钱”？ 即使您正在开发一些没有单元测试框架的嵌入式平台？ 即使你在一个紧迫的期限内工作，试图达到一些短期目标，即使以长期代码质量为代价？

没有。编写单元测试并非“总是可行”。它有许多常见的障碍。这并不是说我们不应该尝试来编写更多更好的测试。有时候，我们没有机会。

就个人而言，我厌倦了“代码质量”讨论，因为他们倾向于

• 过于关注假设的例子，并且往往是某些个人的心血结晶，他们真的没有考虑过对其他人的项目有多适用，或者与他正在研究的不同大小的代码库，
• 往往过于情绪化，并且为我们的代码注入了太多的人类特征（想想“代码味道”一词，这是一个很好的例子），
• 由那些用过多的抽象层写出可怕的臃肿，过于复杂和冗长的代码的人来主导，或者谁将判断代码是否可以重用“看起来我可以只接受这段代码并使用它未来的项目“，而不是更有意义的”我实际上已经能够获取这些代码并在不同的项目中重用它。“

我当然有兴趣编写高质量的代码。我倾向于被通常谈论代码质量的人关闭。

Answer 2

代码审查不是一门精确的科学。使用的Metrics在某种程度上是值得商榷的。在该页面的某处：“您无法控制无法衡量的内容”

假设您有一个包含35个参数的5000行的巨大功能。您可以对它进行单元测试，但它可能完全按照预期进行测试。无论输入是什么。所以基于单元测试，这个功能是“完美的”。除了正确性之外，还有很多其他quality attributes you might want to measure。性能，可扩展性，可维护性，可用性等。你有没有想过为什么软件维护是一场噩梦？

真正的软件项目质量控制不仅仅是检查代码是否正确。如果您查看V-Model of software development，您会发现编码只是整个等式的一小部分。

软件质量控制可以达到项目总成本的60％。这是巨大的。相反，人们更愿意降低到0％并回家认为他们做出了正确的选择。我认为为什么这么少的时间专注于软件质量的真正原因是因为软件质量还不是很好理解。

• 有什么可衡量的？
• 我们如何衡量它？
• 谁来衡量呢？
• 测量它会得到什么/失去什么？

许多编码器血汗工厂都没有意识到“现在减少错误”和“后来更多利润”之间的关系。相反，他们所看到的只是“浪费时间”和“现在利润减少”。即使显示漂亮的图形显示相反的情况。

此外，软件质量控制和software engineering作为一个整体是一个相对较新的学科。到目前为止，很多编程空间都被网络牛仔所采用。你有多少次听说“任何人”可以编程？任何人都可以编写可靠的代码，但并不是每个人都可以成为程序员。

编辑*

我遇到this paper (PDF)来自那个说“你无法控制你无法衡量的东西”的人。基本上他说控制一切并不像他最初认为的那样令人满意。这不是一个精确的烹饪配方，你可以盲目地应用于所有项目，如软件工程学校想让你思考。他只是添加了另一个参数来控制“我想控制这个项目吗？它是否需要？”

Answer 3

• 懒惰/考虑无聊
• 管理层觉得没必要 - 无知的“只做正确”的态度。
• “这个小项目不需要代码 质量管理“变成”现在 实施成本太高 这个大的代码质量管理 项目“

我不同意它虽然很沉闷。坚固的单元测试设计使创建测试变得轻而易举，让它们更加有趣。

Calculating vector flow control - PASSED
Assigning flux capacitor variance level - PASSED
Rerouting superconductors for faster dialing sequence - PASSED
Running Firefly hull checks - PASSED
Unit tests complete. 4/4 PASSED.

像任何事情一样，如果你做了太多事情就会感到无聊，但是经过几个小时的编码后花费10或20分钟为一些复杂的功能编写一些随机测试并不会给你的创作生活带来麻烦。

Answer 4

  

为什么代码质量如此不受欢迎？

因为我们的职业不专业。

然而，是关心代码质量的人。你可以在Software Craftsmanship运动discussion group中找到志同道合的人。但遗憾的是，软件业务中的大多数人并不了解代码质量的价值，或者甚至不知道什么构成了良好的代码。

Answer 5

简短回答：除非出现问题，否则只有其他人（主要是经验丰富的开发人员和工程师）才会欣赏这些无形资产。在这一点上，管理者和客户都在哗然，并要求为什么没有正式的流程。

更长的答案：这种短视的方法不仅限于软件开发。美国汽车工业（或其左翼）可能就是最好的例子。

当项目一次性或一次性开始时，也很难证明正式的工程流程是正确的。当然，在项目完成很久之后，它需要自己的生命（并且变得突出），因为不同的业务部门开始依赖于它们自己的业务流程。

此时需要设计新的解决方案;但是，如果没有使用这些工具和良好实践的实践，这些工具就没有用处了。它们成为一个耗时的障碍。在IT团队支持业务的公司中，我经常看到这种情况，在这些公司中，开发通常是反动的而不是主动的。

编辑：当然，这些坏习惯和许多其他人是思想工作等咨询公司能够继续茁壮成长的真正原因。

Answer 6

我想答案与“为什么代码质量不受欢迎？”这个问题相同。

我认为最重要的原因是：

• 开发者的懒惰。为什么要花时间准备单元测试，检查解决方案，如果它已经实现了？
• 管理不当。为什么要求开发人员处理代码质量，如果有成千上万的新功能请求，程序员可以简单地实现某些东西，而不是考虑已经实现的东西的质量。

Answer 7

  

可能每个Java开发人员都知道JUnit ......

虽然我相信大多数或许多开发人员都听说过JUnit / nUnit /其他测试框架，但是很少有人知道如何使用这样的框架编写测试。从那些人中，很少有人很好地理解如何使测试成为解决方案的一部分。

我已经了解了至少7年的单元测试和单元测试框架。我试图在5-6年前的一个小项目中使用它，但仅在最近几年我才学会了如何正确地做到这一点。 （即找到适合我和我的团队的方式......）

对我来说，其中一些事情是：

• 寻找适合单元测试的工作流程。
• 在我的IDE中集成单元测试，并具有运行/调试测试的快捷方式。
• 学习如何测试什么。 （比如如何测试登录或访问文件。如何从数据库中抽象自己。如何模拟和使用模拟框架。学习提高可测试性的技术和模式。）
• 进行一些测试比完全没有测试要好。
• 发现错误后，可以稍后编写更多测试。编写证明错误的测试，然后修复错误。
• 你必须练习才能擅长。

所以直到找到正确的方法;是的，它很枯燥，没有回报，很难做，很费时间等等。

修改 在这篇blogpost中，我深入探讨了针对单元测试的一些原因。

Answer 8

我没有看到提到的一个重要因素是任何流程改进（单元测试，连续集成，代码审查等等）需要在组织内拥有致力于该技术的拥护者，具有适当的影响力在组织内部，并愿意做的工作，以说服他人的价值。

例如，我已经看到了一个真正认真对待代码审查的工程组织。那家公司有一个软件副总裁，他是一个真正的信徒，他会参与代码审查，以确保他们正确完成。他们偶然拥有与我合作过的任何团队的最佳生产力和质量。

另一个例子是我在另一家公司实施了单元测试解决方案。尽管管理层坚持，但最初没有人使用它。但我们中的一些人真正努力谈论单元测试，并为想要开始单元测试的人提供尽可能多的帮助。最终，一些最受尊敬的开发者签约后，他们开始看到单元测试的优势。之后，我们的测试覆盖率大幅提升。

我只想到了另一个因素 - 有些工具需要花费大量时间才能开始使用，并且启动时间很难实现。静态分析工具可能很糟糕 - 你运行该工具，并报告2,000个“问题”，其中大多数都是无害的。一旦正确配置了工具，误报问题就会大大减少，但有人必须花时间，并承诺随着时间的推移维护工具配置。

Answer 9

这是疼痛的基本心理。当你跑步以满足截止日期时，代码质量需要最后一个席位。我们讨厌它，因为它枯燥乏味。

Answer 10

代码质量不受欢迎？让我对这个事实提出异议。

Agile 2009等会议就持续集成，测试技术和工具进行了大量演讲。像Devoxx和Jazoon这样的技术会议也有相应的主题。 甚至还有一个专门讨论持续集成的会议。测试（CITCON，每年在3大洲进行3次）。 事实上，我个人的感觉是，这些谈话非常普遍，以至于他们处于对我完全无聊的边缘。

根据我作为顾问的经验，咨询代码质量技术＆amp;工具实际上很容易出售（虽然收入不高）。

尽管如此，虽然我认为代码质量是一个受欢迎的讨论主题，但我宁愿同意开发人员（通常）不做好或足够的测试这一事实。我对这个事实有一个相当简单的解释。

基本上，它归结为这些技术仍然相当新的事实（TDD是15岁，CI小于10）并且他们必须与1）经理竞争，2）开发人员的方式“运作良好”到目前为止“（无论那意味着什么）。 用Geoffrey Moore的话来说，现代代码质量技术仍处于采用曲线的早期阶段。整个行业采用它们需要一段时间。

然而，好消息是，我现在遇到了刚从大学毕业的开发人员，这些开发人员已经教过TDD并且真正对它感兴趣。这是最近的发展。一旦有足够的这些产品进入市场，该行业别无选择，只能改变。

Answer 11

当你考虑工程格言“好，快，便宜：选择两个”时，这很简单。根据我的经验，98％的时间，它是快速和廉价的，并且必要时另一方必须受苦。

Answer 12

它让我想起了这个Monty Python小品：

“令人兴奋吗？不，不是。它很沉闷。沉闷。沉闷。我的上帝很沉闷，它是如此的沉闷和乏味，闷热，无聊和绝对的DULL。”

Answer 13

我说出于很多原因。

首先，如果应用程序/项目很小或者没有大规模的重要数据，那么编写测试所需的时间最好用于编写实际的应用程序。

有一个阈值，其质量要求达到了需要进行单元测试的水平。

还存在许多方法不易测试的问题。它们可能依赖于数据库或类似数据中的数据，这会产生设置要提供给方法的模型数据的麻烦。即使您设置了模型数据 - 您能确定数据库的行为方式是否相同？

在发现尚未考虑的问题时，单元测试也很薄弱。也就是说，单元测试不能模拟意外情况。如果您没有考虑断电会发生什么，如果网络链路发送的CRC数据仍然是CRC正确的。为此编写测试是徒劳的。

我赞成代码检查，因为它们让程序员可以与其他程序员分享经验和代码风格。

Answer 14

“没有编写测试的常见借口，但它们只是借口。”

是吗？让八位程序员在一个房间里，向他们询问有关如何最好地保持代码质量的问题，并且根据他们的年龄，教育程度和喜好，您将得到九个不同的答案。 20世纪70年代，计算机科学家们会嘲笑单元测试的概念;我不确定他们会不会错。

Answer 15

管理需要以花费更多时间的价值出售，以节省时间。由于他们实际上无法衡量“不固定的错误”，他们往往更关心如何满足他们的最后期限＆amp;发货日期比项目的长期质量。

Answer 16

代码质量是主观的。主观话题总是乏味的。

由于目标只是制作有效的东西，因此代码质量总是排在第二位。它增加了时间和成本。 （我不是说它不应该被视为好事。）

99％的时间，没有第三方因代码质量差的问题（除非您正在制作太空飞船或培训切换软件）。

• 有用吗？ =混凝土。
• 漂亮吗？ =在旁观者的眼中。

阅读弗雷德布鲁克斯的神话人月。没有银弹。

Answer 17

缺乏“代码质量”不会使用户，销售人员，架构师或代码开发人员付出代价;它减慢了下一次迭代，但我可以想到几个成功的产品似乎是由头发和泥浆制成的。

我发现单元测试让我的工作效率提高了，但是我看到很多格式错误，设计不良的代码都通过了所有的测试（通常是多次修补的长牙码）。通过测试，你会获得一个有道路的斯柯达，而不是Bristol的工艺。但是，如果您的“代码质量低”并通过测试并始终满足用户的要求，那么这就是有效的商业模式。

  

我的结论是开发人员不想编写测试。

我不确定。部分地，软件中的整个教育过程不是由测试驱动的，并且可能应该是 - 而不是要求进行练习，将单元测试给予学生。在数学问题上运行检查是正常的，为什么不在软件工程中呢？

另一件事是单元测试需要单元。一些开发人员发现模块化和封装很难做得很好。一个好的技术主管将创建一个模块化的架构，将一个单元的范围本地化，从而使其易于单独测试;许多系统没有很好的架构师，他们不具备可测试性，或者没有足够的重构来减少单元间的耦合。

由于固有耦合，测试分布式或GUI驱动的应用程序也很困难。我只参加了一个做得那么好的团队，并且拥有与开发部门一样大的测试部门。

  

静态代码分析通常在小型项目中进行，但并不真正用于强制执行编码约定或在企业项目中发现可能的错误。

我见过的每一套未经自动化的编码约定在逻辑上都是不一致的，有时甚至是不可用的 - 甚至声称在几个项目中已经“成功”使用的那些。非自动编码标准似乎是政治文件而非技术文件。

  

通常甚至会忽略像潜在空指针访问这样的编译器警告。

我从未在一家容忍编译警告的商店工作过。

Answer 18

现代写作中强调代码质量的许多概念忽略了代码质量的主要指标：代码必须首先发挥作用。其他一切只是达到这一目的的手段。

有些人不觉得他们有时间学习软件工程的最新时尚，并且他们已经可以编写高质量的代码了。我不是在判断它们的地方，但在我看来，如果人们无法阅读，理解和改变你的代码，那么你的代码很难被长时间使用。

Answer 19

单元测试需要额外的工作。如果程序员发现他的产品“有效”（例如，没有单元测试），那么为什么呢？特别是当它不像在程序中实现下一个功能那样有趣时，等等。大多数人只是倾向于懒惰，这不是一件好事...

Answer 20

在x年前由别人写的神秘代码丛林中超过一天捕获一些随机的“特征”是非常重要的“无聊”，毫不知道出了什么问题，为什么它出错了，绝对没有想法是什么当它应该在几个小时内结束时可以解决它。当它完成后，没有人满足于巨大的延迟。

去过那里 - 见过。

Answer 21

我还没有看到定期编写的单元测试。之所以给出这样的原因是因为代码在项目开始时进行了太多的改动，所以每个人都放弃了编写单元测试，直到一切都稳定下来。之后，每个人都很开心，不需要进行单元测试。所以我们有一些测试留在那里作为历史，但他们没有使用，可能与当前的代码不兼容。

我个人认为为大型项目编写单元测试是不可行的，尽管我承认我没有尝试过，也没有和那些做过的人交谈过。业务逻辑中有如此多的规则，如果你只是稍微改变一些地方，你就无法知道哪些测试要更新，而不是崩溃的那些。谁知道，旧的测试现在可能无法涵盖所有​​可能性，并且需要时间来回忆五年前写的内容。

另一个原因是缺乏时间。如果您分配了一个任务，其中显示“完成时间：O，5人/天”，您只有时间实施它并对其进行浅层测试，而不是考虑所有可能的情况以及与其他项目部分的关系并写下所有必要的测试。实施某些东西可能需要0.5天，而编写测试需要几周时间。除非你特别给出了创建测试的命令，否则没有人会理解大量的时间损失，这将导致大喊大叫/差评。不，对于我们复杂的企业应用程序，我想不出五分钟内任务的良好测试覆盖率。这需要时间，可能需要对大多数应用程序模块有深入的了解。

因此，我看到它们的原因是时间损失，它不会产生任何有用的功能，也不会成为维护/更新旧测试以反映新业务规则的噩梦。即使有人想，只有经验丰富的同事才能编写这些测试 - 至少一年深度参与项目，但实际需要两到三年。所以新同事不管理正确的测试。创建糟糕的测试毫无意义。

Answer 22

代码质量是特定于上下文的，无论人们尝试多少努力都很难概括。

它类似于理论与应用之间的差异。

Answer 23

我不知道。你看过Sonar了吗？当然它是Maven具体的，但指向你的构建和繁荣，许多指标。这种项目将促进这些代码质量指标成为主流。

Answer 24

您被更便宜的大学生或外包工作者取代的可能性与您的代码的可读性成正比。

Answer 25

有些人接触到的另一件事是，大多数开发工程师都是可怕的测试人员。他们没有专业知识或思维模式来有效地测试自己的代码。这意味着单元测试对他们来说似乎没有什么价值 - 因为他们的所有代码总是通过单元测试，为什么还要编写它们呢？

教育和指导可以为此提供帮助，测试驱动的开发也是如此。如果你先编写测试，那么你至少主要考虑测试，而不是试图完成测试，所以你可以提交代码......

Answer 26

当程序员忘记或幼稚时，很多事情都会出现，并且他们的代码将在以后被其他人查看（或者他们自己几个月/几年）。

此外，评论并不像实际编写光滑的代码那样“酷”。

Answer 27

我经常遇到的一种态度（但从来没有来自已经是质量上瘾者的程序员）是编写单元测试只会迫使你编写更多代码而不需要任何额外的功能。他们认为，在产品上添加功能而不仅仅是创建“元代码”时，最好花些时间。

这种态度通常会逐渐消失，因为单元测试会捕获越来越多的错误，你会发现这些错误在生产环境中很难找到。

Answer 28

我认为代码质量被高估了。我做的越多，对我的意义就越小。代码质量框架更喜欢过于复杂的代码。你永远不会看到像“这段代码过于抽象，没有人会理解它”这样的错误。但是，例如PMD说我班上有太多方法。因此，我应该将类切换为抽象类/类（自PMD不关心我做的最好的方法）或基于功能切割类（最糟糕的方式，因为它可能仍然有太多方法 - 在那里）。

静态分析真的很酷，但它只是警告。例如，FindBugs存在投射问题，您应该使用instaceof警告消失。我不这样做只是为了让FindBugs高兴。

我觉得太复杂的代码不是当方法有500行代码时，而是当方法使用500个其他方法和许多抽象只是为了好玩。我认为代码质量大师应该真正找到代码太复杂而不关心小事情的东西（你可以用很快的方法用正确的工具重构它们。）。

我不喜欢代码覆盖的想法，因为它真的没用，并使单元测试无聊。我总是测试具有复杂功能的代码，但只测试代码。我在一个100％代码覆盖率的地方工作，改变任何事情都是一场真正的噩梦。因为当你改变任何东西时，你不得不担心破坏（写得不好）的单元测试并且你永远不知道如何处理它们，很多时候我们只是将它们注释掉并添加todo以便以后修复它们。

我认为单元测试有它的位置，例如我在我的网页解析器中做了很多单元测试，因为我一直发现不同的错误或不支持的标签。如果你想测试数据库逻辑，测试数据库程序真的很难，DbUnit真的很难用。

Answer 29

人们对代码的“好”意味着什么并不常见。很多人会降到“我跑它”甚至“我写它”的水平。

我们需要对好的代码是什么以及是否重要有共同的感觉。对于第一部分，我写了一些想法：

http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html

至于是否重要，这已经被覆盖了很多次。如果你的代码要活得很长，这很重要。如果它真的不会出售或不会被部署，那么它显然不会。如果它不值得做，那就不值得做好。

但如果你不练习编写良性代码，那么在重要的时候就不能这样做。我认为人们从事过差工作，不知道其他任何事情。

Answer 30

我认为代码质量或测试的真正问题在于你必须投入大量的工作，而你却得不到任何回报。减少错误==少工作？不，总有事可做。少bug ==更多钱？不，你必须改变工作以获得更多的钱。单元测试英雄，你只是为了让自己感觉更好。

我在管理层鼓励单元测试的地方工作，但是我是唯一一个编写测试的人（我想要做得更好，这是我做这件事的唯一原因）。我理解，对于其他人而言，编写测试只需要做更多工作，而没有任何回报。网上冲浪比写测试更酷。

有人可能会破坏你的测试并说他不知道如何修复或评论它（如果你使用maven）。

框架不适用于真正的网络应用程序集成测试（单元测试可能会通过，但它可能无法在网页上运行），因此即使您编写测试，您仍然必须手动测试它。

您可以使用 HtmlUnit 这样的框架，但使用它真的很痛苦。 Selenium 会因网页上的每次更改而中断。 SQL测试几乎是不可能的（您可以使用 DbUnit 来完成，但首先必须为它提供测试数据.5个连接的测试数据是很多工作，没有简单的方法来生成它）。我不知道您的网络框架，但我们使用的那个非常喜欢静态方法，因此您必须努力测试代码。

Answer 31

我的简短回答是：除非您是撰写支票的人（即自由职业者，拥有公司等），否则大部分时间的解救速度对您的雇主来说更为重要。鉴于这一事实，有些时候程序员在面临最后期限时需要采用“快速而肮脏”的方式。

其他因素，例如分析不佳以及提出最新更改的客户，会使“质量”代码的制作更加困难。

Answer 32

代码质量不会让提供商赚更多的钱，其他方式来看，提供商想要更多的人，更多的时间通过指出不良代码质量的原因。

总的来说，IT服务业务规模（过去二十年）是通过糟糕的代码质量实现的，因为客户在流程和认证机构上销售，所以它们可以正式使事情变得混乱。

除非新的IT商业模式超出T＆amp; M的计费范围，否则我们不能指望代码质量会占据一席之地。

我对IT外包业务模式应该如何改变的一些看法是

http://communities.nasscom.in/discussion/topics/531869/messages

简而言之，考虑从时间和身体（T＆amp; M）业务转向结果的时间和责任（T＆amp; A）

Answer 33

在网络世界中，我认为这是因为上市时间至关重要。错误可以在运行中修复。重点是快速降温。如果钱飞向你，你就解决它。但首先你要看看你的项目是否“坚持”。如果没有，你会做一些新的事情。但如果你有像Twitter或Facebook这样的热门话题，那么你就会认真对待工程学。

但是有各种各样的编程任务。如果您要将游戏卡带或光盘发送出去，那么（大多数情况下）一旦它们处于野外就无法修复它们。

Answer 34

我总是使用质量代码，我喜欢符合标准。即使我的HTML有一个doctype，也没有多少人可以这么说。

我曾经遇到过代码，它不是在数据库的每个条目中运行时打印文本，而是将该文本附加到变量，然后在循环之后将其打印出来。

代码对我失败了。它超出了内存限制。