@Lenciel

浮生三唱

我认识胡萌,是在初中。

一九九四年,他十三,我十二。

人很平常。

广中校门一开,漫出来满街的小孩儿,都和胡萌差不多。

平常的胡萌也有绰号,叫「荷尔蒙」。

但他并没有因了这绰号变得多么亢奋,还是那样,稳稳的。

我和疯子叫他胡子。

疯子也是绰号,那时候,我们总在一起。

我叫什么?不记得了。

但我喜欢他们。

很快,我们仨就好得非同一般。

跟一般的好得非同一般的男孩儿一样,我们结拜了兄弟。

我们甚至有一套见面打招呼专用的手势。

为什么觉得这样很酷?不记得了。

但我还记得整套动作,怎么握手,怎么击拳。

除开读书和装酷,我们踢球、看漫画、讨论姑娘。

我们讨论了姑娘吗?不记得了。

可能没有,胡子他太沉稳。

青春期的男孩儿大都神叨叨的,一会儿冲动,一会儿冷峻,维护起这个,看不惯那个。胡子好像总是垂绅正笏,不动声色。不但从没有什么争端因他而起,就算有事情主动找上门,无论来时多么气势汹汹横冲直撞,到了他面前,都像仪仗队进了太和殿,偃旗息鼓,被他低低缓缓地纳了。

他就连说话,也跟那殿上门枢开合一般,低低缓缓。

所以他的沉稳,确实有点不一样,很像个职业习惯。

那么小的人职业是啥?我不知道,但隐约觉得跟他父亲当过兵有关系。

高中开始,胡子去了文科班,疯子去了别的中学,大家聚得不多。

朋友间需要交流的更多是观点,而不是感情。所以和很多曾经好得非同一般的男孩儿一样,我们变得有点淡。

但我一直有他们的消息。

我知道沉稳的胡子大学去了自贡,读了一个沉稳的专业,找了一个沉稳的工作。

我想起他的时候,总想起《颐和园》里的郭晓冬。

是因为长得像?说话做事情像?我觉得这些都有点,但可能更多是我自己的希望。

那部片子,爱情浓烈明朗,有点爽;生活迂回苦涩,有点沉。我希望沉稳的胡子像男主那样,平时稳着,但也能和自己心爱的姑娘,干点疯狂的事情。

胡子马上用行动教育我,这都属于瞎担心:他居然和晓薇恋爱了。

居然应该是所有人的想法。

晓薇姓杨,是我们初中班上的一枝花。人长得很漂亮,又很聪明,成绩也棒。

和很多漂亮又聪明的姑娘不一样的是,晓薇特别简单直爽。

我们都叫她晓薇。

我觉得他们能在一起真好。

后来我就看到胡子和晓薇结婚生子,听说还进了同一个军工单位。

胡子在里面管安全和法务,日子过得稳稳当当。

那年我说,白石老人的印,很多人不知道背面是啥。胡子跑来回了我。

当时我想,他果然是个文科生。后来算算,那会儿他应该已经知道自己病了。

他得的是脑癌。

我和疯子约个两三个同学去看过他们一次,大家一起合了个影,背景好像是块匾,上面刻着李白的《将进酒》。

这种事情我总是很不擅长。

前天晚上 7 点 57 分,胡子走了,疯子告诉我,今早就火化。

迷糊中醒来,是个晴天,日头冲破云层,匆匆升起,像打响了革命第一枪,要赶着翻开新的一页。

我故意早去了一会儿,因为疫情,殡仪馆冷清得有点儿瘆人。一排排的告别室里,只有逝者,不见活人。我按着晓薇发给我的厅名室号,找到了地方,整个告别室里只有我们两个人。

他走之前几个月应该有点辛苦,我觉得那不是他,但写着名字的牌子竖在那里,只好相信。我对他说,「胡子,你终于解脱了,愿你的在天之灵接受到所有生者心中的善意和温情,并终得慰藉,一路走好」。

接下来干嘛我不知道,便走到告别室外面。

隔壁的一家,请了个唱诗班。家属捶胸顿足,悲痛万分。唱诗班穿戴整齐,歌声悠扬。

我们这边实在是有点沉默的尴尬。

我想,我的那些话虽然也是发自内心,但对于胡子,是不是不过是混在其他悼念者里的一句套话,太迟也太冠冕堂皇了。所以我又跑进去,「胡子,那我给你讲个笑话吧。你到了天上,别那么沉稳,先疯狂地笑,疯狂地闹,后面还有的是时间沉稳」。

他默默躺着,好像没同意,我只好呆呆站着。

八点整,其他人来了。因为疫情,主要是单位的代表。

晓薇也来了,我们没聊几句,仪式正式开始。致辞的人告诉我们,他是多次「先进党员」、很多次「先进工作者」、更是一个「好同志」。然后按照关系亲疏,职位大小,依次告别。

悼念是一种带着秩序的政治活动,牵挂才是众人散尽后呆坐碑前,对着虚空说些傻话的人享有的特权。

仪式结束,来了几个军装服务人员,就要把灵柩推到焚化炉那边了。

晓薇扑到身边同事身上哭喊,再也见不到他了,再也见不到了。

很多人也就哭了出来。

鲁迅说,人类的悲欢并不相通,但当你看到自己的朋友这样和命运搏斗,却仍然只能一败涂地,总会感同身受。

于是我赶紧藏起情绪,混进人群。

到了车上,我翻了会儿胡子的朋友圈。他给自己起的名字,是「浮生三唱」,是他 2013 年朋友圈发过的一段词里的:

浮生三唱,不唱离觞。一唱明镜秋霜,再唱积尘小轩窗,三唱人已老,秋将凉。

他的签名,定格在:

死亡不是真正的逝去,遗忘才是。所以,请记住我。

