請您在閱讀本文之前，先了解《高效程序員的45個習慣》-之一。

每一期都會涉及15個話題，用3期來列出這45個習慣，每次不貪多，貪精，大家如果有空，一定要細細品味這15個習慣。

注意：每一個好的習慣，開頭都會相應有一個唱反調的句子哦。

?

1 做事

“出了問題，第一重要的是確定元兇，找到那個人！一旦證實了是他的錯誤，就可以保證這樣的問題永遠也不會再發生了。”

指責不會修復bug，把矛頭對準問題的解決辦法，而不是人。這是真正有用處的正面效應。

也許你不相信，但確實有些人常常不把解決問題放在最高優先級上。也許你也沒有。先自我反省一下，當有問題出現時，“第一”反應究竟是什么？

一個重大的錯誤應該被當作是一次學習而不是指責他人的機會。

團隊成員們在一起工作，應互相幫助，而不是互相指責。

如果你沒有犯過任何錯誤，就說明你可能沒有努力去工作。

?

2 欲訴則不達

“你不需要真正地理解那塊代碼，它只要能夠工作就可以了。哦，它需要一個小小的調整。只要在結果中再加上幾行代碼，它就可以工作了。干吧！就把那幾行代碼加進去，它應該可以工作。”

拙劣的代碼工人會這樣不假思索地改完代碼，然后快速轉向下一個問題；而優秀的程序員會挖掘更深一層，盡力去理解為什么這里需要加1，更重要的是，他會想明白會產生什么其他影響。

千里之堤，潰于蟻穴，大災難是逐步演化而來的。一次又一次的快速修復，每一次都不探究問題的根源，久而久之就形成了一個危險的沼澤地，最終會吞噬整個項目的生命。

如果有一位團隊成員宣布，有一塊代碼其他人都很難看懂，這就意味著任何人（包括原作者）都很難維護它。請讓它變得簡單些。

?

3 對事不對人

“當L先生在做一個新方案介紹時，下面有人會說‘這樣設計很蠢！都沒有考慮線程安全！’（這也暗示著L先生很蠢）。”

事實上，最適合并且最有效的表達方式應該是“謝謝，L先生。但是我想知道，如果兩個用戶同時登錄會發生什么情況？”

盡力貢獻自己的好想法，如果你的想法沒有被采納也無需生氣；不要因為只是想體現自己的想法而對擬定的好思路畫蛇添足。

?

4 排除萬難，奮勇前進

“老鼠們打算在貓的脖子上系一個鈴鐺，這樣貓巡邏靠近時，就能預先得到警報。每只老鼠都點頭，認為這是一個絕妙的想法。這時一個年老的老鼠站出來說道’那么，誰愿意挺身而出去系鈴鐺呢？’毫無疑問，沒有一只老鼠站出來。當然，這個絕妙的計劃也就這樣泡湯了。”

有時，絕妙的計劃會因為勇氣不足而最終失敗。盡管前方很危險，但你必須有勇氣向前沖鋒，做你認為對的事情。

當你勇敢地站出來時，如果受到了缺乏背景知識的抉擇者的抵制，你需要用他們能夠聽懂的話語表達。“更清晰的代碼”是無法打動生意人的。節約資金、獲得更好的投資回報，避免訴訟以及增加用戶利益，會讓論點更有說服力。

?

5 跟蹤變化

“軟件技術的變化如此之快，勢不可擋，這是它的本性。繼續用你熟悉的語言做你的老本行吧，你不可能跟上技術變化的腳步。”

如果只是掌握了工作中需要的技術并不夠。那樣的工作也許幾年之后就不再有了—它會被外包或者會過時，那么你就將會出局。

迭代和增量式的學習；了解最新行情；參加本地的用戶組活動；參加研討會議；如饑似渴地閱讀。

?

6 對團隊投資

“不要和別人分享你的知識—自己留著。你是因為這些知識才成為團隊中的佼佼者，只要自己聰明就可以了，不用管其他失敗者。”

團隊中的開發者們各有不同的能力、經驗和技術。每個人都各有所長。不同才能和背景的人混在一起，是一個非常理想的學習環境。

一個學習型的團隊才是較好的團隊。

每周，要求團隊中的一個人主持講座。他會給大家介紹一些概念，演示工具，或者做團隊感興趣的任何一件事。你可以挑一本書，給大家說說其中一些特別內容、項目或者實踐，無論什么主題都可以。

?

7 懂得丟棄

“那就是你一貫的工作方法，并且是有原因的。這個方法也很好地為你所用。開始你就掌握了這個方法，很明顯它是最好的方法。真的，從那以后就不要再改變了。”

打破舊習慣很難，更難的是自己還沒有意識到這個問題。丟棄的第一步，就是要意識到你還在使用過時的方法，這也是最難的部分。另一個難點就是要做到真正的丟棄舊習慣。 畢竟，汽車要比馬車車廂強多了。

