你的程式設計師是在努力工作還是在偷懶？

　　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原則所帶來的好處。我就看到有的人以編寫複雜程式碼並工作到深夜為傲。

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