前情提要，推荐王垠的两篇博客文章：

• 《怎样尊重一个程序员》
• 《关于Git的礼节》

由于过往不规范的工作经历，我之前是缺少对 Code Review 的理解的。最近因为同事对这个问题情绪化的表达，我开始关注到关于 Code Review 的问题。

基本礼仪：不要用 FYI

谷歌公开出来的 Code Review 规范 《The Standard of Code Review》已经非常具有指导意义，内容很全面，包括我现在实际遇到的流程问题，也完全可以依照这个规范来消化解决。当然前提是所有团队成员事先对这个规范的内容已经达成一致，而不是假设公司的员工已经知道并且开始遵循这个规范。

关于规范（TSCR）中已经提到的流程问题、礼貌问题，这里是不需要赘述的。我关注到的是其中一个小章节《Label comment severity》，也就是对 Code Review 之后的 comment 进行重要程度的区分，并且加上前缀，让 author 可以明确知道哪些留言是必须要改的，哪些是无关紧要的。

除去必须要改的 comment 不加前缀，谷歌的规范中提到有三类前缀，这些都是指站在 Reviewer 的立场，如何去写 comment，本质上这三类前缀都不影响代码的 approve 和合并：

• Nit (Nitpick): 你应该改，但是不改我也能接受。
• Optional：只是建议，你自由选择改还是不改。
• FYI (For Your Information)：这个 PR 中完全不需要因此有改动，但我觉得这是一个有意思的点，后续你可以关注下。

其中第三个前缀 FYI，每当看到 For Your Information 这个短语的时候，我总是下意识的会把这个短语翻译为中国传统社会普遍流行的一句古话： “为了你好”。

相信在中国本土长大的华人，即使没有遭受过严苛古怪的家庭教育，也都能深刻理解到 “为了你好” 的威力。

为了你好，你要好好学习
为了你好，你不能打游戏
为了你好，你要考公务员
为了你好，你要早点结婚
为了你好，你必须生孩子
……

一些情况下，父母的 “为了你好” 只是他们满足自己变态控制欲望的借口，另一些情况下，有些父母发自真心的 “为了你好”，然后由于自身有限的眼光给出了不正确的建议。

总的来说，中文语境下的 “为了你好” 绝不是什么好词，如果把这种话语带到工作中，就更匪夷所思了。虽然 For Your Information 并不能直译为 “为了你好”，但是为了避免歧义，还是建议大家不要使用这样的话术。

所以，Code Review 的基本礼仪就是，不要用 FYI。

为什么 “为了你好” 往往是错的

先说结论

因为没有人可以在实际上了解另一个人。

父母真的了解自己的孩子吗？结婚多年的夫妻，真的知道对方的心思吗？审查犯人的警察，足够了解自己在调查的罪犯了吗？心理学的专家，能猜到自己女朋友早上为什么生气吗？对于每一个人，你真的了解自己吗？

所以其实可以得到这样一个和技术无关的结论，出于礼貌，我们应该尽量避免对别人说 “为了你好”。

具体事例

最近的工作中，我提交的代码包含一个简单的事件总线（Event bus）的实现，其中事件的 Publish 和 Subcribe 都用了 RW 锁来保证 map 读写的线程安全：

func (eb *EventBus) Publish(event Event) {
	eb.mu.RLock()
	defer eb.mu.RUnlock()
	if ch, exists := eb.channels[event]; exists {
		ch <- event
	}
}

而我得到的 CR 建议是用 Sync map 改写为：

func (eb *EventBus) Publish(event Event) {
    if ch, ok := eb.channels.Load(event); ok {
        // 注：这里需要类型断言
        ch.(chan Event) <- event
    }
}

这实际上最多是一个 Nit 级别的 comment，我是不太在意的，这个事情的处理起来也非常简单。

而事实上问题在于，我听到了类似于 “为了你好” 的话，大致意思是，为了你好，你要了解清楚 RW 锁、互斥锁、Sync map 的区别，然后选择在 Event bus 场景下最正确的实现方式，并且能够条理清晰地去说服别人。

如果说我从自身技术发展的角度，是不太在乎这种问题的。这个问题本质上是我们平时面试时候说的八股文，随着最近几年面试风向的转变，也越来越多的人开始逐渐达成一致、反感八股文一类的东西了。

当然追求这一类底层问题到极致的人，肯定是有技术追求的人，这并不是什么坏事，我们应该尊重任何努力以及对技术较真的人。只是技术也分很多种方面。

我的兴趣

我算不算有技术追求的人呢？也许有时候算吧，不然也不会从 Fusionist 裸辞，放弃了比现在算上币权还要高的工资。或者说，无论是技术还是别的东西，其实我们所有人都愿意追求有趣的东西。

从过往经历来看，我关心的技术话题并且乐于出自兴趣去学习、思考的，比如：

• PoW 和 PoS 的本质区别是什么，PoW 好还是 PoS 好

  • 《为什么说 PoW 比 PoS 更加去中心化》

• 以太坊的 PoS 和 Cardano 的 PoS 有什么区别

  • 为什么说 Cardano 的 PoS 是比较纯粹的 PoS，又为什么以太坊的 PoS 更加去中心化

• PBFT 的优缺点是什么，PBFT 有哪些优化的空间

  • 《所有 BFT 共识的区块链都是中心化的》
  • 《Ethereum Casper 为什么需要 EIP-7251》
  • 《区块链中的 PBFT 不需要第二次投票》

• 不同类型的区块链是如何处理分叉的

  • 《对区块链共识机制的理解》
  • 《PoS 类型的区块链如何处理分叉》

• 区块链可能有哪些有趣的应用场景

  • 《Pebbling Game 鹅卵石游戏》
  • 《一种在区块链上生成随机数的机制》
  • 《“猜均值的2/3” dApp 游戏设计》

知道这些东西有用吗？没什么用，面试的时候几乎不会有人问，工作中更是用不到，就仅仅只是出于兴趣爱好去探索这些技术问题。这些问题的答案，从来也都不是现成的，网络上是搜索不到的，ChatGPT 也是没办法精准回答的，只有经过一段时间的学习，加上查阅论文资料，结合自己的亲身经历和理解，才可以形成技术观点，无论观点本身是对还是错。

因此可能出于某种思维上的惯性，我很少关心太过基础的编程类问题。这种事情因人而异，不能强求，自然也不能强迫别人因为 FYI 就去关心某些问题。

FYI：成为好的 writer

（刚说完不要 FYI，我这里就在 FYI）

《Rework》 这本书里有一个章节印象挺深，标题是 “Hire great writers”，书中的观点是，不是因为工作中需要发表什么文章、写什么报告，而是好的 writer 往往具备逻辑清晰表达问题的能力，可以帮助到工作。

回到技术问题上，现在各种形式的技术文章也都非常普遍，比如对锁的使用场景比较有心得的话，完全可以落实到文字上，输出成果形成一篇文章，分门别类的介绍锁的种类、最佳的使用场景，然后发表到各种平台上，获得成千上万人的关注，再然后如果对其他技术细节也有心得，内容逐渐丰富，直到写出了一本书，甚至有出版社看上，或者公开到网络上作为电子书开源……FYI……何必跟我较真呢。