前言

这篇有两个主题：公司文化与code review，而讲者特别强调的是要如何将这两件事情中间做连结。所以如果你想知道要如何把公司定义的价值落第到工程文化中，蛮适合可以看看这演讲的。

演讲总结

这篇的主旨其实讨论的是公司文化而非Code review。讲者利用Code review做为范例，示范如何由下而上的在code review的过程中加入培养公司文化。

整个演讲分成两部分，第一大部分讲的是「公司文化」而第二部分讲的是「Code review与文化的交互影响」。

如何定义你的文化？

讲者首先介绍了四种价值：

1. 基本价值（Permission to play value）

   公司里最基本的行为标准，例如诚实、尊敬、可信…等等。

2. 核心价值（Core values）

   这是当公司利益冲突时决定要取何者重要标准，所以不能是太general就像permission to play一样。

3. 志向价值（Aspirational value）

   这比较像是公司期望的价值，并不是继承而来也不是自然产生的，而是刻意安置到公司里的。

4. 意外产生的价值（Accidental values）

   这代表的是公司不预期但意外产生的价值，有可能是从一群有相同背景的人带来的文化，也有可能是因为公司环境而自然产生的问题。这种类的价值必须要谨慎对待，因为这种价值有可能会将新人或新观点拒於千里之外。

上面四种价值基本上驱使公司中所有决策与策略，所以时刻确认做的事情是否与公司价值一致是很重要的。

而为了达到让团队真正的合作，我们必须要克服失能团队的五大障碍（The five dysfunctions of a team）。由下而上是：

1. 缺乏信任（Absence of Trust）
2. 害怕冲突（Fear of Conflict）
3. 缺少承诺（Lack of Commitment）
4. 规避责任（Avoidance of Accountability）
5. 忽视成果（Inattention to Results）

（图片撷取自原演讲影片连结）

细节在此不多做介绍，有兴趣的人可以直接去搜寻此书《克服团队领导的5大障碍》。

而讲者提到一个问题，新创公司都会遇到的一大问题是我们要怎麽权衡「把事情做好」与「快速完成事情」？她说小朋友才做选择，我们两个都要。所以建立好的团队在此就至关重要了。

在Code Review中体现公司文化

下半部演讲讲的是关於将公司文化应用在code review上的部份。

她先大略提及了SalesLoft的code review流程

（图片撷取自原演讲影片连结）

而做这些Code review的目的有：提高可读性，确认架构与设计的决定，在测试前就找到bug，与知识转移...等等。而code review的过程其实也是一段技术间的对话，让工程师们用code review的方式薰陶与体现公司的价值。

不过，听起来其实流程有够繁琐，这样不是无法达到「快速完成事情」的目的吗？讲者表示其实不会，因为你早期发现问题，与确认code的品质，其实对未来都是一项很大的投资。我们在确认「做对事情」之中，可以确认符合各种原则（例如SOLID、DRY、KISS...等等）或测试覆盖率等等，这些都可以帮助未来在开发时增加效率，短期可能比较缓慢但长期来看却是快速的。

而她们又如何在code review的过程中展现团队合作的精神呢？藉由code review可以达成

1. 知识转移，提高code改动的认知
2. 提昇责任感（accountability）
3. 给予codebase共同的所有权（ownership）
4. 赏识好的决策（recognition）
5. 提倡合作：包含给予冲突，或激发思考
6. 练习指导的机会：培育学习文化，也练习如何开启技术间的讨论。

接下来讲者也拿出了一些公司的例子以表达真的有在做上面这些事情而不是唬烂的，有兴趣的可以看原演讲影片。

如何做好Code review？

身为code reviewer你可以尝试做到下面几件事情

1. 思考：是否code真的能达到预期目标
2. 问问题
3. 确认改动是否符合各种模式（pattern）
4. 思考读者的阅读经验
5. 确认符合coding规范与格式
6. 却认识是否有技术债
7. 回应每条评论

尝试避免下面几件事

1. 巨大且没上下文的Pull Request
2. 过多的评论造成别人的压力
3. 把个人意见当成事实
4. 问批判或拷问的问题
5. 忽略高产出者造成的问题

总结

讲者表示我们要尝试让工程师参与建立好的工程文化，一如让工程师参与建立好的codebase一样。

个人心得

首先要来吐槽一下这个演讲结构XD，我觉得这个演讲整体内容是ok，但是因为她想讲太多东西，而每件事中间连结的逻辑性不够强，所以导致其实听众有点难抓到她的重点在哪里。例如失能团队的五大障碍我觉得在整个演讲中其实没有真的很有必要，即时整个拿掉都不影响到原演讲的主旨。而价值的种类其实也不是这麽重要，只要留下核心价值就足够贯穿全文了。

而演讲内容也有些我不太认同的地方，以下来讲讲。

速度与质量

我完全可以理解这件事情的痛苦与可能性，毕竟我也是看着新创一路从不到百人变几千人的规模。我同意团队合作是能同时达成速度与品质重要的因素。但是这讲法仅限於完全理想的状况。

1. 因为要提倡利用code review当成技术对话，其实就会花很多的时间，在时间资源稀缺不足的情况下，这很难成为priority。
2. 另外一大重点是，站在个人的角度看，「建立好公司文化」的动力不见得能大到驱使我们「把code review做好」，因为好的code review其实蛮劳心劳力的，特别是工程师又是一个不喜欢一直沟通的人种，且做好code review也不见得会有credit。
3. 其实很难证明，也很难拿捏注重「品质」所花的时间到底能为未来带来多少助益。
4. 当人力资源不足的时候，谁要来提倡这个文化？如果没有已经熟悉code review文化的人来辅助，要如何确认大家会走偏？

所以当一个公司制定的策略是两者兼顾时，我觉得其实是非常不负责任也不切实际的，因为最後其实最後苦的都是那些相信公司价值的员工，因为他们会花大量的时间与精力去达到公司所说的目的。

所谓核心价值

我其实也一直在思考公司提倡的核心价值到底能带来什麽样的意义，因为我自己个人在公司推动核心价值这部份的印象是没有很好XD。公司虽然在各处传达核心价值（厕所、会议室到处贴、年度评监也要写自己对核心价值做了哪些贡献）但对员工的感觉是教条洗脑式的宣导，并没有对我们的工作有实质的帮助。或许是公司订的核心价值太过generic，所以变成所有的事情，任何作法都可以和核心价值硬扯上关系，只是看你多会扯而已。但是这样的结果又给公司的文化带来那些贡献，我自己觉得是感受不到的。

利用Code review打开对话

虽然对於这篇演讲充满疑虑，但我觉得讲者也提到我蛮认同的点，就是Code review其实就是整个工作过程的一个缩影。Code review不只单纯只是把code写好而已，更是一个重要的沟通管道，可以透过这个过程去理解别人的个性，想法与思考过程，做事的应对方式，甚至也可以展现leadership的skill。

记得Indeed的面试有一关就是Code review的interview，我自己觉得是蛮好的，光是这个小小的过程可以看出你的细心程度，看出你的技术底子，看你在乎什麽不在乎什麽，也可以看你的coaching或mentoring的能力。

不过可惜的是我觉得自己在code review上面做的贡献并没有很多，所以自己在利用code review分析人的行为上面并没有特别的擅长，这也是我下一份工作可以着重练习的地方之一。