我目前正在从事一个大型项目，许多开发人员随着时间的推移工作，代码很糟糕。经过多次重构，我们现在到达了一个点，代码没问题。现在我在想“ok”是什么意思——可能对每个人来说都是不同的。
你认为可以指定“ok”吗？什么是重要的？NDepend 指标？测试覆盖率？注释？编码风格？文档？
我知道已经有很多关于编码风格或评论的话题（例如这里）。这个问题只是关于哪些事实是重要的。
kleolb02
问问题
1033 次
7 回答
3
我认为对于任何重要的项目，您都应该有适当的编码指南（样式、评论等）和指标，以了解它们是否被遵循。您列出的清单是一个很好的开始。
于 2008-11-18T15:44:00.773 回答
1
你把两种不同的东西混在一起了。
您谈论编码风格，但随后您提到测试覆盖率、指标等。
编码风格当然可以指定——所有需求文档都必须声明“为了代码维护和一致性，这个项目将遵循这些编码风格和标准。”
然而，一般来说，大多数项目只需要“良好的行业实践”和“整个项目的一致编码风格”，并将其实际定义和实现留给开发人员。
但是，您正在讨论的其他问题，需要重构、测试、覆盖等的错误代码（我也会抛出 LINT 和静态分析），这些都应该明确指定和要求。没有理由将它们排除在规范之外 - 它们是显示哪种类型的编码错误（或者，在风格和错误代码之间的模糊线上，哪种类型的编码模式可能产生错误代码）的硬指标在任何给定的代码中，它的性能如何，以及测试显示正确操作的程度。
例如，在大型项目中，客户将与主要开发人员坐下来检查 LINT 配置，以确保它满足他们的需求，并且没有任何轻率的错误会减慢开发速度。
所以，简而言之，是的，所有这些都可以（并且应该，恕我直言）为任何重要的项目指定。
-亚当
于 2008-11-18T15:49:55.833 回答
1
你说得对，每个人的情况都不一样。也就是说，一旦你定义了期望，保持它向前发展的最好方法就是通过频繁的代码审查。
人们，尤其是项目中的新人，总是带着自己的风格。代码审查有助于使代码雌雄同体。
于 2008-11-18T15:50:42.010 回答
0
有许多事情可以提高项目的质量，而这些事情与代码和工具无关。
需求管理。有一些流程来对您的要求进行质量控制。它们有意义吗？谁要求的？他们是提出这些要求的合适人选吗？
测试设计。根据要求而不是实现来构建测试。不要让您的编码人员进行测试！
测试一切——每次。完成每个版本的完整测试周期，没有次要版本。
以我的经验，诸如代码度量和代码标准之类的东西从来没有真正起作用。你会知道谁是无赖编码员；您不需要正式的流程来识别它们。
真正能提高质量和输出的一种技术是代码审查。您需要一些纪律和骨干才能让您的三个资源花一天时间审查 5 天的工作。但是没有什么能如此彻底地揭示潜在的问题，而且，如果人们知道下周有人会批评它，该死的人只会写出更好的代码。
于 2008-11-18T16:06:08.280 回答
0
StyleCop ... 还有，FxCop ...
一个团队绝对应该标准化他们的风格。一些个人选择的空间，但一个团队绝对应该标准化他们的风格。代码更易读、更易维护、更容易审查等等等等。
于 2008-11-18T16:25:37.710 回答
0
某种准则（样式不如内容 IMO 重要），例如最佳模式/实践，但更重要的是代码审查。
于 2008-11-18T16:32:38.977 回答
0
有很多东西可以说是 ok/good 代码的属性。
- 编译时没有错误或警告
还有一些关于这个主题的其他主题......
于 2008-11-18T15:48:21.810 回答