与注释配对编程

Question

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

从长远来看，让一个人记录另一人的代码（反之亦然）是否可以提高代码质量？

这是一个好主意吗？

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

Answer 1

人们倾向于寻找最简单的解决方案。 如果有一个“人为”的描述，那么它可能会在读者深入研究深奥的代码之前被利用。 IOW，通常会首先考虑注释，无论程序员碰巧有多环保。

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

至于谁应该编写注释，则取决于注释的级别。 例如，在较高级别，注释应描述模块的外部行为，并且可以由更多的人来编写。 但是，在内部，注释应解释各种代码块的意图。 这样，读者可以更轻松地收集代码的习惯。 这些评论应由编码人员编写。

Answer 2

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

Answer 3

如果原始作者未编写代码，则冒着错误解释算法的风险。 在我看来，唯一比未正确编写代码更令人沮丧的是错误编写的代码。

您不妨尝试这种方法：

• 与不参与编程工作的开发人员执行代码审查。
• 在没有代码作者的实际参与的情况下执行审阅。 只是审阅者，源代码管理中的代码副本以及书面文档。
• 如果审稿人在没有外部帮助的情况下无法合理地理解代码，则该文件没有足够的文档记录，应退还给作者。
• 根据需要重复。

Answer 4

我发现当助手进行广泛范围的思考（即我们要完成的工作）并且键盘牛仔进行详细范围的思考时，它的工作效果最佳。 我认为评论与之无关。

Answer 5

我倾向于先写注释，然后再写注释，有时或并排编写。 当我最终写评论时，我的脑海中的代码变得非常清晰（感谢在写评论时表达我的想法的事实）。 我不想评论未编写的代码。 每当我回来修改代码时，请先阅读原始注释，然后考虑新注释，然后编写并并行编写代码。