47

我喜欢我的代码井井有条，即正确格式化、可读、设计、测试、检查错误等。事实上，我对此很狂热。（也许甚至比狂热还多……）但根据我的经验，帮助代码质量的行动几乎没有实施。（我所说的代码质量是指您每天生成的代码的质量。软件质量与开发过程等的整个主题要广泛得多，而不是这个问题的范围。）

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

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

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

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

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

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

4

34 回答 34

32

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

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

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

我也看过很多关于持续集成的文章。

不写测试有一些常见的借口，但它们只是借口。如果有人想为他/她的新代码编写一些测试，那么这是可能的

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

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

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

  • 过于关注假设的例子，而且往往是某个人的创意，他们真的没有考虑过它对其他人的项目或与他正在处理的不同大小的代码库有多大的适用性，
  • 往往会变得过于情绪化，并在我们的代码中灌输太多的人类特征（想想“代码气味”这个词，就是一个很好的例子），
  • 被那些编写可怕的臃肿、过于复杂和冗长的代码，抽象层太多的人所支配，或者他们会通过“看起来我可以把这块代码拿来并在未来的项目中使用它”来判断代码是否可重用”，而不是更有意义的“我实际上已经能够获取这段代码并在不同的项目中重用它”。

我当然对编写高质量的代码很感兴趣。我只是倾向于被那些通常谈论代码质量的人拒之门外。

于 2009-07-02T21:07:38.863 回答
12

代码审查不是一门精确的科学。使用的指标在某种程度上是有争议的。该页面的某处：“您无法控制无法衡量的内容”

假设您有一个包含 35 个参数的 5000 行的巨大函数。你可以对它进行单元测试你想要多少，它可能会做它应该做的事情。无论输入是什么。所以基于单元测试，这个功能是“完美的”。除了正确性之外，您可能还需要衡量许多其他质量属性。性能、可扩展性、可维护性、可用性等。你有没有想过为什么软件维护是一场噩梦？

真正的软件项目质量控制不仅仅是检查代码是否正确。如果您检查软件开发的 V 模型，您会注意到编码只是整个方程式的一小部分。

软件质量控制可以达到项目总成本的 60%。这是巨大的。相反，人们更愿意削减到 0%，然后回家认为他们做出了正确的选择。我认为专注于软件质量的时间如此之少的真正原因是软件质量没有得到很好的理解。

  • 有什么要测量的？
  • 我们如何衡量它？
  • 谁来测量它？
  • 我会从测量中获得/失去什么？

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

此外，软件质量控制和软件工程作为一个整体是一门相对较新的学科。到目前为止，许多编程空间已被网络牛仔占据。您听说过多少次“任何人”都可以编程？任何人都可以编写肯定的代码，但并不是每个人都能成为程序员。

编辑 *

我看到了这篇论文（PDF），它来自那个说“你无法控制你无法测量的东西”的人。基本上，他是说控制一切并不像他最初想象的那样可取。这不是一个精确的烹饪食谱，您可以盲目地将其应用于软件工程学校想要让您思考的所有项目。他只是添加了另一个参数来控制，即“我想控制这个项目吗？需要吗？”

于 2009-07-02T20:49:21.397 回答
11
  • 懒惰/认为无聊
  • 管理层认为这是不必要的 - 无知的“做对了”的态度。
  • “这个小项目不需要代码质量管理”变成“现在在这个大项目上实施代码质量管理成本太高了”

我不同意这很无聊。可靠的单元测试设计使创建测试变得轻而易举，并且运行起来更加有趣。

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 分钟为一些复杂的功能编写一些随机测试并不会吸干你的创造性生活。

于 2009-07-02T20:45:53.353 回答
9

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

因为我们的职业不专业。

但是，有些人确实关心代码质量。例如，您可以从Software Craftsmanship运动的讨论组中找到有这种想法的人。但不幸的是，软件行业的大多数人不了解代码质量的价值，或者甚至不知道什么是好的代码。

于 2009-07-03T07:56:57.313 回答
6

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

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

当项目以一次性或一次性的形式开始时，也更难证明正式的工程流程是合理的。当然，在项目完成很久之后，随着不同的业务部门开始依赖它来完成自己的业务流程，它需要自己的生命（并变得突出）。

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

编辑：当然，这些坏习惯和许多其他的坏习惯是像 Thought Works 这样的咨询公司能够继续蓬勃发展的真正原因。

于 2009-07-04T22:03:31.650 回答
6

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