在研发流程中使用 RFC

Why

在各种不同阶段不同规模的技术团队里工作时,很容易遇到两个困扰。

一个是技术决策不够透明或者过分集权带来的参与感和信任度的问题:每个代码库的贡献者都应该参与到架构和高层次的技术决策中。每一行代码都是代表自己,同时也代表团队的其他人,做出的决定。因此,随着团队规模增长,技术决策的透明度如果不够高,员工的参与感和彼此间的信任度都会很快下降。

一个是技术决策的可见度不高带来的技术债务问题:由于并不知道其他人在干什么和他们是怎么干的,每个团队都可能在构建一些重复的东西,并且使用了各自不同的方法和技术栈。对于公司,技术团队构建的系统不是资产就是债务,而前面说到的这些无论从内容还是质量上,大部分都是债务。

因此,作为一个团队,需要一种更好的方式来做出和分享技术决策,这里的「更好」的标志是:

  • 让团队成员而不是技术委员会为他们所负责的系统做出决定
  • 允许领域专家在没有直接参与构建特定系统的情况下参与决策
  • 控制做出决定的系统性风险
  • 减少同步上下文的工作量
  • 在未来有一个可回溯的快照
  • 能同时处理多个项目
  • 是异步的

要同时满足这些要求,粗看起来是相当困难的。但幸运的是,软件团队都会遇到这个问题,因此已经有很多方法论。在研究了很多方法特别是开源软件中实际使用的方法之后,我觉得采用 RFC 来驱动研发流程的效果是最好的。

What

RFC 已经有了很久的历史,它的字面意思就是「请来拍砖」。可以说,互联网就是在一个个涵盖它方方面面的概念、协议、流程的 RFC 文档从编写、讨论到定稿的过程中,得以成型的。

这套方法如此有效,以至于美国政府里的很多机构都在使用它。

RFC 进入软件公司时间也不短了。不管是 Facebook、Google 这样的大公司,还是 Uber 这样的独角兽,都有类似的工具和流程

我个人觉得,对于不同规模的技术团队来说,文档应该有多么全面,文档应该面向谁,文档评审的过程应该有什么,都是不同的。但一个比较结构化的形成、记录和分发文档的方法,对各种公司都会有用:把决策写下来,把知识传播出去,并允许所有人评论,这就是 RFC 的价值所在。

把决策写下来

把决策写下来并分享给他人,是更好的思考过程,也带来更多的责任感。

团队希望提高代码质量?进行正式的 code review,把意见和反馈写下来。 团队希望减少开会浪费的时间?会议前发布讨论的议题,会议后发布会议纪要。 团队希望减少信息不同步带来的惊喜(惊吓)?把决策写成 RFC ,并与他人分享。

第三项之所以在很多团队都没有被采用,是因为工程师是讨厌浪费时间的人。和写 code review 和会议纪要比,文档通常被认为是浪费时间的,因为它很枯燥也很没有参与感。

如果每个人都同意每个任务应该如何完成,那么写下来确实有点浪费时间。问题是什么、将要进行哪些更改或者新开发、哪些棘手部分有了怎样的共同理解。团队中的某个人花几个小时写下来,如果其他团队成员在读完就只是竖起大拇指表示赞同,那他不如去写代码实现了。

但通常情况下,没这么容易。我们经常听到的是:

  • 「我们开会的时候,我不是这个意思。」
  • 「这个我漏掉了,得临时加一下。」
  • 「我们发现这里改了,会破坏系统的其他部分。」

所以,把决策写下来是非常必要的。

在组织内传播并得到反馈

写下来可以带来更好的思考和责任感,但 RFC 的真正魔力在于它在组织里面公开地传播并得到反馈。组织中的人传递的信息在很大程度上决定了组织文化的形成。可以向每个人发出自己的提议并邀请任何人发表评论,会为组织定下信任和尊重的基调。

并且,这也是在整个组织中保持一致的工程框架的关键部分:当人们看到自己造的轮子早已存在或者有了更好的解决方案时,他们就会使用。

另外,在整个过程里面,管理者还有义务为大家建设一个心理安全的环境。比如通过支持「新手」的标签,来允许大家在缺乏专业知识、背景或信心的情况下,大胆地发布自己的建议或者 RFC 。

How

我们尝试的流程是:

  1. 在构建新东西之前做好计划。这可以是面对面的白板,也可以只是用 IM 聊天,只要能搞清楚将如何完成任务。
  2. 在一个简短的书面文档中记录这个计划。简短清晰的写清楚 Why、What、How,不要走极端。
  3. 选择少量的人来 review(高级工程师、团队中将使用你要构建的特性的人)。
  4. 根据上一轮 review 修改后,把这份计划发给公司的所有工程师,请大家都来评论它。
  5. 让每个团队对比较复杂的设计都采用上面的流程,然后不断迭代。

「构建新东西」的粒度是什么,或者说,怎么判断「应该为这个事情写一个 RFC 吗」?

我觉得如果你:

  • 构建新的系统、应用、组件、库等等
  • 开始打算重构、重写现有系统
  • 做出会影响不止一个系统或其他团队成员的改变
  • 增加了一个新的依赖或者改变了现有流程
  • 希望定义客户端或系统之间的契约或接口
  • 计划在技术栈里面引入新东西
  • 不知道你是否应该写

那就写一个吧。

逐步的,公司可能会迭代出 RFC 的模板,因为大量的文档会有一些共有的内容结构比如「做这项工作的动机是什么?」或者「怎么做测试?」。

最后,这个流程对各种规模的团队应该都是适用的。 它不仅解决了可见性,减少技术债务,而且还传播知识,让工程师每天更加投入。并且,这是流程的启动成本很低,我建议任何小型或中型的技术团队去做,特别是正处于成长阶段的团队。