配对编程与评论

Question

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

是否有一个人在代码编写者的批准下长期提高代码质量时记录其他人的代码（反之亦然）？

这是一个好主意？

撇开：我正在寻找独立编程和结对编程之间在预算方面的中间地带。

Answer 1

人们倾向于寻找最简单的问题解决方案。如果有可用的“人类”描述，它可能会在读者深入研究深奥代码之前被利用。 IOW，无论程序员是多么绿色，这些评论通常都会首先考虑。

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

至于谁应该写评论，取决于评论的写作水平。例如，在较高层次上，评论应该描述模块的外部行为，并且可以由更多人写出。然而，在内部，评论应该解释各种代码块的意图。这样，读者就更容易收集代码的风格。这些评论应该由编码员编写。

Answer 2

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

Answer 3

如果原作者没有记录代码，则运行错误解释算法的风险较高。在我看来，唯一比没有充分记录的代码更令人沮丧的是没有正确记录的代码。

你不妨试试这个方法：

• 与没有参与编程的工作量开发商进行代码审查。
• 在没有代码作者的实际存在的情况下执行审阅。只是审阅者，来自源代码控制的代码副本和书面文档。
• 如果审阅者在没有外界帮助的情况下无法合理理解代码，则没有充分的文档记录，应该将其提供给作者。
• 根据需要重复。

Answer 4

我倾向于先写评论，之后立即写代码或者在时间或者时间上并排。当我写下我的评论时，代码变得非常清晰（比写作评论时口头表达我的想法的事实）。我不喜欢评论我没有写的代码。每当我回来修改代码时，首先阅读原始评论，然后思考新评论，编写代码并将代码并排编写。

Answer 5

当助手做广泛的范围思考（即我们试图完成什么）和键盘牛仔做细节范围思考时，我发现它最有效。我不认为评论与它有任何关系。