我认为主要原因是：

  • 开发商的懒惰。如果已经实施，为什么要花时间准备单元测试、审查解决方案？
  • 管理不当。如果有成千上万的新功能请求并且程序员可以简单地实现某些东西而不是关注已经实现的东西的质量，为什么还要要求开发人员处理代码质量。
于 2009-07-02T20:47:42.070 回答
5

我还没有看到提到的一个重要因素是任何流程改进（单元测试、持续集成、代码审查等）都需要在组织内有一个致力于技术的倡导者，在组织内具有适当的影响力，并愿意做让他人相信其价值的工作。

例如，我见过一个工程组织真正认真对待代码审查。那家公司的软件副总裁是一个真正的信徒，他会参与代码审查，以确保他们得到正确的完成。顺便说一句，在我合作过的任何团队中，他们的生产力和质量都是最好的。

另一个例子是当我在另一家公司实施单元测试解决方案时。起初，尽管管理层坚持，但没有人使用它。但是我们中的一些人确实努力谈论单元测试，并为任何想要开始单元测试的人提供尽可能多的帮助。最终，一旦他们开始看到单元测试的优势，几个最受尊敬的开发人员就签约了。在那之后，我们的测试覆盖率显着提高。

我只是想到了另一个因素——一些工具需要很长时间才能开始使用，而且启动时间可能很难获得。静态分析工具以这种方式可能很糟糕——你运行该工具，它会报告 2,000 个“问题”，其中大部分是无害的。一旦正确配置了工具，误报问题就会大大减少，但必须有人花时间，并致力于随着时间的推移维护工具配置。

于 2009-07-02T21:06:41.533 回答
5

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

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

我知道单元测试和单元测试框架至少有 7 年了。5-6 年前，我尝试在一个小项目中使用它，但直到最近几年我才学会了如何正确使用它。（即找到一种适合我和我的团队的方法......）

对我来说，其中一些是：

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

所以直到找到正确的方法；是的，这很无聊，没有回报，很难做，很费时间，等等。

编辑： 在这篇博文中，我深入探讨了这里给出的反对单元测试的一些原因。

于 2009-07-05T01:32:08.280 回答
4

当您考虑工程格言“好、快、便宜：选择两个”时，这非常简单。以我的经验，98% 的情况下，它既快又便宜，而另一个必然要受苦。

于 2009-07-04T22:11:10.573 回答
4

这是痛苦的基本心理学。当你在最后期限前奔波时，代码质量将占据最后席位。我们讨厌它，因为它枯燥乏味。

于 2009-07-02T20:59:19.067 回答
4

代码质量不受欢迎？让我质疑这个事实。

诸如 Agile 2009 之类的会议有大量关于持续集成、测试技术和工具的演讲。Devoxx 和 Jazoon 等技术会议也在这些主题中占有相当大的份额。甚至还有一个专门讨论持续集成和测试的完整会议（CITCON，每年在 3 大洲举行 3 次）。事实上，我个人的感觉是，这些谈话是如此普遍，以至于它们对我来说几乎是完全无聊的。

根据我作为顾问的经验，关于代码质量技术和工具的咨询实际上很容易销售（尽管报酬不高）。

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

从本质上讲，归根结底，这些技术仍然相当新（TDD 已有 15 年历史，CI 不到 10），它们必须与 1) 经理竞争，2) 开发人员的方法“到目前为止运行良好” （不管什么意思）。用 Geoffrey Moore 的话来说，现代代码质量技术仍处于采用曲线的早期阶段。整个行业采用它们需要时间。

然而，好消息是，我现在遇到了刚从大学毕业的开发人员，他们接受过 TDD 的教学并且对它真正感兴趣。这是最近的事态发展。一旦足够多的产品上市，该行业将别无选择，只能改变。

于 2009-07-03T12:30:31.443 回答
3

它让我想起了这个巨蟒短剧：

“令人兴奋？不，不是。它很乏味。乏味。乏味。我的上帝，这很乏味，它是如此的乏味、乏味、闷热、无聊和绝望的乏味。”

于 2009-07-02T20:47:52.023 回答
3

我会说有很多原因。

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

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

还有很多方法不容易测试的问题。它们可能依赖于数据库或类似数据库中的数据，这给设置模型数据以提供给方法带来了麻烦。即使你设置了模型数据——你能确定数据库的行为方式相同吗？

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

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

于 2009-07-02T20:49:48.620 回答
3

管理层需要重视现在花费更多时间以节省未来时间的价值。由于他们实际上无法衡量“未修复的错误”，因此他们通常更关心满足即时的截止日期和交付日期，而不是项目的长期质量。

于 2009-07-04T22:54:29.427 回答
3

