在软件开发领域，很多人都误以为这是一个单人工作，程序员拿着键盘就可以打出代码。然而，今天与过去不同。软件开发早已演变为多人协作的工作模式，代码审查也因此成为关键环节。但这看似简单的指出别人代码缺陷的工作，其实却暗藏玄机。如果你不小心，你可能会得罪你的同事。
在代码审查过程中，稍有不慎的沟通方式就可能导致冲突。例如，当审稿人简单粗暴地在审稿中打上一连串问号时，这在某些人看来可能很正常，但对于审稿人来说，可能会被认为是极其无礼的，甚至可能会直接去IM软件提问。而且，当评论过于直白时，比如“你写的这段代码就是一坨狗屎”，即使本意并非个人，也很容易引起对方的抵触情绪。有些忍耐力差的人可能会情绪崩溃，干脆放弃工作。他们觉得上班就像进坟墓，更改代码变得难以忍受。
起初，很多人认为代码审查只是一个循序渐进的过程，找出优化点，等待提交者完成更改或讨论，然后维持现状，最后将代码和你合并。完成了。但实际上，只要涉及到人与人之间的沟通，尤其是当一方挑剔另一方时，事情就没有那么简单了。这夹杂着人情世故，理想与现实往往相距甚远。情绪可能会干扰信息的传递，影响他人的判断。例如，不礼貌的评论可能会让被评审者不愿意更改代码，从而使评审工作难以顺利进行。
在做出判断时，要谦虚并尊重他人，无论他们的经验或背景如何。优秀的表达，即使内容是批评，也能让对方感到受到尊重。例如，当你发现一个很长的循环代码时，你评论“该代码非常冗长，建议将其更改为列表理解”。虽然观点是正确的，但是表达得不好。如果替换成“这里的循环体比较简单，只有过滤和转换逻辑，很适合改成列表理解，代码更精简”并附上参考链接，效果就是非常不同。这种方法不仅更容易说服对方，便于修改，而且在老板查看PR时也给老板留下了深刻的印象，让老板觉得你对工作很认真，可以帮助同事成长。
除了保持谦逊和尊重之外，还有一些值得采用的评审沟通技巧。发表评论时，最好举个例子，告诉对方他们到底想改变什么，而不是仅仅批评。例如，你不能只是说“你的函数名称不起作用”，而应该给出一个解决方案，例如“你的函数名称不起作用，你可以考虑将其更改为其他名称，或者你可以考虑一下你自己。”这样对方就能明确方向，避免认为你是故意找麻烦。
总之，大家都从心底里同意，代码审查是一个针对物而非人的过程，对代码的批评不应该被视为对人的批评。但提倡好好说话与此并不冲突。一次让双方都满意的沟通几乎就相当于一次更高效的沟通。改善沟通方式，提高工作效率，何乐而不为呢？欢迎大家在评论区分享你在Code Review方面的经验和见解，也不要忘记把这篇文章分享给你身边的开发伙伴，以便我们在Code Review方面为同事和老板提供帮助！
Share on Twitter Share on Facebook
Indie123
Comments
There are currently no comments