高效能程式設計師的修煉
軟體開發者們是真心喜愛編寫**的。但根據我的經驗，他們當中很少有人可以解釋清楚他們為什麼在編寫**。如果你不信，你可以從你的團隊裡找個人來測試一下：問他在做什麼；接著問他為什麼要做那個；繼續問下去，直到你得到乙個可以讓你的客戶理解的原因。
你在做什麼？
我在修復這個資料網格的排序問題。
你為什麼要解決這個問題？
因為它在bug清單上。
它為什麼在bug清單上？
因為有個測試人員把它作為乙個bug報出來了。
為什麼它被作為乙個bug報出來了？
測試人員認為這個字段應該按照數字順序而不是字母順序來排序。
為什麼測試人員這麼認為？
很顯然，如果把「條目2」排在「條目19」的後面，使用者在查詢的時候就會有麻煩。
如果這段對話在你看來很奇怪，或許你還沒有跟足夠多的軟體開發者一起工作過。你知道你到底要問多少次「為什麼」才會得到你的客戶真正在意的答案嗎——哪怕只挨上一點邊？正如「你要舔多少次才能吃完一根tootsie pop棒棒糖」這個問題，答案一定會讓你很吃驚！
這是乙個巨大的鴻溝！
軟體開發者認為他們的工作就是編寫**。其實不然。（這句話是我從billy hollis那裡「偷」來的。他曾以軟體痴迷者為主題做過15分鐘的精彩演講。）他們的工作應該是解決客戶的問題。當然，我們偏愛通過軟體來解決問題，那的確包含了編寫**。但是，我們要有全域性的觀點：在交付完整的解決方案的過程中，編寫**只是其中一環。它自身並不是目的。
作為軟體開發者，我們花了那麼多時間沉浸在沒完沒了的、支離破碎的細節中，以至於我們太容易掉入為了編碼而編碼的陷阱中。如果沒有明確的焦點或者某種讓我們團結在一起的東西，我們就會只見**這棵樹木而不見整個森林。由此可見，擁有乙個清晰的專案遠景宣告（vision statement）是極其重要的，每個人都可以把它當做這個專案的試金石。如果你把遠景宣告搞清楚了，你團隊裡的每個人都應該能通過由陌生人主持的「電梯測試」——在60秒之內，清晰地解釋他們在做什麼，以及為什麼人們會在意他們正在做的事情。
如果你的團隊不能用一種合理的方式向乙個外行解釋他們的工作，不管你有沒有意識到，你都已經處在麻煩之中了。所幸的是，你有個好夥伴——jim highsmith可以幫助你。他推薦了乙個可以構建專案遠景模型的速效公式：
乙個專案遠景模型可以幫助團隊成員通過「電梯測試」——它能賦予團隊成員在2分鐘之內向別人解釋清楚專案的能力。這個模型出自geoffrey moore1的一本書：《跨越鴻溝》（《crossing the chasm》）。它遵循如下的形式：
為了（目標客戶）
他們（關於需求或者機會的說明）
這個（產品名稱）是（產品類別）
它的（關鍵優勢、吸引人的購買理由）
不像（主要競爭對手的替代產品）
我們的產品（主要的差異化的特性說明）
建立乙個專案遠景宣告可以幫助團隊持續專注於產品的關鍵方面，哪怕細節一直在快速變化也不怕；否則，團隊很容易就會被短期（2～4周）開發迭代中的問題纏住，從而失去對整個專案遠景的控制。
我對這個速效公式並不感冒，因為它太過死板。但它是乙個不錯的開始。玩玩「mad libs」2吧，看你能想到些什麼——絕對不能沒有遠景宣告，但也不要乙個毫無感覺、用雜亂無章的拼盤偽裝成的遠景宣告。然而，我認為jim關於開發遠景宣告的第二個建議更能給我們帶來希望。
我認為，即使在乙個提供資訊科技服務的組織裡，每個專案都應該被當作是乙個創造「產品」的過程。無論這個專案的目標是提公升內部的會計系統，還是建立乙個全新的電子商務**，面向產品的思維方式必能帶來豐厚的回報。
我發現有一種做法在讓整個團隊思考產品遠景方面很有效果，那就是「設計產品包裝盒」。這個練習可以在專案啟動階段很好地激發大家的思維和討論。整個團隊假設產品最終會被裝在乙個可拆封的盒子裡，而他們的任務就是設計這個包裝盒的正面和背面。這包括給產品起個名字、一幅、正面列出3～4個關鍵點來「叫賣」這個產品、背面的詳細特性說明以及執行要求。
實踐證明，想出15～20個產品特性是容易的。難就難在，要選出其中3～4個能促使人們購買這個產品的特性。這個過程中還經常會發生關於「誰是真正的客戶」的激烈爭論。
「設計產品包裝盒」是構建遠景宣告的一種極好的方法。它基於乙個具體的、真實世界裡的概念，因此大多數人都可以輕鬆地開動他們的腦筋。忘掉那些空中餡餅式的遠景追求吧，讓我們務實一點：我們（假想）的產品包裝盒看起來會是什麼樣的呢？
我們都是消費者。我們對產品包裝盒的設計目標都很清楚。如果不拿產品包裝盒跟極端的「電梯推介3」相提並論，那它也應該：
這裡有個例子，讓我們來看看命運多舛的microsoft bob4的包裝盒。你該如何解釋為什麼客戶應該購買microsoft bob？甚至你該如何說明這個見鬼的microsoft bob到底是個什麼東西？
看看那些現有的、你覺得引人注目的產品包裝盒是有指導意義的。當然，看看那些你覺得不好的包裝盒也可以引以為戒。我們很清楚我們的產品包裝盒不應該是什麼樣子。
從專案開始的第一天就確立乙個堅定的遠景宣告吧！如果你還沒有，那就從jim眾多美妙的建議裡隨便挑選乙個，然後照著去做，立即構建出乙個遠景宣告。在缺乏清晰的遠景宣告時，無法通過「電梯測試」的團隊數目將是令人震驚的——他們不能解釋他們正在做什麼，或者為什麼他們的工作是有意義的。不要犯那樣的錯誤。構建乙個了不起的遠景宣告，讓你的隊友們可以使他們的工作與這個遠景相關聯。確保你的團隊可以通過「電梯測試」。
作者在twitter上發的一條短訊：
高效能程式設計師的修煉
1.盡量寫的簡潔，大道至簡 if s string.empty if s 2.寫 的時候注釋要突出功能的具體實現方法，而不是要寫出該段程式實現子什麼功能，盡量用函式名就表明了這段程式所要表達的意思，程式要寫的簡單明白其它的程式設計師能夠看懂 3.向 橡皮鴨求助 這個例子，就像很多電影裡乙個人物對著乙...
關於《高效能程式設計師的修煉》
關於 高效能程式設計師的修煉 關於注釋議論，與筆者不謀而合，注釋就是 寫的不好的物證，其實 不需要注釋，自己就可以說明自己。關於老鼠 電擊和乳酪的問題，其實大家現在往往再犯加兩倍 酪的同時，也加了 5倍的電擊，最終客戶或使用者只是說一句不好用，就對辛辛苦苦一年的成果無情給扼殺了。關於寫點東西的問題，...
20131123《高效能程式設計師的修煉》
好不容易盼來了乙個週末，平時待實驗室也就算了，幹嘛到了週末還在那裡待呢。乙個人閒來在寢室沒事，就隨意看看書，寫寫東西吧。今天看到額jeff atwood的 高效能程式設計師的修煉 這本書一開始就說了，要做程式設計師，你必須是對程式設計比較熱愛的，這樣的乙個開篇再次將我轉網際網路的想法打消掉了。下面就...