“不写测试有一些常见的借口，但它们只是借口。”

他们是吗？让八位程序员聚在一个房间里，问他们一个关于如何最好地保持代码质量的问题，你会得到九个不同的答案，具体取决于他们的年龄、教育程度和偏好。1970 年代计算机科学家会嘲笑单元测试的概念。我不确定他们会错。

于 2009-07-02T20:53:52.760 回答
3

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

由于目标只是做出可行的东西，因此代码质量总是排在第二位。它增加了时间和成本。（我并不是说它不应该被认为是一件好事。）

99% 的情况下，第三方不会因为代码质量差而导致后果（除非您正在制作航天飞机或火车切换软件）。

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

阅读 Fred Brooks 的神话人物月。没有银弹。

于 2009-07-05T22:37:38.077 回答
2

单元测试需要额外的工作。如果程序员看到他的产品“工作”（例如，没有单元测试），为什么要这样做呢？尤其是当它不像在程序中实现下一个功能那么有趣时，等等。大多数人在谈到它时往往会变得懒惰，这不是一件好事......

于 2009-07-02T20:46:18.563 回答
2

代码质量是特定于上下文的，无论人们如何努力做到这一点，都很难一概而论。

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

于 2009-07-02T20:47:01.683 回答
2

现代写作中强调的许多关于代码质量的概念都忽略了代码质量的主要指标：代码首先必须是功能性的。其他一切都只是实现这一目标的手段。

有些人觉得他们没有时间学习软件工程的最新潮流，而且他们已经可以编写高质量的代码。我无法判断它们，但在我看来，如果人们无法阅读、理解和更改代码，那么长时间使用您的代码是非常困难的。

于 2009-07-04T22:46:35.120 回答
2

我也没有见过定期编写的单元测试。原因是在项目开始时代码更改过大，所以每个人都放弃了编写单元测试，直到一切都稳定下来。在那之后，每个人都很高兴并且不需要单元测试。所以我们有一些测试作为历史保留在那里，但它们没有被使用，并且可能与当前代码不兼容。

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

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

因此，在我看来，原因是时间损失，没有产生有用的功能，以及维护/更新旧测试以反映新业务规则的噩梦。即使有人愿意，也只有有经验的同事才能编写这些测试——至少要深入参与该项目一年，但确实需要两到三年。因此，新同事无法管理适当的测试。并且创建糟糕的测试是没有意义的。

于 2009-07-02T21:13:57.963 回答
2

在 x 年前由其他人编写的神秘代码丛林中捕捉一些极其重要的随机“功能”是“无聊的”，却不知道出了什么问题，为什么会出错，完全不知道有什么办法可以解决它当它应该在几个小时内结束时。当它完成后，没有人会因为巨大的延迟而感到满意。

去过那里 - 看到了。

于 2009-07-04T21:06:11.517 回答
2

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

我发现单元测试可以提高我的工作效率，但我看到很多格式错误、设计不可读的糟糕代码都通过了所有测试（通常是经过多次修补的老旧代码）。通过测试，您将获得一辆值得上路的斯柯达，而不是布里斯托尔的工艺。但是，如果您的代码质量“低”并且通过了测试并始终如一地满足用户的要求，那么这就是一个有效的商业模式。

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

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

另一件事是单元测试需要单元。一些开发人员发现模块化和封装很难做好。一个好的技术领导会创建一个模块化的架构来本地化一个单元的范围，这样就可以很容易地进行单独的测试；许多系统没有优秀的架构师来促进可测试性，或者没有定期重构以减少单元间的耦合。

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

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

我见过的每一组没有被自动化的编码约定在逻辑上都是不一致的，有时甚至到了无法使用的地步——甚至那些声称已经在多个项目中“成功”使用过的编码约定。非自动编码标准似乎是政治文件而不是技术文件。

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

我从来没有在允许编译器警告的商店工作过。

于 2009-07-05T14:43:09.257 回答
1

我不知道。你见过声纳吗？当然它是特定于Maven的，但将它指向你的构建和繁荣，很多指标。这类项目将促进这些代码质量指标成为主流。

于 2009-07-04T22:18:07.393 回答
1

I think that real problem with code quality or testing is that you have to put a lot of work into it and YOU get nothing back. less bugs == less work? no, there's always something to do. less bugs == more money? no, you have to change job to get more money. unit-testing is heroic, you only do it to feel better about yourself.

I work at place where management is encouraging unit-testing, however I am the only person that writes tests(i want to get better at it, its the only reason I do it). I understand that for others writing tests is just more work and you get nothing in return. surfing the web sounds cooler than writing tests.

