請您在閱讀本文之前，先了解《高效程序員的45個習慣》-之三。
每一期都會涉及15個話題，用3期來列出這45個習慣，每次不貪多，貪精，大家如果有空，一定要細細品味這15個習慣。
注意：每一個好的習慣，開頭都會相應有一個唱反調的句子哦。
?
31 告知，不要詢問
“不要相信其他的對象。從別人那里去拿你需要的信息，然后自己處理，自己決策。不要放棄控制別人的機會”。
告知=命令，詢問=查詢
命令和查詢相分離模式，就是要將功能和方法分為命令和查詢兩類，并在源碼中記錄下來，以做到將命令代碼都放在一起，并將所有查詢代碼都放在一起。
絕對不能允許一個看起來無辜的“查詢”去修改對象的狀態。
?
32 根據契約進行替換
“深層次的集成是很棒的。如果你需要其他類的函數，直接繼承它們就好了！”
保持系統靈活性的關鍵方式，是當新代碼取代原有代碼之后，其他已有的代碼不會意識到任何差別。
如果你不確定一個接口做出了什么樣的承諾，或者有什么樣的需求，那就很難提供一個對其有意義的實現了。
?
33 記錄問題解決日志
“在開發過程中是不是經常遇到似曾相識的問題？這沒關系，以前解決過的問題，現在還是可以解決掉的。”
面對問題是開發人員的一種生活方式。當問題發生時，我們會希望記起第一次是如何解決的，而且希望下次能夠更快地把它搞定。但是，有時我們又記不清上次是如何修復的了。
不要在同一處跌倒兩次。
要想得到更好的效果，不妨維護一個保存曾遇到的問題以及對應解決方案的日志，我們稱之為每日日志（daylog）。
可以選擇符合需求的任何格式，下面的內容可能用得上：
- 問題發生日期
- 問題簡述
- 解決方案詳細描述
- 引用文章或網址，以提供更多細節或相關信息
任何代碼片段、設置或對話框的截屏，只要它們是解決方案的一部分，或者可以幫助更深入地理解相關細節。
務必要將上述信息變為計算機可搜索的格式。
?
34 警告就是錯誤
“編譯器的警告信息只不過是給過分小心和過于書呆子氣的人看的。它們只是警告而已。”
有些警告是過于挑剔的編譯器的良性副產品，但有些則不是。例如，一個關于未被使用的變量的警告，可能不會產生什么惡劣影響，但卻有可能是暗示某些變量被錯誤使用了。
簽入帶有警告的代碼，就跟簽入有錯誤或者沒有通過測試的代碼一樣，都是極差的做法。
?
35 對問題各個擊破
“要調試一個明顯的錯誤，只要去查看整個系統的代碼，而且是要全部過一遍。畢竟你不知道問題可能發生在什么地方，這樣做是找到它的唯一方式。”
單元測試帶來的積極效應是它會強迫形成代碼的分層。要保證代碼可測試，就必須把它從周邊代碼中解脫出來。
認識復雜問題的第一步，是將它們分離出來。
很多應用的代碼在編寫時沒有注意到這一點，使得分離變得特別困難。應用的各個構件部分之間會彼此糾結：想把這個部分單獨拿出來，其他的會緊隨而至。在這些狀況下，最好花一些時間把關注的代碼提取出來，而且創建一個可讓其工作的測試環境。
?
36 報告所有的異常
“不要讓程序的調試者看到那些奇怪的異常。處理它們是你的責任。把你調用的一切都包起來，然后發送自己定義的異常。”
作者曾經使用一個非常流行的開源程序庫時倍受打擊。作者調用的一個方法本來應該創建一個對象，可得到的卻是null，調查很久都沒有頭緒。幸好這個庫是開源的，所以他下載了源代碼，并找到了出問題的那個調用方法。那個方法認為她的系統中缺少了某些必要的組件。這個底層方法拋出了帶有相關信息的異常。但是，上層方法卻偷偷地用沒有異常處理代碼的空catch代碼塊，把異常給忽略掉了，然后拋出了一個null。后來，作者安裝了相應的組件，問題解決了。
?
37 提供有用的錯誤信息
“不要嚇著用戶，嚇程序員也不行，要提供給他們干凈整潔的錯誤信息。”
在設計一個登陸頁面時，當用戶輸錯密碼時，我們提示哪個信息更好呢：“Unable to perform operation”、“Couldn’t login…”、還是“Error validating password”
錯誤信息有助于問題的解決。當問題發生時，可以詳細研究問題的細節描述和發生上下文。
?
38 定期安排會面時間
“會議安排得越多越好。實際上，我們要安排更多的會議。”
立會 （站著開的會議，Scrum最早引入并被極限編程所強調的一個實踐）是將團隊召集在一起，并讓每個人了解當下進展狀況的好辦法。顧名思義，參與者們不允許在立會中就坐，這可以保證會議快速進行。一個人坐下來之后，會由于感到舒適而讓會議持續更長的時間。
要保證立會議題不發散，每個人只能回答下述三個問題：
- 昨天的收獲是什么
- 今天計劃要做哪些工作
- 面臨著哪些障礙
大家都期盼著立會，希望彼此了解各自的進度和手上的工作，而且不怕把各自遇到的問題拿出來公開討論。
?
39 架構師必須寫代碼
“我們的專家級架構師會提供設計好的架構，供你編寫代碼。他經驗豐富，拿的薪水很高，所以不要用一些愚蠢的問題或者實現上的難點來浪費他的時間。”
這些架構師通常在項目開始時介入，繪制各種各樣的設計圖，然后在重要的代碼實現開始之前離開。有太多這種“Powerpoint架構師”。由于得不到反饋，而且設計會隨著時間而演進，所以他們的架構設計工作也不會有很好的收效。
新系統的設計者必須要親自投入到實現中去。
?
40 實行代碼集體所有制
“不用擔心那些煩人的bug，Joe下周假期結束回來后會把它解決掉的。在此之前先想個權宜之計應付一下吧。”
不應像國家宣稱對領土的所有權一樣，聲明個人對代碼的所有權。任何一位團隊成員，重要理解某段代碼的來龍去脈，就應該可以對其進行處理。如果某一段代碼只有一位開發人員能夠處理，項目的風險無形中也就增加了。
相比找出誰的主意最好、誰的代碼實現最爛而言，解決問題，并讓應用滿足用戶的期望更為重要。
在大型項目中，如果每個人都可以隨意改變任何代碼，一定會把項目弄得一團糟。代碼集體所有制并不意味著可以隨心所欲、到處破壞。
?
41 成為指導者
“你花費了大量的時間和精力，才達到目前的水平。對別人要有所保留，這樣讓你看起來更有水平。讓隊友對你超群的技能感到恐懼吧。”
教學相長。通過詳細解釋自己知道的東西，可以使自己的理解更深入。當別人提出問題時，也可以發現不同的角度。
成為指導者，意味著要分享，而不是固守自己的經驗、知識和體會。
?
42 允許大家自己想辦法
“你這么聰明，直接把干凈利落的解決方案告訴團隊其他人就好了。不要浪費時間告訴他們為什么這么做。”
作為指導者，應該鼓勵、引領大家思考如何解決問題。
用問題來回答問題，可以引導提問的人走上正確的道路 。
?
43 準備好后再共享代碼
“別管是不是達到代碼簽入的要求，要盡可能頻繁的提交代碼，特別是要下班的時候。”
向代碼庫中提交仍在開發的代碼，會帶來很多風險。當其他開發者獲取最新版本的代碼時，也會受到這些代碼的影響。
絕不要提交尚未完成的代碼。故意簽入編譯未通過或是沒有通過單元測試的代碼，對項目來說，應被視作玩忽職守的犯罪行為。
?
44 做代碼復查
“用戶是最好的測試人員。別擔心–如果哪里出錯了，他們會告訴你們的。”
代碼剛剛完成時，是尋找問題的最佳時機。如果放任不管，它也不會變得更好。
管理層擔心進行代碼復查所耗費的時間。他們不希望團隊停止編碼，而去參加長時間的代碼復查會議。開發人員對代碼復查也感到擔心，允許別人看他們的代碼，會讓他們有受威脅的感覺。這影響了他們的自尊心。
要尋找深藏不露的代碼bug，正式地進行代碼檢查，其效果是任何已知形式測試的兩倍，而且是移除80%缺陷的唯一已知方法。
在極限編程中，不存在一個人獨立進行編碼的情況。編程總是成對進行的 ：一個人在鍵盤旁邊（擔任司機的角色），另一個人坐在后面擔任導航員。他們會不時變換角色。有第二雙眼睛在旁邊盯著，就像是在進行持續的代碼復查活動，也就不必安排單獨的特定復查時間了。
你也可以考慮使用諸如Similarity Analyzer或Jester這樣的代碼分析工具。
不進行思考、類似于橡皮圖章一樣的代碼復查沒有任何價值。
?
45 及時通報進展和問題
“管理層、項目團隊以及業務所有方，都仰仗你來完成任務。如果他們想知道進展狀況，會主動找你要的。還是埋頭繼續做事吧。”
如果等到截止時間才發布壞消息，那么經理或技術主管就會擔心你再次讓他們失望，并開始每天多次檢查你的工作進度。
及時通報進展和問題，有情況發生時，就不會讓別人感到突然，而且他們也很愿意了解目前的進展和狀況。他們會知道何時應提供幫助，而且你也獲得了他們的信任 。
?
結束語
《高效程序員的45個習慣》，
每一個習慣都值得程序員同學去仔細體會和吸收。
