一个好的请求请求的3条规则

如今,似乎所有开发都发生在Github上。 有一个所谓的Github流,您可以在其中提交拉取请求,并在团队中的某人对其进行审阅后将它们合并到master分支中。

作为提交了提交请求的审查并也审查了请求的人,我有一些事情要讲述审查过程。

有两个主要部分可能会导致对审核过程的误解。 我们可能会误解问题或情感。 第一个是简单的,因此我们举一个例子开始:

该注释的含义是:命名不好,或者这不是事务,或者不应该是attr_reader?

更好,但还有很多悬而未决的问题。

目前,我们正处于成功传达问题的时刻。 这里的问题是我们从未传达过“为什么”部分。 审稿人应该猜测自己的推理,否则可能会展开无休止的辩论,直到两人要就某事做出决定为止。

我们成功添加了“为什么我们认为应该更改”部分。 我添加了“我们的意见”部分,因为所讨论的问题确实只是某人的意见,因此传达以下信息非常重要:

有很多演讲形式可以帮助简化沟通,但即使将其声明为问题也可以完成工作。 另外,最好避免询问“为什么要这么做?”这类问题。 它使受审者处于防御状态,并且可以再次引发无休止的辩论。 最好是提出您的解决方案,例如:“我们可以尝试以这种方式来做这件事”。

总结一个好的请求请求注释的3条规则:

  1. 描述性
  2. 具有“为什么”部分
  3. 有礼貌

…并使用标记。

当然,我们所有人都有有限的时间,并不总是愿意花时间在别人的问题上,而是希望在每个人都互相帮助的友好环境中工作,只有每个人都为此付出一点努力,这种情况才会发生。