我们应该用什么指标来判断代码质量？
我目前正在开发一个大型项目，许多开发人员加班加点，代码很糟糕。 经过多次重构后，我们现在已经到达了代码可以正常运行的地步。 现在我在想“ok”意味着什么——可能对每个人来说都有不同的意义。
您认为可以指定“ok”吗？ 什么是重要的？ NDepend 指标？ 测试覆盖率？ 评论？ 编码风格？ 文档？
我知道已经有很多关于编码风格或评论的主题（例如此处）。 这个问题只是关于什么事实是重要的。
I'm currently working on a large project, where many developers worked over time and the code was terrible. After many refactorings we now arrived a point, where the code is ok. Now I'm thinking what "ok" means - probably for everyone something different.
Do you think it's possible to specify "ok"? What is important? NDepend metrics? Test Coverage? Comments? Coding style? Documentation?
I know there are already many topics about coding style or commenting (for example here). This question is just about what facts are important.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我认为对于任何重要的项目，您都应该制定适当的编码指南（样式、注释等）和指标，以了解它们是否被遵循。 您列出的清单是一个很好的开始。
I think for any non-trival project you should have coding guidelines in place (style, comments, etc.) and metrics to know if they are being followed or not. The list you've outlined is a very good start.
你混淆了两种不同的东西。
你谈论编码风格，但随后你提到测试覆盖率、指标等。
编码风格当然可以指定 - 所有需求文档必须声明的是“为了代码维护和一致性的目的，该项目将遵循这些编码风格和标准”。
然而，一般来说，大多数项目只需要“良好的行业实践”和“整个项目一致的编码风格”，并将其实际定义和实现留给开发人员。
然而，您正在讨论的其他问题，需要重构、测试、覆盖率等的不良代码（我也会抛出 LINT 和静态分析），这些应该明确指定和要求。 没有理由将它们排除在规范之外 - 它们是硬指标，显示可能会出现什么类型的编码错误（或者，在风格和坏代码之间模糊不清，什么类型的编码模式可能会产生有缺陷的代码）在任何给定的代码中，它的执行情况如何，以及测试显示正确操作的情况如何。
例如，在大型项目中，客户将与首席开发人员坐下来检查 LINT 配置，以确保它满足他们的需求，并且没有任何琐碎的错误会减慢开发速度。
所以，简而言之，是的，所有这些都可以（并且应该，恕我直言）为任何重要的项目指定。
-亚当
You're mixing up two different things.
You talk about coding style, but then you mention test coverage, metrics, etc.
Coding style can certainly be specified - all the requirements document has to state is that "For purposes of code maintenance and consistency, this project will follow these coding styles and standards."
Generally, however, most projects merely require, "Good industry practices" and "a consistent coding style across the project" and leave the actual definition and implementation of that up the to developers.
However, the other issues you're discussing, bad code which required refactoring, tests, coverage, etc (I'd throw LINT and static analysis as well) these should be explicitly specified and required. There's no reason to leave them out of the specification - they are hard metrics that show what type of coding errors (or, getting on the fuzzy line between style and bad code, what type of coding patterns are likely to produce buggy code) are likely in any given code, how well it performs, and how well the tests show correct operation.
In large projects the customer will sit down with the lead developers and go over the LINT configuration, for instance, to make sure it meets their needs and no frivolous errors are slowing down development.
So, in short, yes, all this can (and should, IMHO) be specified for any project of significance.
-Adam
你说得对，每个人的好坏都是不同的。 也就是说，一旦您定义了期望，保持它向前发展的最佳方法就是通过频繁的代码审查。
人们，尤其是项目中的新人，总是带着自己的风格。 代码审查有助于使代码雌雄同体。
You're right that okay is different for everyone. That said, once you've defined the expectations, the best way to maintain it going forward is through frequent code reviews.
People, especially new people on a project, always bring their own style. Code reviews help androgynize the code.
有很多东西可以说是好的/好代码的属性。
还有一些关于这个主题的其他线程......
There are so many things that can be said to be attributes of ok/good code.
there are also a few other threads on SO about this topic...
有很多与代码和工具无关的事情可以提高项目的质量。
需求管理。
制定一些流程来将质量控制应用于您的要求。 它们有道理吗？ 谁要求的？ 他们是提出这些请求的合适人选吗？
测试设计。
根据需求而不是实现来构建测试。
不要让您的编码员进行测试！
测试一切——每次。
对每个版本进行完整的测试周期，不存在次要版本。
根据我的经验，诸如代码度量和代码标准之类的东西从来没有真正起作用。 你会知道谁是游手好闲的程序员； 您不需要正式的流程来识别它们。
真正能够提高质量和输出的一项技术是代码审查。 您需要一些纪律和勇气才能让您的三个资源每天花时间审查 5 天的工作。 但没有什么能如此彻底地揭示潜在的问题，而且，如果人们知道下周有人会批评它，他们就会写出更好的代码。
There are a number of things which will improve the quality of a project which have nothing to do with code and tools.
Requirements management.
Have some process to apply quality control to your requirments. Do they make sense? Who asked for it? Are they the right people to make these requests.
Test Design.
Build your tests according to the requirments, not the implementation.
Do not let your coders do the testing!
Test Everything -- Every Time.
Go through the complete test cycle for every release, there is no such thing as a minor release.
In my experience things like code metrics and code standards never really work. You will know who the deadbeat coders are; you dont need a formal process to identifiy them.
The one tecnique which really works to improve quality and output are code reviews. You need some disipline and backbone to have three of your resources spend a day reveiwing 5 days work. But nothing uncovers potentail problems so thouroughly, and, damit people just write better code if they know someone is going to critique it next week.
StyleCop ...还有FxCop ...
团队应该绝对标准化他们的风格。 个人选择有一定的空间，但团队应该绝对标准化他们的风格。 代码更具可读性、更易于维护、更容易审查等等。
StyleCop ... also, FxCop ...
A team should absolutely standardize their styles. Some room for personal choice, but a team should absolutely standarize their styles. Code is more readable, more maintainable, more easily reviewed, etc. etc. etc.
某种指南（在我看来，风格不如内容重要），例如最佳模式/实践，但更重要的是代码审查。
Some kind of guidelines (style is less important than content IMO), e.g. best patterns / practices, but more importantly CODE REVIEWS.