Code Review
從 2011 年開始，強制要求在團隊成員之間做代碼複查。Code Review 帶來的反饋意見讓團隊成員能夠迅速提升自己的技能水平，這解決了 LinkedIn 各個團隊近年來因迅速擴張帶來的技能不足的問題。
通過建立公司範圍的 Code Review 工具，這就可以做跨團隊的 Code Review。既有利於消除 bug，提升質量，也有利於不同團隊之間經驗互通。
Code Review 的經驗作爲員工晉升的參考因素之一。
Code Review 的一個難點是，Reviewer 可能不瞭解某塊代碼修改的背景和目的。所以 LinkedIn 要求代碼簽入版本管理系統前，就對其做清晰的說明，以便複查者瞭解其目的，促進 Review 的進行。
我認爲，這個方法實在太讚了。因爲，我看到很多時候，Reviewer 都會說不了解對方代碼的背景或是代碼量比較大而無法做 Code Review，然而，他們卻沒有找到相應的方法解決這個問題。
LinkedIn 對提交代碼寫說明文檔這個思路是一個非常不錯的方法，因爲代碼提交人寫文檔的過程其實也是重新梳理的過程。我的個人經驗是，寫文檔的時候通常會發現自己把事兒幹複雜了，應該把代碼再簡化一下，於是就會回頭去改代碼。是的，寫文檔就是在寫代碼。
有些 Code Review 工具所允許給出的反饋只是代碼怎樣修改以變得更好，但長此以往會讓人覺得複查提出的意見都表示原先的代碼不夠好。爲了提高員工積極性，LinkedIn 的代碼複查工具允許提出“這段代碼很棒”之類的話語，以便讓好代碼的作者得到鼓勵。我認爲，這個方法也很贊，正面鼓勵的價值也不可小看。
爲 Code Review 的結果寫出有目的性的註釋。比如“消除重複代碼”，“增加了測試覆蓋率”，等等。長此以往也讓團隊的價值觀得以明確。
Code Review 中，不但要 Review 提交者的代碼，還要 Reivew 提交者做過的測試。除了一些單元測試，還有一些可能是手動的測試。提交者最好列出所有測試過的案例。這樣可以讓 Reviewer 可以做出更多的測試建議，從而提高質量。
對 Code Review 有明確的期望，不過分關注細枝末節，也不要炫技，而是對要 Review 的代碼有一個明確的目標。