为什么代码质量讨论会引起强烈反响？
我喜欢我的代码井然有序，即格式正确、可读、设计、测试、检查错误等。事实上，我对此很狂热。 （也许不仅仅是狂热......）但根据我的经验，有助于代码质量的行动很难实施。 （我所说的代码质量是指您每天生成的代码的质量。软件质量与开发过程等的整个主题要广泛得多，而不是这个问题的范围。）
代码质量似乎并不受欢迎。 我的经验中的一些例子包括：
可能每个 Java 开发人员都知道 JUnit，几乎所有语言都实现 xUnit 框架，但在我知道的所有公司中，只有很少的适当的单元测试存在（如果有的话）。 我知道由于技术限制或紧迫的截止日期，并不总是可以编写单元测试，但在我看到的情况下，单元测试是一种选择。 如果开发人员想为他/她的新代码编写一些测试，他/她可以这样做。 我的结论是开发人员不想编写测试。
静态代码分析经常在小型项目中使用，但并不真正用于强制编码约定或查找企业项目中可能的错误。 通常，甚至像潜在的空指针访问这样的编译器警告也会被忽略。
会议发言人和杂志会谈论很多关于EJB3.1、OSGI、云和其他新技术，但很少谈论新的测试技术或工具、新的静态代码分析方法（例如SAT求解）、有助于维持更高水平的开发流程。质量，遗留代码的一些令人讨厌的野兽是如何接受测试的，...（我没有参加很多会议，对于敏捷主题的会议来说，它看起来可能有所不同，因为单元测试和 CI 等在那里具有更高的价值。）< /p>
质量 为什么代码质量如此不受欢迎/被认为很无聊？
编辑：
感谢您的回答。 其中大多数涉及单元测试（并且已在 相关问题）。 但是还有很多其他东西可以用来保持高代码质量（请参阅相关问题）。 即使您无法使用单元测试，您也可以使用每日构建，向 IDE 或开发流程添加一些静态代码分析，尝试结对编程或强制审查关键代码。
I like my code being in order, i.e. properly formatted, readable, designed, tested, checked for bugs, etc. In fact I am fanatic about it. (Maybe even more than fanatic...) But in my experience actions helping code quality are hardly implemented. (By code quality I mean the quality of the code you produce day to day. The whole topic of software quality with development processes and such is much broader and not the scope of this question.)
Code quality does not seem popular. Some examples from my experience include
Probably every Java developer knows JUnit, almost all languages implement xUnit frameworks, but in all companies I know, only very few proper unit tests existed (if at all). I know that it's not always possible to write unit tests due to technical limitations or pressing deadlines, but in the cases I saw, unit testing would have been an option. If a developer wanted to write some tests for his/her new code, he/she could do so. My conclusion is that developers do not want to write tests.
Static code analysis is often played around in small projects, but not really used to enforce coding conventions or find possible errors in enterprise projects. Usually even compiler warnings like potential null pointer access are ignored.
Conference speakers and magazines would talk a lot about EJB3.1, OSGI, Cloud and other new technologies, but hardly about new testing technologies or tools, new static code analysis approaches (e.g. SAT solving), development processes helping to maintain higher quality, how some nasty beast of legacy code was brought under test, ... (I did not attend many conferences and it probably looks different for conferences on agile topics, as unit testing and CI and such has a higher value there.)
So why is code quality so unpopular/considered boring?
EDIT:
Thank your for your answers. Most of them concern unit testing (and has been discussed in a related question). But there are lots of other things that can be used to keep code quality high (see related question). Even if you are not able to use unit tests, you could use a daily build, add some static code analysis to your IDE or development process, try pair programming or enforce reviews of critical code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（30）
Stack Overflow 部分的一个明显答案是它不是一个论坛。 它是一个问题和答案的数据库，这意味着试图避免重复的问题。
您能想到多少个关于代码质量的不同问题？ 这就是为什么没有 50,000 个关于“代码质量”的问题。
除此之外，任何声称会议发言人不想谈论单元测试或代码质量的人显然需要参加更多的会议。
我也看过足够多关于持续集成的文章。
哦，真的吗？ 即使你的老板说“我不会因为你在单元测试上浪费时间而付钱给你”？
即使您正在使用一些没有单元测试框架的嵌入式平台？
即使您的工作期限很紧，试图实现一些短期目标，甚至以牺牲长期代码质量为代价？
不。编写单元测试并不“总是可能”。 它有很多常见的障碍。 这并不是说我们不应该尝试编写更多更好的测试。 只是有时候，我们没有机会。
就我个人而言，我厌倦了“代码质量”讨论，因为它们往往过于
我当然对编写高质量的代码感兴趣。 我只是对那些通常谈论代码质量的人感到厌烦。
One obvious answer for the Stack Overflow part is that it isn't a forum. It is a database of questions and answers, which means that duplicate questions are attempted avoided.
How many different questions about code quality can you think of? That is why there aren't 50,000 questions about "code quality".
Apart from that, anyone claiming that conference speakers don't want to talk about unit testing or code quality clearly needs to go to more conferences.
I've also seen more than enough articles about continuous integration.
Oh really? Even if your boss says "I won't pay you for wasting time on unit tests"?
Even if you're working on some embedded platform with no unit testing frameworks?
Even if you're working under a tight deadline, trying to hit some short-term goal, even at the cost of long-term code quality?
No. It is not "always possible" to write unit tests. There are many many common obstacles to it. That's not to say we shouldn't try to write more and better tests. Just that sometimes, we don't get the opportunity.
Personally, I get tired of "code quality" discussions because they tend to
I'm certainly interested in writing high quality code. I just tend to be turned off by the people who usually talk about code quality.
代码审查并不是一门精确的科学。 使用的指标在某种程度上是有争议的。 该页面上的某处：“你无法控制无法测量的东西”
假设您有一个包含 5000 行和 35 个参数的庞大函数。 您可以根据需要对它进行单元测试，它可能会完全执行其应该执行的操作。 无论输入是什么。 所以基于单元测试，这个功能是“完美”的。 除了正确性之外，还有大量您可能想要衡量的其他质量属性。 性能、可扩展性、可维护性、可用性等。 您是否想过为什么软件维护是一场噩梦？
真正的软件项目质量控制远远不止简单地检查代码是否正确。 如果您检查软件开发的 V 模型，您将请注意，编码只是整个方程式的一小部分。
软件质量控制可占项目总成本的 60%。 这是巨大的。 相反，人们更愿意削减到 0%，然后回家后认为自己做出了正确的选择。 我认为很少有时间花在软件质量上的真正原因是因为软件质量没有得到很好的理解。
许多程序员血汗工厂没有意识到“现在更少的错误”和“以后更多的利润”之间的关系。 相反，他们看到的只是“现在浪费了时间”和“现在利润减少了”。 即使显示漂亮的图形也能证明相反的情况。
此外，软件质量控制和软件工程作为一个整体是一门相对较新的学科。 到目前为止，很多编程空间都被网络牛仔占据了。 您听过多少次“任何人”都可以编程？ 任何人都可以编写代码，这是肯定的，但并不是每个人都可以成为程序员。
编辑*
我遇到了 这篇论文 ( PDF) 出自“你无法控制无法测量的事物”之人之口。 基本上，他是说控制一切并不像他最初想象的那么理想。 这并不是一个精确的烹饪方法，你可以盲目地应用于所有项目，就像软件工程学校想让你思考的那样。 他只是添加了另一个参数来控制，即“我想控制这个项目吗？需要它吗？”
Code review is not an exact science. Metrics used are somehow debatable. Somewhere on that page : "You can't control what you can't measure"
Suppose that you have one huge function of 5000 lines with 35 parameters. You can unit test it how much you want, it might do exactly what it is supposed to do. Whatever the inputs are. So based on unit testing, this function is "perfect". Besides correctness, there are tons of others quality attributes you might want to measure. Performance, scalability, maintainability, usability and such. Did you ever wondered why software maintenance is such a nightmare?
Real software projects quality control goes far beyond simply checking if the code is correct. If you check the V-Model of software development, you'll notice that coding is only a small part of the whole equation.
Software quality control can go to as far as 60% of the whole cost of your project. This is huge. Instead, people prefer to cut to 0% and go home thinking they made the right choice. I think the real reason why so little time is dedicated to software quality is because software quality isn't well understood.
Lots of coder sweatshops do not realise the relation between "less bugs now" and "more profit later". Instead, all they see is "time wasted now" and "less profit now". Even when shown pretty graphics demonstrating the opposite.
Moreover, software quality control and software engineering as a whole is a relatively new discipline. A lot of the programming space so far has been taken by cyber cowboys. How many times have you heard that "anyone" can program? Anyone can write code that's for sure, but it's not everyone who can be a programmer.
EDIT *
I've come across this paper (PDF) which is from the guy who said "You can't control what you can't measure". Basically he's saying that controlling everything is not as desirable as he first thought it would be. It is not an exact cooking recipe that you can blindly apply to all projects like the software engineering schools want to make you think. He just adds another parameter to control which is "Do I want to control this project? Will it be needed?"
无知的“只要做对”的态度。
质量管理”变成“现在”
实施起来成本太高
如此大的代码质量管理
我
不同意它很乏味。一个可靠的单元测试设计使创建测试变得轻而易举，并使测试运行起来更加有趣。
就像任何事情一样，如果你做太多，但花 10 或 20 分钟为它编写一些随机测试，它会变得无聊 。经过几个小时的编码后的一些复杂功能不会剥夺您的创造力。
Ignorant "Just do it right" attitude.
quality management" turns into "Now
it would be too costly to implement
code quality management on this large
project"
I disagree that it's dull though. A solid unit testing design makes creating tests a breeze and running them even more fun.
Like anything it can get boring if you do too much of it but spending 10 or 20 minutes writing some random tests for some complex functions after several hours of coding isn't going to suck the creative life from you.
因为我们的职业不专业。
然而，有人确实关心代码质量。 例如，您可以从软件工艺运动的讨论组。 但不幸的是，软件行业的大多数人并不了解代码质量的价值，或者甚至不知道什么是好的代码。
Because our profession is unprofessional.
However, there are people who do care about code quality. You can find such-minded people for example from the Software Craftsmanship movement's discussion group. But unfortunately the majority of people in software business do not understand the value of code quality, or do not even know what makes up good code.
我想答案与“为什么代码质量不受欢迎？”这个问题是一样的。
我认为最主要的原因是：
I guess the answer is the same as to the question 'Why is code quality not popular?'
I believe the top reasons are:
简短的回答：除非出现问题，否则它是一种只有其他人（主要是经验丰富的开发人员和工程师）才会欣赏的无形资产之一。 此时，经理和客户一片哗然，并要求正式流程为何没有到位。
更长的答案：这种短视的方法不仅限于软件开发。 美国汽车工业（或剩下的工业）可能是最好的例子。
当项目一开始是一次性的或一次性的时，也很难证明正式的工程流程的合理性。 当然，在项目完成很久之后，随着不同的业务部门开始依赖它来实现自己的业务流程，它就会有自己的生命力（并变得突出）。
此时需要设计新的解决方案； 但如果没有使用这些工具的实践和良好实践，这些工具就毫无用处。 它们成为耗时的障碍。 我在 IT 团队为业务提供支持的公司中经常看到这种情况，而开发往往是被动的而不是主动的。
编辑：当然，这些坏习惯和许多其他习惯是像 Thought Works 这样的咨询公司能够继续蓬勃发展的真正原因。
Short answer: It's one of those intangibles only appreciated by other, mainly experienced, developers and engineers unless something goes wrong. At which point managers and customers are in an uproar and demand why formal processes weren't in place.
Longer answer: This short-sighted approach isn't limited to software development. The American automotive industry (or what's left of it) is probably the best example of this.
It's also harder to justify formal engineering processes when projects start their life as one-off or throw-away. Of course, long after the project is done, it takes a life of its own (and becomes prominent) as different business units start depending on it for their own business process.
At which point a new solution needs to be engineered; but without practice in using these tools and good-practices, these tools are less than useless. They become a time-consuming hindrance. I see this situation all too often in companies where IT teams are support to the business, where development is often reactionary rather than proactive.
Edit: Of course, these bad habits and many others are the real reason consulting firms like Thought Works can continue to thrive as well as they do.
我还没有看到提及的一个重要因素是，任何流程改进（单元测试、持续集成、代码审查等）都需要在组织内有一位致力于技术的倡导者，在组织内具有适当的影响力，并愿意努力让他人相信其价值。
例如，我见过一个工程组织真正认真地对待代码审查。 该公司有一位软件副总裁，他是一位真正的信徒，他会参与代码审查，以确保代码正确完成。 顺便说一句，他们的生产力和质量是我合作过的所有团队中最好的。
另一个例子是我在另一家公司实施单元测试解决方案时。 起初，尽管管理层坚持，但没有人使用它。 但我们中的一些人确实努力谈论单元测试，并为任何想要开始单元测试的人提供尽可能多的帮助。 最终，一些最受尊敬的开发人员在开始看到单元测试的优势后签约了。 之后，我们的测试覆盖率显着提高。
我只是想到了另一个因素 - 有些工具需要花费大量时间才能开始使用，而且启动时间可能很难获得。 静态分析工具在这种情况下可能会很糟糕 - 您运行该工具，它会报告 2,000 个“问题”，其中大多数都是无害的。 一旦正确配置了工具，误报问题就会大大减少，但必须有人花时间，并致力于随着时间的推移维护工具配置。
One big factor that I didn't see mentioned yet is that any process improvement (unit testing, continuos integration, code reviews, whatever) needs to have an advocate within the organization who is committed to the technology, has the appropriate clout within the organization, and is willing to do the work to convince others of the value.
For example, I've seen exactly one engineering organization where code review was taken truly seriously. That company had a VP of Software who was a true believer, and he'd sit in on code reviews to make sure they were getting done properly. They incidentally had the best productivity and quality of any team I've worked with.
Another example is when I implemented a unit-testing solution at another company. At first, nobody used it, despite management insistence. But several of us made a real effort to talk up unit testing, and to provide as much help as possible for anyone who wanted to start unit testing. Eventually, a couple of the most well-respected developers signed on, once they started to see the advantages of unit testing. After that, our testing coverage improved dramatically.
I just thought of another factor - some tools take a significant amount of time to get started with, and that startup time can be hard to come by. Static analysis tools can be terrible this way - you run the tool, and it reports 2,000 "problems", most of which are innocuous. Once you get the tool configured properly, the false-positive problem get substantially reduced, but someone has to take that time, and be committed to maintaining the tool configuration over time.
虽然我相信大多数或许多开发人员都听说过 JUnit/nUnit/其他测试框架，但很少有人知道如何使用这样的框架编写测试。 从这些中，很少有人能够很好地理解如何使测试成为解决方案的一部分。
我了解单元测试和单元测试框架至少有 7 年了。 我五六年前在一个小项目中尝试过使用它，但直到最近几年我才学会如何正确使用它。 （即找到一种适合我和我的团队的方法......）
对我来说，其中一些事情是：
所以直到找到正确的方法； 是的，这很乏味，没有回报，很难做，耗时，等等。
编辑：
在这篇博文中，我深入探讨了一些这里给出了反对单元测试的原因。
While I believe most or many developers have heard of JUnit/nUnit/other testing frameworks, fewer know how to write a test using such a framework. And from those, very few have a good understanding of how to make testing a part of the solution.
I've known about unit testing and unit test frameworks for at least 7 years. I tried using it in a small project 5-6 years ago, but it is only in the last few years that I've learned how to do it right. (ie. found a way that works for me and my team...)
For me some of those things were:
So until finding the right way; yeah, it's dull, non rewarding, hard to do, time consuming, etc.
EDIT:
In this blogpost I go in depth on some of the reasons given here against unit testing.
代码质量不受欢迎？ 让我对这个事实提出异议。
Agile 2009 等会议有大量关于持续集成以及测试技术和工具的演示。 Devoxx 和 Jazoon 等技术会议也涉及这些主题。
甚至还有一个专门讨论持续集成和持续集成的会议。 测试（CITCON，每年在 3 大洲举行 3 次）。
事实上，我个人的感觉是，这些谈话是如此普遍，以至于对我来说它们已经处于完全无聊的边缘。
根据我作为顾问的经验，咨询代码质量技术和 工具实际上很容易出售（尽管报酬不是很高）。
也就是说，虽然我认为代码质量是一个流行的讨论主题，但我宁愿同意这样一个事实：开发人员（通常）没有做良好或足够的测试。 对于这个事实，我确实有一个相当简单的解释。
本质上，归根结底是这些技术仍然相当新（TDD 已有 15 年历史，CI 小于 10），并且它们必须与 1) 经理、2) 开发人员竞争，而这些技术“到目前为止已经运作良好” （不管什么意思）。
用 Geoffrey Moore 的话说，现代代码质量技术仍处于采用曲线的早期阶段。 整个行业采用它们还需要时间。
不过，好消息是，我现在遇到了刚从大学毕业的开发人员，他们接受过 TDD 教学，并且对此真正感兴趣。 这是最近的进展。 一旦足够多的产品进入市场，该行业将别无选择，只能做出改变。
Code Quality is unpopular? Let me dispute that fact.
Conferences such as Agile 2009 have a plethora of presentations on Continuous Integration, and testing techniques and tools. Technical conference such as Devoxx and Jazoon also have their fair share of those subjects.
There is even a whole conference dedicated to Continuous Integration & Testing (CITCON, which takes place 3 times a year on 3 continents).
In fact, my personal feeling is that those talks are so common, that they are on the verge of being totally boring to me.
And in my experience as a consultant, consulting on code quality techniques & tools is actually quite easy to sell (though not very highly paid).
That said, though I think that Code Quality is a popular subject to discuss, I would rather agree with the fact that developers do not (in general) do good, or enough, tests. I do have a reasonably simple explanation to that fact.
Essentially, it boils down to the fact that those techniques are still reasonably new (TDD is 15 years old, CI less than 10) and they have to compete with 1) managers, 2) developers whose ways "have worked well enough so far" (whatever that means).
In the words of Geoffrey Moore, modern Code Quality techniques are still early in the adoption curve. It will take time until the entire industry adopts them.
The good news, however, is that I now meet developers fresh from university that have been taught TDD and are truly interested in it. That is a recent development. Once enough of those have arrived on the market, the industry will have no choice but to change.
当您考虑到工程格言“好、快、便宜：选两个”时，这非常简单。 根据我的经验，98% 的情况下，它又快又便宜，而其他人必然会受苦。
It's pretty simple when you consider the engineering adage "Good, Fast, Cheap: pick two". In my experience 98% of the time, it's Fast and Cheap, and by necessity the other must suffer.
这是疼痛的基本心理学。 当你赶在最后期限前完成任务时，代码质量占据最后一席之地。 我们讨厌它，因为它枯燥乏味。
It's the basic psychology of pain. When you'ew running to meet a deadline code quality takes the last seat. We hate it because it's dull and boring.
这让我想起了这个 Monty Python 短剧：
“令人兴奋？不，不是。很乏味。乏味沉闷。天哪，太沉闷了，太沉闷了，太无聊了。”
It reminds me of this Monty Python skit:
"Exciting? No it's not. It's dull. Dull. Dull. My God it's dull, it's so desperately dull and tedious and stuffy and boring and des-per-ate-ly DULL. "
我想说有很多原因。
首先，如果应用程序/项目很小或者没有大规模地携带真正重要的数据，那么编写测试所需的时间最好用于编写实际的应用程序。
存在一个阈值，质量要求达到需要进行单元测试的水平。
还有许多方法不易测试的问题。 他们可能依赖于数据库或类似数据中的数据，这给设置模型数据以提供给方法带来了麻烦。 即使您设置了模型数据 - 您能否确定数据库的行为方式相同？
单元测试在发现尚未考虑的问题方面也很弱。 也就是说，单元测试不擅长模拟意外情况。 如果您还没有考虑过停电时可能会发生什么情况，如果网络链路发送了 CRC 仍然正确的坏数据。 为此编写测试是徒劳的。
我完全赞成代码检查，因为它们让程序员可以分享其他程序员的经验和代码风格。
I'd say for many reasons.
First of all, if the application/project is small or carries no really important data at a large scale the time needed to write the tests is better used to write the actual application.
There is a threshold where the quality requirements are of such a level that unit testing is required.
There is also the problem of many methods not being easily testable. They may rely on data in a database or similar, which creates the headache of setting up mockup data to be fed to the methods. Even if you set up mockup data - can you be certain the database would behave the same way?
Unit testing is also weak at finding problems that haven't been considered. That is, unit testing is bad at simulating the unexpected. If you haven't considered what could happen in a power outage, if the network link sends bad data that is still CRC correct. Writing tests for this is futile.
I am all in favour of code inspections as they let programmers share experience and code style from other programmers.
“不写测试有一些常见的借口，但它们只是借口。”
他们是吗？ 让八名程序员坐在一个房间里，问他们一个关于如何最好地维护代码质量的问题，你将得到九种不同的答案，具体取决于他们的年龄、教育程度和偏好。 20 世纪 70 年代的计算机科学家可能会嘲笑单元测试的概念； 我不确定他们这样做是不是错了。
"There are the common excuses for not writing tests, but they are only excuses."
Are they? Get eight programmers in a room together, ask them a question about how best to maintain code quality, and you're going to get nine different answers, depending on their age, education and preferences. 1970s era Computer Scientists would've laughed at the notion of unit testing; I'm not sure they would've been wrong to.
管理层需要相信现在花更多时间来节省未来时间的价值。 由于他们无法实际衡量“未修复的错误”，因此他们通常更关心能否满足当前的截止日期和时间。 发货日期高于项目的长期质量。
Management needs to be sold on the value of spending more time now to save time down the road. Since they can't actually measure "bugs not fixed", they're often more concerned about meeting their immediate deadlines & ship date than the longterm quality off the project.
代码质量是主观的。 主观的话题总是乏味的。
由于目标只是做出可行的东西，因此代码质量始终排在第二位。 它增加了时间和成本。 （我并不是说这不应该被认为是一件好事。）
99% 的情况下，代码质量差不会给第三方带来后果（除非您正在制作航天飞机或火车切换软件）。
阅读弗雷德·布鲁克斯的《人月神话》。 没有灵丹妙药。
Code quality is subjective. Subjective topics are always tedious.
Since the goal is simply to make something that works, code quality always comes in second. It adds time and cost. (I'm not saying that it should not be considered a good thing though.)
99% of the time, there are no third party consquences for poor code quality (unless you're making spaceshuttle or train switching software).
Read Fred Brooks' The Mythical Man Month. There is no silver bullet.
单元测试需要额外的工作。 如果程序员发现他的产品“有效”（例如，没有单元测试），为什么还要这样做呢？ 尤其是当它不像实现程序中的下一个功能等那么有趣时。大多数人在谈到它时往往会变得懒惰，这并不是一件好事......
Unit Testing takes extra work. If a programmer sees that his product "works" (eg, no unit testing), why do any at all? Especially when it is not nearly as interesting as implementing the next feature in the program, etc. Most people just tend to be lazy when it comes down to it, which isn't quite a good thing...
代码质量是特定于上下文的，无论人们付出多少努力，都很难一概而论。
这类似于理论与应用之间的差异。
Code quality is context specific and hard to generalize no matter how much effort people try to make it so.
It's similar to the difference between theory and application.
我也没有见过定期编写的单元测试。 原因是在项目开始时代码发生了太大的变化，因此每个人都放弃了编写单元测试，直到一切都稳定下来。 之后每个人都很高兴并且不需要单元测试。 因此，我们有一些测试保留在那里作为历史，但它们没有被使用，并且可能与当前代码不兼容。
我个人认为为大型项目编写单元测试是不可行的，尽管我承认我没有尝试过也没有与尝试过的人交谈过。 业务逻辑中有如此多的规则，如果您只是在某个地方稍微更改一些内容，您将无法知道要更新哪些测试，而不是那些会崩溃的测试。 谁知道呢，旧的测试现在可能无法涵盖所有可能性，并且需要时间来回忆五年前编写的内容。
另一个原因是时间不够。 当你分配了一个任务，上面写着“完成时间：O,5 人/天”时，你只有时间去实现它并进行浅层测试，而不是考虑所有可能的情况以及与其他项目部分的关系并编写所有的内容。必要的测试。 实施某些内容可能确实需要 0.5 天，而编写测试则需要几周时间。 除非您被特别命令创建测试，否则没有人会理解巨大的时间损失，这将导致大喊大叫/差评。 不，对于我们复杂的企业应用程序，我无法在五分钟内想出一个很好的任务测试覆盖率。 这需要时间，并且可能需要对大多数应用程序模块有非常深入的了解。
因此，在我看来，原因是时间损失，没有产生任何有用的功能，以及维护/更新旧测试以反映新业务规则的噩梦。 即使有人愿意，也只有经验丰富的同事才能编写这些测试——至少需要深入参与该项目一年，但实际上需要两到三年。 因此，新同事无法管理适当的测试。 创建糟糕的测试是没有意义的。
I also have not seen unit tests written on a regular basis. The reason for that was given as the code being too extensively changed at the beginning of the project so everyone dropped writing unit tests until everything got stabilized. After that everyone was happy and not in need of unit tests. So we have a few tests stay there as a history but they are not used and are probably not compatible with the current code.
I personally see writing unit tests for big projects as not feasible, although I admit I have not tried it nor talked to people who did. There are so many rules in business logic that if you just change something somewhere a little bit you have no way of knowing which tests to update beyond those that will crash. Who knows, the old tests may now not cover all possibilities and it takes time to recollect what was written five years ago.
The other reason being the lack of time. When you have a task assigned where it says "Completion time: O,5 man/days", you only have time to implement it and shallow test it, not to think of all possible cases and relations to other project parts and write all the necessary tests. It may really take 0,5 days to implement something and a couple of weeks to write the tests. Unless you were specifically given an order to create the tests, nobody will understand that tremendous loss of time, which will result in yelling/bad reviews. And no, for our complex enterprise application I cannot think of a good test coverage for a task in five minutes. It will take time and probably a very deep knowledge of most application modules.
So, the reasons as I see them is time loss which yields no useful features and the nightmare to maintain/update old tests to reflect new business rules. Even if one wanted to, only experienced colleagues could write those tests - at least one year deep involvement in the project, but two-three is really needed. So new colleagues do not manage proper tests. And there is no point in creating bad tests.
在 x 年前别人编写的神秘代码丛林中，在一天多的时间里捕捉一些极其重要的随机“功能”是“乏味的”，没有任何线索出了什么问题，为什么会出错，并且完全不知道如何解决它当它应该在几个小时内结束时。 当它完成后，没有人会因为巨大的延迟而感到满意。
去过那里-看到了。
It's 'dull' to catch some random 'feature' with extreme importance for more than a day in mysterious code jungle wrote by someone else x years ago without any clue what's going wrong, why it's going wrong and with absolutely no ideas what could fix it when it was supposed to end in a few hours. And when it's done, no one is satisfied cause of huge delay.
Been there - seen that.
现代代码质量写作中强调的许多概念都忽略了代码质量的主要指标：代码必须首先具有功能性。 其他一切都只是达到这一目的的手段。
有些人觉得他们没有时间学习软件工程的最新时尚，并且他们已经可以编写高质量的代码。 我无法评判它们，但在我看来，如果人们无法阅读、理解和更改你的代码，那么它很难长期使用。
A lot of the concepts that are emphasized in modern writing on code quality overlook the primary metric for code quality: code has to be functional first and foremost. Everything else is just a means to that end.
Some people don't feel like they have time to learn the latest fad in software engineering, and that they can write high-quality code already. I'm not in a place to judge them, but in my opinion it's very difficult for your code to be used over long periods of time if people can't read, understand and change it.
缺乏“代码质量”不会让用户、推销员、架构师或代码开发人员付出代价； 它会减慢下一次迭代的速度，但我能想到几个成功的产品，它们似乎是用头发和泥土制成的。
我发现单元测试可以提高我的工作效率，但我见过很多格式错误、不可读、设计不良的代码，但它们通过了所有测试（通常是已经修补了很多次的老代码）。 通过测试，您将获得一辆适合上路的斯柯达，而不是Bristol 的精湛工艺。 但是，如果您的代码质量较低，但通过了测试并始终满足用户的要求，那么这就是一个有效的商业模式。
我不知道。 部分地，软件的整个教育过程不是测试驱动的，而且可能应该是——而不是要求学生上交练习，而是给学生进行单元测试。 在数学题中进行检查是很正常的，为什么在软件工程中不可以呢？
另一件事是单元测试需要单元。 一些开发人员发现模块化和封装很难做好。 优秀的技术领导者将创建一个模块化架构，该架构将单元的范围本地化，从而使单独测试变得容易； 许多系统没有优秀的架构师来促进可测试性，或者没有定期进行重构以减少单元间的耦合。
由于固有的耦合，测试分布式或 GUI 驱动的应用程序也很困难。 我只在一个团队中做得很好，并且拥有与开发部门一样大的测试部门。
我见过的每一套尚未自动化的编码约定在逻辑上都是不一致的，有时甚至达到了无法使用的程度——即使是那些声称已在多个项目中“成功”使用的约定。 非自动编码标准似乎是政治文件而不是技术文件。
我从来没有在一家容忍编译器警告的商店工作过。
Lack of 'code quality' doesn't cost the user, the salesman, the architect nor the developer of the code; it slows down the next iteration, but I can think of several successful products which seem to be made out of hair and mud.
I find unit testing to make me more productive, but I've seen lots of badly formatted, unreadable poorly designed code which passed all its tests ( generally long-in-the-tooth code which had been patched many times ). By passing tests you get a road-worthy Skoda, not the craftsmanship of a Bristol. But if you have 'low code quality' and pass your tests and consistently fulfill the user's requirements, then that's a valid business model.
I'm not sure. Partly, the whole education process in software isn't test driven, and probably should be - instead of asking for an exercise to be handed in, give the unit tests to the students. It's normal in maths questions to run a check, why not in software engineering?
The other thing is that unit testing requires units. Some developers find modularisation and encapsulation difficult to do well. A good technical lead will create a modular architecture which localizes the scope of a unit, so making it easy to test in isolation; many systems don't have good architects who facilitate testability, or aren't refactored regularly enough to reduce inter-unit coupling.
It's also hard to test distributed or GUI driven applications, due to inherent coupling. I've only been in one team that did that well, and that had as large a test department as a development department.
Every set of coding conventions I've seen which hasn't been automated has been logically inconsistent, sometimes to the point of being unusable - even ones claimed to have been used 'successfully' in several projects. Non-automatic coding standards seem to be political rather than technical documents.
I've never worked in a shop where compiler warnings were tolerated.
我经常遇到的一种态度（但从未来自已经对质量上瘾的程序员）是，编写单元测试只会迫使您编写更多代码，而不会为此付出任何额外的功能。 他们认为最好把时间花在为产品添加功能上，而不是仅仅创建“元代码”。
随着单元测试发现越来越多的错误，您意识到这些错误在生产环境中会很严重且难以定位，这种态度通常会消失。
One attitude that I have met rather often (but never from programmers that were already quality-addicts) is that writing unit tests just forces you to write more code without getting any extra functionality for the effort. And they think that that time would be better spent adding functionality to the product instead of just creating "meta code".
That attitude usually wears off as unit tests catch more and more bugs that you realize would be serious and hard to locate in a production environment.
当程序员忘记或天真，并且表现得好像他们的代码不会被其他人在以后（或他们自己几个月/几年后）看到时，就会出现很多这样的情况。
而且，注释并不像实际编写一段漂亮的代码那么“酷”。
A lot of it arises when programmers forget, or are naive, and act like their code won't be viewed by somebody else at a later date (or themselves months/years down the line).
Also, commenting isn't near as "cool" as actually writing a slick piece of code.
许多人提到的另一件事是，大多数开发工程师都是糟糕的测试人员。 他们没有有效测试自己代码的专业知识或心态。 这意味着单元测试对他们来说似乎不是很有价值——因为他们所有的代码总是通过单元测试，为什么还要编写它们呢？
教育和指导可以帮助实现这一点，测试驱动开发也可以。 如果您首先编写测试，那么您至少主要考虑的是测试，而不是试图完成测试，这样您就可以提交代码......
Another thing that several people have touched on is that most development engineers are terrible testers. They don't have the expertise or mind-set to effectively test their own code. This means that unit testing doesn't seem very valuable to them - since all of their code always passes unit tests, why bother writing them?
Education and mentoring can help with that, as can test-driven development. If you write the tests first, you're at least thinking primarily about testing, rather than trying to get the tests done, so you can commit the code...
你被更便宜的刚毕业的大学生或外包工人取代的可能性与你的代码的可读性成正比。
The likelyhood of you being replaced by a cheaper fresh out of college student or outsource worker is directly proportional to the readability of your code.
人们对于代码的“好”意味着什么没有共识。 很多人会落到“我跑了它”甚至“我写了它”的水平。
我们需要对什么是好的代码以及它是否重要有某种共同的认识。 对于第一部分，我写了一些想法：
http: //agileinaflash.blogspot.com/2010/02/seven-code-virtues.html
至于它是否重要，已经被讨论过很多次了。 如果您的代码要寿命很长，这一点非常重要。 如果它真的永远不会出售或不会被部署，那么它显然不会。 如果不值得做，就不值得做好。
但如果你不练习编写良好的代码，那么在重要的时候你就无法做到这一点。 我认为人们已经练习了做糟糕的工作，并且不知道其他任何事情。
People don't have a common sense of what "good" means for code. A lot of people will drop to the level of "I ran it" or even "I wrote it."
We need to have some kind of a shared sense of what good code is, and whether it matters. For the first part of that,I have written up some thoughts:
http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html
As for whether it matters, that's been covered plenty of times. It matters quite a lot if your code is to live very long. If it really won't ever sell or won't be deployed, then it clearly doesn't. If it's not worth doing, it's not worth doing well.
But if you don't practice writing virtuous code, then you can't do it when it matters. I think people have practiced doing poor work, and don't know anything else.
我认为代码质量被高估了。 我做的越多，它对我的意义就越小。 代码质量框架更喜欢过于复杂的代码。 您永远不会看到诸如“此代码太抽象，没有人会理解它。”之类的错误，但例如 PMD 说我的类中有太多方法。 所以我应该将类切割成抽象类（这是最好的方法，因为 PMD 不关心我做什么）或根据功能切割类（最糟糕的方法，因为它可能仍然有太多方法 - 已经存在）。
静态分析确实很酷，但它只是警告。 例如 FindBugs 存在转换问题，您应该使用
instaceof来让警告消失。 我这样做并不是为了让 FindBugs 高兴。我认为太复杂的代码不是当方法有 500 行代码时，而是当方法使用 500 个其他方法和许多抽象只是为了好玩时。 我认为代码质量大师应该真正致力于发现代码何时过于复杂，并且不要太关心小事情（您可以非常快速地使用正确的工具重构它们。）。
我不喜欢代码覆盖率的想法，因为它真的毫无用处并且使单元测试变得无聊。 我总是测试具有复杂功能的代码，但仅限于该代码。 我在一个代码覆盖率 100% 的地方工作，改变任何东西都是一场真正的噩梦。 因为当您更改任何内容时，您必须担心损坏的（编写不好的）单元测试，并且您永远不知道如何处理它们，很多时候我们只是将它们注释掉并添加
todo以便稍后修复它们。我认为单元测试有其地位，例如，我在网页解析器中进行了大量单元测试，因为我一直发现不同的错误或不支持的标签。 如果你还想测试数据库逻辑，测试数据库程序真的很难，DbUnit 使用起来真的很痛苦。
I think code quality is over-rated. the more I do it the less it means to me. Code quality frameworks prefer over-complicated code. You never see errors like "this code is too abstract, no one will understand it.", but for example PMD says that I have too many methods in my class. So I should cut the class into abstract class/classes (the best way since PMD doesn't care what I do) or cut the classes based on functionality (worst way since it might still have too many methods - been there).
Static Analysis is really cool, however it's just warnings. For example FindBugs has problem with casting and you should use
instaceofto make warning go away. I don't do that just to make FindBugs happy.I think too complicated code is not when method has 500 lines of code, but when method is using 500 other methods and many abstractions just for fun. I think code quality masters should really work on finding when code is too complicated and don't care so much about little things (you can refactor them with the right tools really quickly.).
I don't like idea of code coverage since it's really useless and makes unit-test boring. I always test code with complicated functionality, but only that code. I worked in a place with 100% code coverage and it was a real nightmare to change anything. Because when you change anything you had to worry about broken (poorly written) unit-tests and you never know what to do with them, many times we just comment them out and add
todoto fix them later.I think unit-testing has its place and for example I did a lot of unit-testing in my webpage parser, because all the time I found diffrent bugs or not supported tags. Testing Database programs is really hard if you want to also test database logic, DbUnit is really painful to work with.
我不知道。 您看过声纳吗？ 当然，它是 Maven 特定的，但将其指向您的构建和繁荣，以及许多指标。 这种项目将促进这些代码质量指标成为主流。
I don't know. Have you seen Sonar? Sure it is Maven specific, but point it at your build and boom, lots of metrics. That's the kind of project that will facilitate these code quality metrics going mainstream.
我认为代码质量或测试的真正问题是你必须投入大量工作，但你却一无所获。 更少的错误==更少的工作？ 不，总有事情要做。 更少的错误==更多的钱？ 不，你必须换工作才能赚更多的钱。 单元测试是英雄，你这样做只是为了自我感觉更好。
我在管理层鼓励单元测试的地方工作，但是我是唯一编写测试的人（我想做得更好，这是我这样做的唯一原因）。 我明白，对于其他人来说，编写测试只是更多的工作，而且您没有任何回报。 上网冲浪听起来比编写测试更酷。
有人可能会破坏你的测试并说他不知道如何修复或注释掉它（如果你使用maven）。
框架不适合真正的 Web 应用程序集成测试（单元测试可能会通过，但可能无法在网页上运行），因此即使您编写测试，您仍然必须手动测试它。
你可以使用像HtmlUnit这样的框架，但是使用起来真的很痛苦。 Selenium 会随着网页上的每次更改而中断。 SQL测试几乎是不可能的（你可以使用DbUnit来做到这一点，但首先你必须为其提供测试数据。5个连接的测试数据是大量的工作，并且没有简单的方法来生成它）。 我不知道你的网络框架，但我们使用的框架非常喜欢静态方法，所以你真的必须努力测试代码。
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.