comments - 结对编程与评论

Question

多年来，我发现绿色程序员倾向于阅读注释而不是代码来调试问题。

从长远来看，让一个人在代码编写者的批准下记录另一个人的代码（反之亦然）是否会提高代码质量？

这是一个好主意吗？

旁白：在预算方面，我正在寻找单独编程和结对编程之间的中间地带。

Answer 1

人们倾向于寻找解决问题的最简单方法。如果有可用的“人类”描述，则很可能在读者深入研究深奥代码之前使用它。IOW，通常会首先考虑评论，无论程序员碰巧有多环保。

注释应尽可能保持。不幸的是，它们很容易变得陈旧（因为它们无法被编译器验证）。因此，它们应该保持在合理的最低限度，因为最终，代码本身是唯一可以信任的真实注释。

至于谁写评论，要看评论写到什么级别了。例如，在更高级别的注释应该描述模块的外部行为，并且可以由更多的人编写。然而，在内部，注释应该解释各种代码块的意图。这样，读者更容易收集代码的习惯。这些评论应该由编码员编写。

Answer 2

我发现当一个人编写代码而另一个人编写单元测试时，“结对编程”效果最好（并排工作，这样他们就可以看到彼此在做什么）。您也可以偶尔交换角色。

Answer 3

如果原作者没有记录代码，您将面临更高的误解算法的风险。在我看来，唯一比记录不充分的代码更令人沮丧的是记录不正确的代码。

您可能希望尝试这种方法：

• 与未参与编程工作的开发人员一起执行代码审查。
• 在代码作者不在场的情况下进行审查。只是审阅者、源代码控制的代码副本和书面文档。
• 如果审阅者在没有外部帮助的情况下无法合理理解代码，则说明文档没有充分记录，应将其归还给作者。
• 根据需要重复。

Answer 4

我发现当助手进行广泛的范围思考（即我们要完成什么）并且键盘牛仔进行详细范围的思考时，它的效果最好。我不认为评论与它有任何关系。

Answer 5

我倾向于先写评论，然后立即或有时或有时并排编写代码。当我最终写下我的评论时，代码在我的脑海中变得非常清晰（感谢在写评论时表达我的想法的事实）。我不喜欢评论我没有写的代码。而且每当我回来修改代码时，首先阅读原始注释，然后想到新的注释，将它们写下来并并排编写代码。