程序员处理代码审查的最佳方法是什么？

我对代码审查非常陌生，但是在博士学位期间我已经编码多年了-这并不总是使您成为一名优秀的程序员！

如果审阅者更改了您的代码并逐行处理代码，如果您不同意该怎么办？有时，您做出了选择X，而审阅者将其更改为Y，您的脑海中就想到了Y，但由于不利因素而决定不这样做，但是审阅者断言那些不利因素并不重要。您应该说出您的分歧，还是只是不听对方的意见？

如果您不善于接受批评，并且审稿人是组织中的高级人员，那么这将很困难。防守太大可能是不好的。

没错，防御是无济于事的。但是然后-都没有受到批评，因此，如果您觉得这种情况正在发生，那么您真的应该表达自己的担忧，即代码审查不能帮助您在组织内编写更好的代码。

审查者有责任审查代码中是否存在真正的不合规之处和缺陷，而不能将其用作编写代码的方式。这意味着该审查将审查您的工作方式，并指出您犯了错误的地方（我们中最好的人所做的事情）或不了解框架或标准或“历史原因”的某些代码被编写为就是你在哪里。

因此，如果有多种方法可以完成某项工作，则有充分的理由将您的代码更改为另一种方法，否则其简单的非建设性搅动将无济于事。

另外，请记住，评论者也不是完美的。他们可能认为Y是实现此目标的方法，却没有意识到X会更好。您应该以X方式解释您这样做的原因。审阅者可能会同意您的意见，或者他可能会告诉您为什么Y是更好的解决方案-可能还有其他因素使您不知道他是这样做的。

简而言之，复查是一种使团队成员交流其代码更改的方法。因此，请与审稿人谈谈。

如果有帮助，请以公正的方式进行讨论，就好像您甚至不是所审查代码的作者一样。毕竟，该代码属于公司或团队，而团队则必须对其进行维护。您只是碰巧是写这本书的人，这并不是许多人认为的重要因素。

编写计算机代码是在不确定情况下做出决策的主要示例。压力总是矛盾的，您如何在给定的问题中做出决定取决于您所感知的压力以及对压力的重视程度。

因此，当审阅人不同意您的决定时，这意味着他们看到的压力/风险与您不同，或者他们认为其中一些压力比您大/小。您必须绝对谈论这些差异，因为如果不这样做，则会首先导致导致分歧的问题永久存在。

如果您的审阅者的级别更高，他们的经验可能会正确地告诉他们这种风险或这种风险在实践中不是很相关，或者他们可能知道某种错误在您的组织中已存在很长的历史，因此值得格外小心避免它。相反，如果您认为自己知道审稿人可能不了解的内容，则必须绝对表达；保持沉默等于您失职。

处理这种情况的最重要部分是要理解，对设计决策的批评实际上始终不是对某人性格的批评。（在实际情况很少见的情况下，您会很快注意到，如果您确实无法取悦他人，那么您所做的任何事情都不会产生任何影响，因此遵循最佳做法的危害在哪里？这仅仅是由于不同的人对计算机代码所涉及的许多风险和回报有不同的理解，并且鉴于现代计算机代码的复杂性，这是意料之中的。讨论差异有助于在这种情况下以及将来的情况下改进代码并改善您的合作。

其他答案已经包含非常好的信息。我想对gbjbaanb暗示的某些方面进行一些扩展（请参阅我对他的回答的评论）。

根据我的经验，我在代码审查期间观察到了各种反馈：

1. “老实说，我认为这是错误的/次优的，您应该以这种方式进行更改。” 我通常会认真对待这种反馈，并且只有在我认为有反对意见时，才会反对建议的更改。
2. “我认为您的解决方案还可以，请考虑采用这种替代方法，但是是否接受更改取决于您自己。” 我也非常重视这种反馈：尽管他们并不坚信他们的解决方案更好，但审阅者仍在建议其他方案。我有机会学习一些东西，如果我喜欢它，我会接受的。否则，如果我根据自己的喜好保留代码，则审阅者认为可以。
3. “我本来会做不同的事情，所以您必须更改它，句点。”，甚至是“哦，我已经更改了您的代码，因为...”，没有建议更改，已经提交了！给出了有关更改的一些快速解释，暗示没有太多时间来讨论细节，因为我们必须继续进行下一个任务。
4. 审阅者建议进行一些琐碎的小改动，这些改动不会改进代码，而只会使其有所不同。当被要求讨论建议的更改时，审阅者将对琐碎的细节进行冗长的讨论，直到您精疲力竭。

选项3、4可能会伪装成1和2：“按照我的建议进行操作非常重要。” 或“如果您真的想要，您可以拒绝更改。”，语气实际上是与所说的相反。如果您反对不必要的更改，则可以使用共享代码所有权来证明这种态度：“代码不属于您，它属于团队！” 如果审阅者不是很开放讨论，激怒并试图不惜一切代价寻求解决方案，您可以告诉他们审阅者的意图是否诚实。基本上他们已经决定了，任何进一步的讨论都只是浪费时间。