someone might break your tests and say he doesn't know how to fix or comment it out(if you use maven).

Frameworks are not there for real web-app integration testing(unit test might pass, but it might not work on a web page), so even if you write test you still have to test it manually.

You could use framework like HtmlUnit, but its really painful to use. Selenium breaks with every change on a webpage. SQL testing is almost impossible(You can do it with DbUnit, but first you have to provide test data for it. test data for 5 joins is a lot of work and there is no easy way to generate it). I dont know about your web-framework, but the one we are using really likes static methods, so you really have to work to test the code.

于 2010-03-15T20:46:41.830 回答
1

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

这种态度通常会随着单元测试捕获越来越多的错误而逐渐消失，您意识到这些错误会很严重并且难以在生产环境中定位。

于 2009-07-02T20:47:47.283 回答
1

你被更便宜的刚毕业的大学生或外包工人取代的可能性与你的代码的可读性成正比。

于 2009-07-04T22:40:34.040 回答
1

当程序员忘记，或者天真，并且表现得好像他们的代码在以后不会被其他人查看（或者他们自己几个月/几年之后）时，就会出现很多情况。

此外，评论并不像实际编写一段漂亮的代码那样“酷”。

于 2009-07-02T21:05:26.653 回答
1

几个人提到的另一件事是，大多数开发工程师都是糟糕的测试人员。他们不具备有效测试自己代码的专业知识或思维定势。这意味着单元测试对他们来说似乎不是很有价值——因为他们所有的代码总是通过单元测试，为什么还要编写它们呢？

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

于 2009-07-02T21:11:32.867 回答
1

人们对代码的“好”意味着什么没有常识。很多人会沦落到“我跑了”甚至“我写了”的地步。

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

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

至于它是否重要，这已经被讨论过很多次了。如果您的代码寿命很长，这非常重要。如果它真的永远不会出售或不会部署，那么它显然不会。如果不值得做，那就不值得做好。

但是，如果您不练习编写有道德的代码，那么您就无法在重要的时候做到这一点。我认为人们已经练习过做不好的工作，并且不知道其他任何事情。

于 2010-03-11T22:44:55.067 回答
1

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

静态分析真的很酷，但它只是警告。例如FindBugs有投射问题，你应该使用它instaceof来消除警告。我这样做并不是为了让 FindBugs 开心。

我认为太复杂的代码不是方法有 500 行代码，而是方法使用 500 种其他方法和许多抽象只是为了好玩。我认为代码质量大师应该真正致力于发现代码何时过于复杂并且不太关心小事情（您可以使用正确的工具快速重构它们。）。

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

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

于 2009-07-05T22:31:23.347 回答
1

我的简短回答是：除非您是开支票的人（即自由职业者、拥有公司等），否则大多数时候交付速度对您的雇主而言更为重要。鉴于这一事实，有时程序员在面临最后期限时需要采取“快速而肮脏”的方式。

其他因素，例如糟糕的分析和在最后一刻提出更改的客户，使“质量”代码的生产更加困难。

于 2010-07-11T14:39:48.997 回答
1

代码质量并没有让提供商赚更多的钱，换个角度来看，提供商想通过指出代码质量差的原因来要求更多的人，更多的时间。

总而言之，IT 服务业务规模（在过去的二十年中）是通过糟糕的代码质量实现的，它们被允许在官方上把事情弄得一团糟，因为客户是通过流程和认证机构出售的。

除非新的 IT 业务模型出现在计费的 T&M 之外，否则我们不能指望代码质量会占有一席之地。

我对 IT 离岸业务模式应该如何改变的一些想法是

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

简而言之，考虑从时间和身体 (T&M) 业务转向时间和结果责任 (T&A)

于 2012-09-25T06:05:25.537 回答
0

在网络世界中，我认为这是因为上市时间至关重要。错误可以即时修复。重点是让一些东西快速冷却。如果钱向你飞来，你就修好它。但首先你想看看你的项目是否“坚持”。如果没有，你做一些新的事情。但是，如果您有 Twitter 或 Facebook 之类的热门产品，那么您就会认真对待工程。

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

于 2009-07-05T22:51:24.290 回答
-1

我总是使用质量代码，而且我喜欢符合标准。甚至我的 html 也有一个 doctype，并没有多少人能这么说。

我曾经遇到过这样的代码，它不是在遍历数据库的每个条目时打印文本，而是将该文本附加到一个变量中，并在循环之后打印它。

代码对我来说失败了。它超过了内存限制。

于 2011-03-09T15:49:47.030 回答