IT评估编码质量 - 我们如何知道什么是好的？

Question

来自IT背景，我参与过软件项目，但我不是程序员。我最大的挑战之一是拥有大量的IT经验，人们常常转向我来管理包含软件开发的项目。这些项目通常是外包的，没有全职架构师或PM的预算，这使我能够评估正在进行的工作。

我过去曾经设法通过这个，我（有充分的理由）对接受这些责任感到不安。

我的问题是，从技术经验而非编程的角度来看，除了确定编码是否有效之外，我如何评估编码是否写得好？是否有方法，技巧，交易技巧，旗帜，标志，任何可以说的东西 - 嘿这是垃圾还是嘿这真是太棒了？

Answer 1

好问题。应该得到一些好的回应。

1. 代码清洁度（缩进，文件组织，文件夹结构）
2. 评论很好（不只是内联评论，而是说明它们是什么的变量，说出它们做什么的函数等）。
3. 小的可理解的函数/方法（没有疯狂的300行方法，可以在整个地方使用嵌套来执行各种操作）
4. 关注SOLID principles
5. 单元测试代码的大小和质量是否与项目的代码库相似
6. 接口代码是否与业务逻辑代码分开，而业务逻辑代码又应与基础架构访问代码（电子邮件，数据库，Web服务，文件系统等）分开。
7. 性能分析工具对代码的看法（NDepend，NDoc，NCover等）

还有更多内容......但这会让你开始。

Answer 2

代码有2个主要受众群体：

• 使用它的人
• 开发它的人

所以你需要做两个简单的测试：

• 运行代码。你能做到它应该做的工作吗？
• 阅读代码。你能理解开发者的一般意图吗？

如果您对这两个问题的回答都是肯定的，那就是很棒的代码。

阅读代码时，不要担心您不是程序员。如果代码写得很好/有文档记录，那么即使是非程序员也应该能够看到很多想要实现的目标。

顺便说一句：好问题！我希望更多的非程序员关心代码质量。

Answer 3

首先，设定基本规则（所有程序员都注册），说明什么是“好”，什么不是。自动化测试你可以测量的那些（例如，功能少于多行，McCabe复杂性，你的程序员发现令人困惑的习语）。然后接受“良好的编码”是你知道的，当你看到的东西，而不是你可以用一套规则确定的东西，并允许人们偏离标准提供他们得到一个人的同意更多经验。同样，这些标准必须是生活文件，面对反馈进行调整。

代码审查也很有效，因为并非所有这些“好的风格”规则都可以自动确定。有经验的程序员可以说出他们不喜欢没有经验的程序员代码的东西 - 你必须让原作者改变它以便他们从错误中吸取教训 - 而没有经验的程序员可以说出他们发现很难理解其他人的代码 - 并且，通过被迫阅读其他人的代码，他们也将学习新的技巧。同样，这将为您提供有关您的标准的反馈。

在某些特定点上，复杂性和功能大小运行良好，可重复（单元）测试期间的代码覆盖率也是如此，但最后一点需要注意：除非您正在开展高质量标准的工作必要性（嵌入式代码，作为示例，或安全关键代码）100％代码覆盖率意味着您正在测试10％的值得测试的代码路径，以及90％几乎从未编码错误的代码路径。值得测试的是那些发现错误并提高可维护性的测试。

Answer 4

我认为您正在尝试评估通常未评估的内容。上面已经有了一些很好的答案。你已经证明自己在处理软件方面更加成熟，因为你不接受自己的个人练习，你不能认为编写软件很容易。

您认识一位您信任的开发人员吗？也许让那个人成为评估过程的一部分。

Answer 5

  

如何评估编码是否写得好

有多种方法/指标来定义'好'或'好'，例如：

• 按时交付
• 快速交付
• 交付后没有错误
• 易于安装
• 记录良好
• 快跑“
• 使用便宜的硬件
• 使用廉价软件
• 编写
费用不高
• 易于管理
• 易于使用
• 易于更改（即添加新功能）
• 易于移植到新硬件
• ...等...

其中，程序员倾向于重视“易于改变”：因为，他们的工作是改变现有软件。

Answer 6

这是一个困难的问题，可能是您的非功能性要求可以帮助您的地方

• 指定您的性能要求：每秒事务数，响应时间，一段时间内预期的DB记录，
• 要求交付包括绩效分析工具的结果
• 指定运行应用程序的计算机，您不必升级硬件来运行应用程序

为了观察代码，并确定其编写的代码是否更加强硬，来自@Andrew＆amp; @Chris几乎涵盖了它...你想要的代码看起来很好，易于维护并且性能良好。

Answer 7