不是完全忘記舊的習慣，而是只在使用適當的技術時才使用它。

?

8 打破砂鍋問到底

“接受別人給你的解釋，別人告訴你問題出在了什么地方，你就去看什么地方。不需要再浪費時間去追根究底”

要不停的問“為什么”。不能只滿足于別人告訴你的表面現象，要不停的提問直到你明白問題的根源。

問“為什么”，但是要問到點子上。

當你問“為什么”的時候，也許你會被反問：“為什么你問這個問題？”。在提問之前，想好你提問的理由，這會有助于你問出恰當的問題。

?

9 把握開發節奏

“我們很長時間沒有進行代碼復審，所以這周會復審所有的代碼。”

在許多不成功的項目中，基本上都是隨意安排工作計劃，沒有任何規律。那么樣的隨機安排很難處理。你根本不知道明天將會發生什么。

但是，敏捷項目會有一個節奏和循環，讓開發變得更加輕松。Scrum約定了30天之內不應該發生需求變化，這樣可以確保團隊有一個良性的開發節奏。（Scrum是一種迭代式增量軟件開發過程，通常用于敏捷軟件開發。包括了一系列實踐和預定義角色的過程骨架。）

站立會議最好每天在固定的時間和地點舉行，比如說上午10點左右。要養成這樣的習慣，在那時就準備好一切參加站立會議。

?

10 讓客戶做決定

“開發者兼具創新和智慧，最了解應用程序。因此，所有關鍵決定都應該由開發者定奪。每次業務人員介入的時候，都會弄得一團糟，他們無法理解我們做事的邏輯。”

在設計方面，做決定的時候必須有開發者參與。可是，在一個項目中，他們不應該做所有的決定，特別是業務方面的決定。

記錄客戶做出的決定，并注明原因。好記性不如爛筆頭。

?

11 讓設計指導而不是操縱開發

“設計文檔應該盡可能詳細，這樣，低級的代碼工人只要敲入代碼就可以了。編寫代碼的時候，無論你發現什么，絕不能偏離了設計文檔。”

設計滿足實現即可，不必過于詳細。

即使之前已經提交了設計文檔，也還會有一些意料之外的情況出現。時刻謹記，此階段提出的設計只是基于你目前對需求的理解而已。一旦開始了編碼，一切都會改變。設計及其代碼實現會不停地發展和變化。

設計可以分為兩層：戰略和戰術。前期的設計屬于戰略，通常只有在沒有深入理解需求的時候需要這樣的設計。更確切的說，它應該只描述總體戰略，不應深入到具體的細節。

?

12 合理地使用技術

“你開始了一個新的項目，在你面前有一長串關于新技術和應用框架的列表。這些都是好東西，你真的需要使用列表中所有的技術。想一想，你的簡歷上將留下漂亮的一筆，用那些偉大的框架，你的新應用將具有極高的技術含量。”

這個技術框架真能解決這個問題么？（如果需要，先做一個小的原型）

你將會被它拴住么？（一些技術是賊船，一旦你使用了它，就會被它套牢，再也不可能回頭了。我們需要考慮它是開放技術還是專利技術）

維護成本是多少？（維護成本昂貴。我們聽說，有個項目的合同是支持一個規則引擎，引擎一年的維護費用是5萬美元，但是，這個數據庫只有30條規則）

不需開發你能下載到的東西。

新技術就應該像是新的工具，可以幫助你更好地工作，它自己不應該成為你的工作。

?

13 保持可發布

“我們剛試用的時候發現了一個問題，你需要立即修復它，放下你手頭的工作，去修復那個剛發現的問題。不用告訴其他任何人—趕快讓它工作就行了。”

已提交的代碼應該隨時可以行動。

在本地運行測試；檢出最新的代碼；提交代碼。

?

14 提早集成，頻繁集成

“只要沒有到開發的末尾階段，就不要過早地浪費時間去想如何集成你的代碼，至少也要等開發差不多的時候，才可以考慮它。”

敏捷的一個主要特點就是持續開發，而不是三天打魚兩天曬網地工作。特別是在幾個人一起開發同一個功能時，更應該頻繁地集成代碼。

絕不要做大爆炸似的集成。

代碼集成是主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律地進行集成。

?

15 提早實現自動化部署

“沒問題，可以手動安裝產品，尤其是給質量保證人員安裝。”

系統能在你的機器上運行，或者能在開發者和測試人員的機器上運行，當然很好，但是，它同時也需要能夠部署在用戶的機器上。

質量保證人員應該測試部署過程。

從第一天起就開始交付，一開始就實現自動化部署應用。

如果維護安裝腳本變得很困難，那很可能是一個早期警告，預示著—很高的維護成本。