将编程与注释配对

人们倾向于寻找解决问题的最简单方法。如果有一个“人类”描述可用,它很可能会在读者深入研究深奥的代码之前被使用。注意,不管程序员是多么的环保,注释通常都会被首先考虑。

应尽可能保留意见。不幸的是,它们很容易过时(因为编译器无法验证它们)。因此,它们应该保持在合理的最低限度,因为最终,代码本身是唯一真实的 评论 这是可以信任的。

至于谁应该写评论,这取决于写评论的级别。例如,在更高的层次上,注释应该描述模块的外部行为,并且可以由更多的人编写。但是,在内部,注释应该解释各种代码块的意图。这样,读者就可以更容易地领会到代码的风格。这些评论应该由编码人员编写。

我发现,当一个人编写代码,另一个人编写单元测试(并排工作以便他们能够看到对方在做什么)时,“成对编程”最有效。你也可以偶尔调换角色。

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

您可能希望尝试以下方法:

• 与不参与编程工作的开发人员一起执行代码检查。
• 在代码作者不在场的情况下进行评审。只有审阅者、源代码管理的代码副本和书面文档。
• 如果没有外部帮助,审阅者无法合理地理解代码,则该代码没有充分的文档记录,应返回给作者。
• 必要时重复。

我倾向于先写评论,然后立即编写代码,或者有时并排编写,或者有时并排编写。当我最后写下我的评论时,代码在我的头脑中变得非常清晰(比在写评论时描述我的想法更清楚)。我不想评论我没有写的代码。每当我回来修改代码时,首先阅读原始注释,然后考虑新注释,编写它们,并排编写代码。

我发现当助手进行广泛的范围思考(即我们要完成什么)并且键盘牛仔进行详细的范围思考时,它最有效。我认为评论与此无关。