你的公司會獎勵程式碼量最大的那個人嗎

本文引自我的個人部落格http://johncai.github.io/thought/2014/05/17/does-your-company-value-top-committers/

在一次部門PM會議中，一位PM提出可以在每個月的update meeting中評選一些表現不錯的員工，比如執行code review最好的、最準時上班的等等，是個很不錯的想法。大家繼續思考還有哪些獎項時，其中一位說：提交程式碼最多的人，怎麼樣？或者提交程式碼次數最多的人！

聽上去是個不錯的建議，在我們這個軟體開發部門，寫程式碼是我們最主要的工作，這個獎項無疑是對程式設計師很大的鼓勵和肯定。但我心裡立刻就反應過來，這是危險很可能錯誤的做法。為什麼呢？

一個程式設計師，如果提及程式碼次數比別人多，無非兩種可能：

1. 他比別人寫了更多的程式碼。
2. 他比別人提交程式碼更加頻繁。

應該獎勵寫更多程式碼的程式設計師嗎？

不, 我很容易地就回想起，有一次要做某功能的釋出時，發現效能不行，我看了下程式碼，大概100行，執行過程需要查詢資料庫10次左右，有些查詢很慢。然後我把它重構（嚴格說應該是重寫）到10行程式碼，查詢資料庫2次，效能不再是問題，順利釋出。

什麼是重構？什麼是重寫？當你說重構時，首先，你得有女朋友，不對，首先，你得有測試；其次，要不你改生產程式碼而不改測試程式碼，要不你改測試程式碼而不改生產程式碼。這才叫重構；否則就是重寫。

好的程式設計師通過寫更少（而不是更多）的程式碼，來完成一個功能。用程式碼完成一件事，固然很爽，但很多好的程式設計師都有這個體會：刪除大段大段的程式碼時，更爽。

因為更少的程式碼意味著更高效，更可維護，更節約別人讀程式碼的時間（別忘記你花1天寫的程式碼，會有10天以上的時間被別人讀。），更能適應業務需求的變化。因此好的程式設計師對自己寫出的大量程式碼心懷不安，而為自己更少的程式碼感到傲嬌。

更好的程式設計師不僅著力於用更少的程式碼去實現軟體功能，更著力於開發更少的軟體功能來滿足更多的業務需求。軟體的feature不是越多越好，如果開發出來的東西沒人用，沒有解決客戶的問題，或者沒有給客戶帶來便利，沒有滿足他們的需求，那麼這樣的feature是沒有用的。

軟體feature是軟體開發團隊的output，滿足了多少客戶的需求，才是outcome。outcome無非就幾種：要麼給客戶省錢了，要麼給客戶賺錢了，要麼提高了對客戶的service，讓客戶的日子更幸福了。

優秀的程式設計師以解決客戶需求為目標，首先保證開發的軟體功能是真正需要的，也就是保證做對的事情，其次用對的方式寫程式碼，儘量降低程式碼量。他不再是碼農，他心裡總是有一張影響地圖,想著他要做的是如何通過程式碼影響他人。至於什麼程式碼行數，則多麼無聊的計數。

Do the right things. ATDD是重要的手段之一。

Do the things right. TDD是重要的手段之一。

應該獎勵提交程式碼更頻繁的程式設計師嗎？

看情況。毫無疑問，應該頻繁地提交程式碼，或者，更嚴格地說，頻繁地整合你的程式碼。這意味著要做持續整合，意味著，不要打特性分支。

整合

經常看到有些程式設計師，把兩天寫的一大坨的程式碼commit。他們做不到每1到2小時就commit一次程式碼，那麼意味著

1. 他沒掌握分解任務這一必備技能。
2. 他在這兩天失去了用程式碼跟其他程式設計師交流的機會。

寫程式碼是一種創造性的活動，程式設計師用思想交流，好的程式設計師把思想反應到程式碼中（talk is cheap, show me the code），時時用程式碼與他人交流。

另外一些程式設計師提交程式碼時，不先做整合，整合至少意味著編譯通過+單元測試的通過，表示我們這次提交沒有破壞之前的任何東西。任何的一次破壞，對於其他程式設計師來說，都需要花時間去看哪裡不對了，尤其是那些用程式碼交流的程式設計師，他們經常從伺服器pull最新程式碼，他們需要伺服器上的程式碼一直都是對的，以免中斷並打擾他們的工作。

整合！

很多使用git的團隊，為每一個feature打一個feature branch出來，然後做了上面所有的實踐，直到feature完成，才merge回開發的主線上。這樣的團隊還是沒明白整合的意思。整合就是在主線上整合的意思，沒有其它意思。沒事就打個branch，那是開源、超大團隊不得已而為之的做法。

不在主線上的程式碼是不存在的。

當然，其實還是應該沒事就打個branch，但在本地打，打出來做一些實驗性的東西，打出來以便目前工作未完成時可以隨時切換到另一個工作中去，打出個新天地。隨打隨刪。git的branch就是個指標，好好利用。

所以，應該獎勵提交程式碼更頻繁的程式設計師嗎？應該，如果他在做持續整合，他幾乎從不破壞程式碼庫，他以修復失敗的CI為第一要務，他讓所有程式設計師的工作流動而不停滯，他以更少程式碼為榮。