程式碼之道

第5部分 (第3/4頁)

理者基本上總會得到他們所要求的東西。如果寫更多行的程式碼能夠讓度量結果更好，那他們得到的程式碼行會比較多。如果更少的程式碼簽入能夠讓度量結果更好，那他們看到的程式碼簽入會比較少。並不是因為程式碼變好了或者開發者變好了，而只是因為那樣做可以使度量的結果更好看。

只要人們相信他們被用數字來判斷，他們就會採取任何必要的措施去確保他們的數字很好看，而不會去管那個度量系統的初衷。畢竟，如果拋開你的方式去做正確的事，結果卻得不到你的肯定，他們又何必呢？

那是不是所有的度量都沒用呢？不是，只要度量用於跟蹤團隊和產品的進度，以便達到明確而公認的目標（比如績效、迴歸率、發現和修復率、解決客戶問題所用的天數等），那它們就很有價值。度量有助於推動團隊前進，並且賦予成就客觀的內涵。然而，它們絕對不可以代替出色的判斷。

作者注：我後來對建設性的度量有了更多的認識。你應該用它們度量令人想要的結果——在理想情況下，應該是基於團隊的結果。結果關注在“什麼”，而不是“如何”，這樣就給大家的改進留出了空間。團隊度量驅動的是共享的目標，而不是帶有競爭性的病態。“程式碼行數”不大可能是令人想要的結果，而“從開始到結束，使用更少的時間開發出高質量的功能”才是令人想要的結果，而且這個結果取決於整個團隊，而不是個人。

不要試圖只在個體開發者的生產力上給一個數字，管理者更應該回答這樣的問題，“一個優秀的開發者是由什麼組成的呢？”如果答案跟指定一個數字那麼簡單，可能很久以前我們就都被定理證明的機器取代了。

扮演一個角色

度量開發者的價值的關鍵是，多想一想開發團隊，而不是個人。不同的人給團隊帶來不同的力量。在判定各個開發者的貢獻時，要考慮到他們在團隊裡扮演的角色。最好的開發者往往不是那些程式碼寫得最好或最快的人。

你不希望整個團隊都是主管或都是程式碼工人，也不希望整個團隊都是架構師。每個團隊都需要有一個才能上的平衡，這樣才會有最好的效力和生產力。

卓越開發者的素質

不過，在“度量開發者”方面還有很多的邊緣問題。下面，我將列出我認為的、卓越開發者具備的一些明顯特徵：

？ 他們知道他們正在做什麼。當你問卓越開發者，為什麼那裡有特定的某行程式碼或某個變數，他們都能說出理由。有時候他們給的理由不那麼美妙（“那行程式碼是我從其他地方抄過來的，它使用了那個結構”），但他們的理由永遠不會是，“哈，我不知道，它看起來能夠工作。”

？ 他們不相信魔法。這是上一條的必然結果，既然他們知道自己正在做什麼。對於黑盒的應用程式程式設計介面、元件或演算法，卓越開發者會感覺不舒服。他們想要知道那些程式碼是怎樣工作的，以免被錯誤的假設或“有漏洞的”抽象傷害到（比如一個字串類，它在實現簡單的字串連線時，隱藏了記憶體分配故障或所需的O（n2）執行時間）。

作者注：賞你一個我最喜歡的“Joel　on　Software”欄目：“The　Law　of　Leaky　Abstractions”。請訪問。

譯者注：有一種衡量演算法複雜度的方法叫大O表示法，它把一個演算法的執行時間用輸入量n的函式來表示，典型如O（1）、O（log（n））、O（n）、O（n*log（n））、O（n2）等。O（n2）表示某個演算法的執行時間隨著元素個數的增加呈平方增長，顯然其效率比較差。

？ 他們瞭解客戶和業務。我在第7章“職業生涯歷險”的“生活是不公平的”欄目中詳細討論了這一點。卓越開發者知道事情的實質，他們能夠分出輕重緩急並且做出恰當的權衡。

？ 他們把客戶和團隊放在優先於自己的位置。卓越開發者不會褻瀆任何任務，他們認為沒有哪個客戶是不重要的。

？ 他們有不妥協的精神和道德規範。儘管個人喜好可能會改變，卓越開發者會一如既往地關注他們如何完成工作，以及怎樣去跟其他人互動。不管是他們選擇的演算法還是他們寫的e…mail，他們都會對自己高標準、嚴要求，始終不會動搖他們的核心價值觀。

？ 他們有傑出的人際溝通技能。儘管沒有很多的開發者能夠主持好遊戲或演出，卓越開發者能夠很好地跟別人相處，尊重別人，並且跟人進行清晰、有效、恰當的溝通。他們不選擇欺凌或脅迫（儘管