IMO的选项1和2是诚实的审阅者的标志，该审阅者试图提供帮助，在尊重您的工作的同时试图教您一些东西，并且愿意亲自学习一些东西。在这种情况下，当我收到审稿人的建设性反馈时，我尽量不要感到骄傲。

选项3、4表明存在一些强大的游戏：重要的是我们是按照自己的方式还是按照自己的方式进行，而不是我们试图找到一个能够同时满足双方的良好解决方案。这可能与审阅者的自我有关，也与他们无法理解任何不遵循其思维方式的代码有关。通常，他们对看起来不太熟悉的代码感到不安，并且希望将其方式强加于整个代码库。

如果情况3和4经常发生，团队合作会变得非常不愉快。在这种情况下，我会考虑离开团队。

为了解决您不同意时该怎么办的问题...

正如大多数人已经指出的那样，谈论它是我们要走的路。

如果您已经这样做，甚至可能不止一次，那么我们使用的一种有用的技术是，如果在某些方面仍然存在分歧，那就说“是的，重构一下-

我们可以为此单独买票吗？

单独的票证可让您获取代码，而不是我在某些地方众所周知的令人恐惧的“搅动且永不移动”模式。这非常适合敏捷，做“可能”的最小量并分散负载。有时yagni最终会申请。有时候，产品经理会决定，比对客户的价值，截止日期和资源而言，迫切的需求要比重构的需求更多。

通常，代码审查可能是一件好事，但从我的经验来看，它最好用作新团队的开发人员使用新的编码准则的工具或用于修复重要的错误的工具，从而降低了出错的风险。如果您认为自己比审阅者更了解，您应该问为什么他或她提出的解决方案更好，并用您对此事的见解进行论证。没有人最了解所有事情，因此代码审查应该或可能对双方都是宝贵的学习经验。

对于审阅者和编码人员而言，代码审阅都是抓住潜在问题并传递知识的机会。

作为代码审查者，责任是强调可能存在的风险，与标准实践不符，改进的地方，并且通常只是同一代码领域的另一种观点。

如果在开发时没有讨论/理解编码人员的决定，则不应导致对代码的更改。

如果审阅者正在进行更改，他们可能很难将工作委派给其他人，这对于许多聪明人来说很难。

当编码人员收到评论时，可以防止您在部署时可能遇到的问题，获得学习新知识的机会以及与评论者分享您的知识的机会。

无论资历高低，您的思维方式都可以提出一些解决方案，而这只是某些人不会想到的，因此，通过做自己认为正确的事情，可以使您获得大放异彩的机会。

只要编码人员和审阅者都承认他们可能是错误的，并且可以犯错，那么由于您共同致力于解决方案，因此审查就可以增强团队实力。

看来您尚未审查您的代码：-)

代码审查的目的是获得质量合格的代码，并知道您已获得质量合格的代码。当对一个没有经验的开发人员的代码进行审查时，可以用来教如何编写更好的代码，同时避免使该开发人员感到沮丧。

审稿人绝不更改您的代码。他们可以提出或多或少有力的建议，说明他们希望如何更改您的代码，并且可以决定是否接受您的代码。

如果审查正确/如果我审查您的代码，您可能会得到一些评论，说明我将如何编写可从中学习或忽略的代码-这些是我有意见的事情，您可以自由地提出意见。不同的意见。在我的领域中，对函数，变量等进行良好的命名被认为很重要，因此您可能会获得一些改进命名的建议。通常，您应该在这种情况下进行更改（有时通过为某个名称找到更好的名称）。有时我会发现错误。您修复它们。有时我会发现我认为是错误的东西，这是错误的。如果很难看到代码是正确的，则可以使其更明显地正确。如果我做错了，你告诉我。

如果我认为设计通常不正确，那么应该早些讨论。然后，我们应该考虑您的设计是否足够好，并考虑到更改涉及的工作量，或者我只是错了，而您的设计却更好。我们应该最终达成一致。

如果审稿人和被审稿人不同意，那么我们有问题。因为这意味着我们一个人无法团队合作，或者我们一个人无法区分好的设计或不好的设计，或两者都没有。这不一定是你的错。不幸的是，有一些开发人员是资深而笨拙的，这对于公司和您来说都是一个问题。

如果发生这种情况，请非常非常认真地思考：您是否有接受充分批评的问题？如果是这样，您需要改变态度。您是否缺乏经验，以至于看不到审稿人为什么是对的？如果是这样，那没问题。信任审稿人并学习。您确定您比审阅者更了解吗？接受评论，但向第三位值得信赖的开发人员询问他的意见。记住，您可以真正确定自己的想法并做到正确，但是您也可以确定自己的想法并确定错误。