請您在閱讀本文之前，先了解《高效程序員的45個習慣》-之二。
每一期都會涉及15個話題，用3期來列出這45個習慣，每次不貪多，貪精，大家如果有空，一定要細細品味這15個習慣。
注意：每一個好的習慣，開頭都會相應有一個唱反調的句子哦。
?
16 使用演示獲得頻繁反饋
“客戶不停的更改需求，導致我們嚴重地延期。他們一次就應該想清楚所有想要的東西，然后把這些需求給我們。”
需求就像是流動著的油墨。你無法凍結需求，就像你無法凍結市場、競爭、知識、進化或者成長一樣。就算你真的凍結了，也很可能是凍結了錯的東西。
不一致的術語是導致需求誤解的一個主要原因。所以，需要維護一份項目術語表。人們應該可以公開訪問它，一般是在wiki或內部網里。
項目啟動了一段時間以后，你就應該進入一種舒適的狀態，團隊和客戶建立了一種健康的富有創造性的關系。
?
17 使用短迭代，增量發布
“我們為后面的3年制定了漂亮的項目計劃，列出了所有的任務和可交付的時間表。只要我們那時候發布了產品，就可以占領市場”
給我一份詳細的長期報告，我就會給你一個注定完蛋的項目。
對于大項目，最理想的辦法就是小步前進，這也是敏捷方法的核心。大步跳躍大大地增加了風險，小步前進才可以幫助你很好地把握平衡。
?
18 固定的價格就意味著背叛承諾
“對這個項目，我們必須要有固定的報價。雖然我們還不清楚項目的具體情況，但仍要有一個報價。”
固定價格的合同會是敏捷團隊的一大難題。我們一直在談論如何用持續、迭代和增量的方式工作。但是現在卻有些人跑過來，想提早知道它會花費多少時間及多少成本。
軟件項目天生就是變化無常的，不可重復。如果要提前給出一個固定的價格，就幾乎肯定不能遵守開發上的承諾。
如果你現在別無選擇，你不得不提供一個固定價格，那么你需要學到真正好的評估技巧。
?
19 守護天使
“你不必為單元測試花費那么多時間和精力。它只會拖延項目的進度。好歹，你也是一個不錯的程序員—單元測試只會浪費時間。”
單元測試能及時提供反饋
單元測試讓你的代碼更加健壯
單元測試時有用的設計工具
單元測試是你自信的后臺
單元測試是可信的文檔
單元測試是學習工具
?
20 先用它再實現它
“前進，先完成所有的庫代碼。后面會有大量時間看用戶是如何思考的。現在只要把代碼扔過墻就可以了，我保證它沒有問題。”
很多成功的公司都是靠著“吃自己的狗食”活著。也就是說，如果要讓你的產品盡可能地好，自己先要積極地使用它。
編程之前，先寫測試。
先寫測試，你就會站在代碼用戶的角度來思考，而不僅僅是一個單純的實現者，這樣做是有很大區別的，你會發現因為你自己要使用它們，所以能設計一個更有用、更一致的接口。
?
21 不同環境，就有不同問題
“只要代碼能在你的機器上運行就可以了，誰會去關心它是否可以在其他平臺上工作，你又不用其他平臺。”
一位同事的代碼失敗了，最終找到了罪魁禍首：一個.NET環境下的API在Windows XP和Windows2003上的行為不同。平臺不同，造成了結果的不一樣。
使用持久集成工具，在每一種支持的平臺和環境中運行單元測試，要積極地尋找問題，而不是等問題來找你。
?
22 自動驗收測試
“很好，你現在用單元測試來驗證代碼是否完成了你期望的行為。發給客戶吧。我們很快會知道這是否是用戶期望的功能。”
關鍵業務邏輯必須要獨立進行嚴格的測試，并且最后需要通過用戶的審批。但是，你又不可能拉著用戶，逐一模塊確認。所以你需要能自動比較用戶期望和實際完成的工作。
FIT（fit.c2.com），即集成測試框架，它很實用，可以更容易的使用HTML表格定義測試用例，并比較測試結果數據。
?
23 度量真正的進度
“用自己的時間表報告工作進度。我們會用它做項目計劃。不用管那些實際的工作時間，每周填滿40小時就可以了。”
時間表很難真實地反映工作完成狀況，因此它不可以用來進行計劃、評估或表現評估。
你曾經聽到開發人員報告一個任務完成了80%么？然而過了一天又一天，一周又一周，那個任務仍然是完成80%。
隨意用一個比率進行度量是沒有意義的。所以不應該去計算工作量完成的百分比，而應該測定還剩下多少工作量沒有完成。如果你最初估計這個任務需要40個小時，在開發了35個小時之后，你認為還需要另外30個小時的工作。那就得到了很重要的度量結果（這里誠實非常重要，隱瞞真相毫無意義）
關注功能，而不是日程表。
?
24 傾聽用戶的聲音
“用戶就是會抱怨。這不是你的過錯，是用戶太愚蠢了，連使用手冊都看不懂。它不是一個bug，只是用戶不明白如何使用而已。他們本應該知道更多。”
不管它是否是產品的bug，還是文檔的bug，或者是對用戶社區理解的bug，它都是團隊的問題，而不是用戶的問題。
對于一些軟件，倒霉的用戶必須要配置那些包含了一些魔術數字的模糊系統文件，否則系統根本不會運行。系統既沒有錯誤提示消息，也不會崩潰，只是顯示大黑屏和一個斗大的“退出”按鈕。
每一個抱怨的背后都隱藏著一個事實。找出真相，修復真正的問題。
沒有愚蠢的用戶；只有愚蠢自大的開發人員。
“它就是這樣的。”這不是一個好答案。
你的用戶有可能會閱讀所有的文檔，記住其中的所有內容。但也可能不會。
?
25 代碼要清晰地表達意圖
“可以工作而且易于理解的代碼當然好，但是讓人覺得聰明更加重要。別人給你錢是因為你腦子好使，讓我們看看你到底有多聰明。”
Hoare說“設計軟件有兩種方式。一種是設計得盡量簡單，并且明顯沒有缺陷。另一種方式是設計得盡量復雜，并且沒有明顯的缺陷。”
（Hoare創造了Algol 60編程語言，并發明了快速排序算法。于1980年獲得圖靈獎。）
代碼閱讀的次數要遠遠超過編寫的次數，所以在編寫的時候值得花點功夫讓它讀起來更加簡單。
當開發人員們像一群旁觀者見到UFO一樣圍在代碼四周，感到恐懼、困惑與無助時，這個代碼的質量就可想而知了。
看一個例子：
coffeeShop.PlaceOrder(2);//通過閱讀代碼，可以大致明白這是要在咖啡店中下一個訂單。但是2代表什么意思？
coffeeShop.PlaceOrder(2 /* large cup */); //不妨添加一些注釋。但注釋有時候是為了幫寫得不好的代碼補漏。
public enum CoffeeCupSize
{
Small,
Medium,
Large
}
coffeeShop.PlaceOrder(CoffeeCupSize,Large);//如果使用上枚舉值，代碼就一目了然了。
應該讓自己或團隊的其他任何人，可以讀懂自己一年前寫的代碼，而且只讀一遍就知道它的運行機制。
?
26 用代碼溝通
“精確地解釋代碼做了什么，每行代碼都要加注釋。不用管為什么要這樣編碼，只要告訴我們做了什么就好了。”
源代碼可以讀懂，不是因為其中的注釋，而應該是由于它本身優雅而清晰。
要盡量避免使用神秘的變量名。（i常用于循環索引變量，str常用于表示字符串。如果用str表示循環索引變量，可真不是好主意）
在代碼可以明確傳遞意圖的地方，不要使用注釋。
解釋代碼做了什么的注釋用處不那么大。相反，注釋要說明為什么會這樣寫代碼。
?
27 動態評估取舍
“性能、生產力、優雅、成本以及上市時間，在軟件開發過程中都是至關重要的因素。每一項都必須達到最理想的狀態。”
與其花費時間去提升千分之一的性能表現，也許減少開發投入，降低成本，并盡快讓應用程序上市銷售更有價值。
如果現在投入額外的資源和精力，是為了將來可能得到的好處，要確認投入一定要得到回報。（大部分情況下，是不會有回報的）
?
28 增量式編程
“真正的程序員寫起代碼來，一干就是幾個小時，根本不停，甚至連頭都不抬。不要停下來去編譯你的代碼，只要一直往下寫就好了！”
如果不對自己編寫的代碼進行測試，保證沒有問題，就不要聯系幾個小時，甚至連續幾分鐘進行編程。相反，應該采用增量式的編程方式。
采用增量式編程和測試，會傾向于創建更小的方法和更具內聚性的類。你應該經常評估代碼質量，并不時的進行許多小調整，而不是一次修改許多東西。
在寫了幾行代碼之后，你會迫切地希望進行一次構建/測試。在沒有得到反饋時，你不要走的太遠。
?
29 保持簡單
“通過編寫史上最復雜的程序，你將會得到美譽和認可，更不用提保住你的工作了。”
Andy曾經認識一個家伙，他對設計模式非常著迷，想把它們全都用起來。有一次，要寫一個大概幾百行的代碼程序。在被別人發現之前，他已經成功將17種設計模式，都運用到那可憐的程序中了。—這不應該是編寫敏捷代碼的方式。
問題在于，許多開發人員傾向于將投入的努力與程序復雜性混同起來。如果你看到別人給出的解決方案，并評價說“非常簡單且易于理解”，很有可能你會讓設計者不高興。許多開發人員以自己程序的復雜性為榮，如果能聽到“Wow，這很難，一定是花了很多時間和精力才做出來的吧。” 這時，他們就會面帶自豪的微笑了。其實應當恰恰相反，開發人員更應該為自己能夠創建出一個簡單并且可用的設計而驕傲。
簡單不是簡陋。
?
30 編寫內聚的代碼
“你要編寫一些新的代碼，看看IDE中現在打開的是哪個類，就直接加進去吧。如果所有的代碼都在一個類或組件里面，要找起來是很方便的。”
內聚性用來評估一個組建（包、模塊或配件）中成員的功能相關性。內聚程度高，表明各個成員共同完成了一個功能特性或是一組功能特性。內聚程度低的話，表明各個成員提供的功能是互不相干的。
類也要遵循內聚性。如果一個類的方法和屬性共同完成了一個功能，這個類就是內聚的。
不過，不要把一些東西分成很多微小的部分，而使其失去了實用價值。當你需要一只襪子的時候，一盒棉線不能帶給你任何幫助。
