你的程序員是在努力工作還是在偷懶？

　　Mike Hadlow 是一位資深軟件開發者，同時也是 EasyNetQ 與 Suteki Shop 的作者，喜愛歷史與科技，是一個技術極客。近日，Mike 就程序員工作效率、工作表現以及工作成果等主題撰寫了一篇博客，談到了我們該如何看待程序員到底是在努力工作還是在偷懶這個問題。

　　如果人們從事的是體力勞動，那么我們就很容易能夠看出他們工作的努力程度。你會直觀、清楚地看到他們頻繁移動的步伐，流下的汗珠。還會看到他們 工作的成果：逐漸升起的磚墻，地上的洞變得越來越深，等等。觀察到并獎勵努力工作的人是人類的一種很基本的天性，這也是我們覺得忍耐力運動令人著迷的原因 之一。不過對于管理技術創造性的員工來說，這種對努力的體力勞動天然的欣賞之情就會出現問題。高效的知識工作者常常看起來并不是那么努力工作。

　　回到 2004 年，那時我還是一名初級開發者，工作在一個大型團隊中，主要從事有線電視公司的賬單與供應系統。就像所有的大型系統一樣，這個系統由大量相對比較獨立的組 件構成，不同的小組負責不同的組件開發工作。模擬電視與數字電視供應系統幾乎是完全分開的，由兩個不同的小組分別進行開發。

　　模擬電視團隊決定根據 Microsoft Biztalk 的一個早期版本來構建他們的系統。團隊有 4 個人以及一個來自于微軟的團隊共同開發并運行這個系統。他們看起來工作非常努力，常常工作到深夜，周末也在加班加點。當遇到生產問題時，團隊的每個人都會 放下手頭的工作，圍攏在一起，提供各種建議和意見，以及如何修復問題的見解。你會看到，這個團隊中的每個人都有很強的團隊凝聚力，而且他們工作都非常努 力。

　　數字電視供應系統則大相徑庭。系統的代碼幾乎是由一個家伙搞定的，我們暫且稱這個家伙為 Dave 吧。我是團隊的一名初級維護工程師。一開始，我在理解代碼時遇到了很多麻煩。程序中并沒有長長的過程語句，相反有大量的小體積類和方法，每個方法的代碼也 只有寥寥數行而已。我有幾個同事抱怨 Dave 將事情搞得過于復雜了。不過 Dave 卻建議我應該閱讀幾本關于面向對象編程的圖書。他教會了我設計模式、SOLID 原則以及單元測試等知識。很快，他所編寫的代碼開始變得具有現實意義了，隨著我不斷加深對代碼的理解，我也越來越發現它優雅的設計。代碼在產品中沒有出現 問題，只是一直在默默地工作。要想對代碼做出修改也是輕而易舉的事情，因此實現新的特性簡直是手到擒來。單元測試意味著進入到生產系統中的 Bug 數量變得微乎其微。

　　結果就是我們這個團隊看起來工作不那么努力。我每天下午5:30 下班，周末也從來不用工作，我們也不必圍聚在一起猜測到底是什么原因導致了生產系統的問題。從外人的角度來看，我們所從事的工作肯定要比模擬電視團隊的簡 單得多。事實上，二者的需求非常相像，只是我們開發出了設計更好的軟件、提供了更好的支持基礎設施，特別是單元測試。

　　管理團隊宣布要根據績效給予員工獎勵。輪到老板與我談話時，他說公平的做法是對那些努力工作的員工給予獎勵，工作越努力，獎勵力度越大，我們的團隊看起來對公司并不那么在意，更無法與那些放棄晚間與周末時間的英雄相提并論。

　　這家有線電視公司有一點與眾不同，你可以直接比較好的軟件設計與差的軟件設計之間的差別，還可以對團隊行為進行比較。大多數組織者都并沒有提供 這一比較。我們很難說某個員工是不是通宵達旦地工作，甚至周末時間也在工作，頻繁充當救火隊員的角色，這種做法是不是就是復雜軟件系統必須要做的呢。除非 你可以讓幾個互相競爭的團隊解決同一問題，否則你永遠也沒法直接比較他們工作上的差別。相反，對于那個坐在角落里，朝九晚五工作的家伙有可能花了很多時間 在上網呢？也許他非常善于編寫穩定、可靠的代碼，也許他的工作要比其他人的簡單。對于偶爾過來檢查的管理者來說，他們會覺得第一種人工作很努力，第二種人 則不是這樣。努力工作就很好，偷懶就很不好，真的是這樣么？

　　我的看法是表面上的努力工作常常是失敗的信號。高壓力、頻繁中斷的環境常常無法開發出好的軟件。長時間的工作也不是一種正確的做法。有時，解決 難題最好的方式可能是不再思考這個問題，出去走走，或是睡個好覺，讓你的潛意識來解決問題。我最喜歡的一本書是G. H. Hardy 所編寫的 A Mathematician’s Apology，他是 20 世紀英國的一位杰出數學家。這本書描繪了他每天的工作：上午工作 4 個小時，下午觀看板球比賽。他說對于復雜的腦力工作來說，一天工作 4 個小時以上是完全沒有意義且生產力低下的方式。

　　我想對管理者說的是，以結果為導向，根據員工工作的成果，根據可運行的軟件為導向，不要被人們表面上的努力工作所蒙蔽。另外，最好不要與你的開 發者坐在一起，你會得到更好的結果，不受傳統、直覺判斷所影響的好結果。遠程工作的好處是非常多的，你只能以輸出來衡量員工的工作情況，而不是看他們是不 是每天端坐 8 小時盯著 IDE 在看為標準，或是聚集在一起提出自己的見解為衡量的準則。

　　有讀者評論說，文章寫的很實在，有時真的很難說服同事設計的簡單性與恰當使用 OO 原則所帶來的好處。我就看到有的人以編寫復雜代碼并工作到深夜為傲。

　　還有讀者說，我曾經與一個家伙共事過，他說“第一次就將事情做對的困難之處在于沒有人認識到事情會有多么復雜”。幾年過去了，我發現這句話非常正確。我現在都會在項目開始前進行大量的提前設計。這常常會讓執行變得非常平滑，不過可能會讓其他人覺得這件事挺簡單的。

                    <span id="shareA4" class="fl">                          </span>