前言

這篇有兩個主題：公司文化與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分析人的行為上面並沒有特別的擅長，這也是我下一份工作可以著重練習的地方之一。