專案開始之前
需求之坑
挖掘需求
建立需求文件
解開不可能解開的謎題
一定有更容易的方法
等你準備好
規範陷阱
圓圈與箭頭
在專案最開始需要確定各種需求，這個階段可以詳細閱讀「需求之坑」。不管在做需求、分析、編碼還是測試總是會遇到各種難題，這個階段可以詳細閱讀「解開不可能解開的謎題」。當你認為已經解決了問題，但你仍然覺得不能啟動專案。這個階段可以詳細閱讀「等你準備好」。專案開發會制定一系列的規範，同時在規範中也存在一些「規範陷阱」。最後我們在「圓圈與箭頭」中考察各種形式開發過程中和方法學的一些缺陷，不管包括那些方法，沒有什麼方法能夠代替思考。在專案啟動前把關鍵問題解決好，就能更好的避免「分析癱瘓」。
完美，不是在沒有什麼需要增加，而是在沒有什麼需要去掉時達到的。
許多書籍和教程都把需求蒐集當作早期階段，事實上需求很少存在表面，通常需求深深的埋藏在層層假定、誤解和政治手段下面。
不要蒐集需求，去挖掘需求。
怎樣真實有效的挖掘需求？
簡單的回答：需求是對需要完成的某件事情的概述。事實上，使用者很少能說出清晰準確的需求，我們需要找出使用者為何要做特定事情的原因，而不只是他們目前做這件事情的方式。這很重要，因為你的開發必須解決他們的商業問題，而不只是滿足他們陳述的需求。有一種能深入了解使用者需求的方式，成為使用者。與使用者一同工作，以像使用者一樣思考。開採需求的過程也是開始與使用者建立和諧關係、了解他們對你正在構建的系統的期許和希望。
從使用者探問真實的需求，你需要編寫一些合適的、描述應用需要的場景的文件，利於每個人都可以用作討論基礎的文件。【捕捉需求的用例這一概念，指的是讓你描述系統的特定用法，不是根據使用者介面，而是以一種更為抽象的方式】我們應該相信乙個信念，成功的工具會更適應使用者的雙手。
看待用例的一種方式是強調目標驅動的本質。用形式化的模板用作備忘錄，可以確保自己包括了用例中所需的所有資訊:履行指標、其他有關方面、優先順序、頻度、以及各種可能突然出現的錯誤和異常。
不要做任何表示方法的奴隸，只要是你與你的聽眾交流需求的最好方法都可以使用。
製作需求文件最大的危險就是太過具體，好的需求文件會保持抽象。在涉及需求的地方是最簡單、最直接準確的反映商業需要的陳述是最好的。需求不是架構，不是設計，也不是使用者介面。需求是需要。
我們要盡可能的超出當時的商業實踐往前看，應該讓需求更抽象。永遠要記住抽象比細節活得更長久。
許多專案的失敗都歸咎與專案範圍的增大：特性膨脹、蔓延特性論或是需求蔓延，我們應該怎麼做才能有效避免？管理需求增長的關鍵是指出每項新特性對專案進度的影響，我們很容易進入乙個叫「只是再增加乙個特性」的大漩渦。
一旦開始討論需求，使用者和領域專家會使用各自對他們具有特定含義的術語，使用不同的名稱指定同一事物或者相同名稱指定不同事物，這無疑是乙個很糟糕的情況，這個時候需要建立維護詞彙表。在定義專案中使用專業術語和詞彙，確保一致性。
在專案中，會發現自己遇到乙個牽扯到很多非常困難的問題。解開這個謎題的秘訣是確定真正的（而不是想象）約束，並在其中找出解決方法。有些約束是絕對的；有些約束只是先入之見。絕對約束必須受到尊重，不管他們看上去多討厭或愚蠢，有些表面上的約束也許並不是真正的約束，很多軟體都具有與之相同的欺騙性。我們應該找到絕對約束。
「在盒子外面思考」鼓勵外面找出可能不適用的約束，並忽略它們。如果「盒子」是各種約束和條件的邊界，那麼訣竅在於找到「盒子」。解開謎題的關鍵在於確定加給你的各種約束，並確定你確實擁有的自由度。問題並不在於你是在盒子裡面思考，還是盒子外面思考，而是在於找到盒子，確定真正的約束。不要在盒子外面思考，要找到盒子。對你的各種約束進行分類，並劃分優先順序，先確定最為嚴格的約束，然後在確定其中考慮其他約束。
有時候你會發現自己在處理的問題似乎比你認為的要難很多，感覺就像你走錯了路，一定有比這更容易的方法。這個時候需要問問自己以下問題：
很多時候，你會發現對需求的重新詮釋能讓整個問題全部消失，你所需要的只是真正約束、令人誤解的約束、還有區分他們的智慧型。
傾聽反覆出現的疑慮，等你準備好再開始。
當你面對一件任務時，如果你反覆感覺到疑惑，或者體驗到某種勉強，要注意它。你可能無法準確指出問題所在，但是給它時間，你的疑慮可能就會結晶成某種更堅實的東西，某種你可以處理的東西。
當我們開始面對乙個新的專案時，總是願意延緩最初的啟動承諾。這是我們要採用一種有效的技術是開始構建原型。選擇乙個你覺得會有困難的地方，開始進行某種「概念驗證」。在典型的情況下，會發生兩種情況，1、開始不久後，你覺得自己是在浪費時間。這種情況可以表明你最初的勉強只是希望拖遲啟動。2、在原型取得進展時得到啟示，意識到基本的前提錯了，還可以清晰的看到怎樣糾正錯誤。你的直覺是對的。把構建原型當作調查你的不適的一種方法，一定要記住你為何這樣做。去構建原型會比簡單宣布「我覺得不該啟動」更能讓人接受。
編寫程式規範就是把需求歸納到程式設計師能夠接管的程式的過程。這是乙個交流活動，旨在解釋並澄清系統的需求，比如消除主要的歧義。最終系統將會符合該合約的要求。對有些事情「做」勝於描述。作為注重實效的程式設計師，應該把傾向於把收集、設計、以及實現視為乙個閉環，交付高質量的系統。不要信任蒐集需求、編寫規範、編碼都是孤立進行的環境。規範和實現都是對同乙個過程、設法捕捉和編撰需求的不同方面。每一步都應該直接進入下一步，沒有人為製造的界限，健康的開發過程鼓勵把來自實現與測試的意見反饋到規範中。
我們要樹立乙個觀念：結構化程式設計，擁有長久的生命。也要避免盲目的採用任何技術，而不把他們放進你的開發實踐和能力的語境中。也不要做形式方法的奴隸。
形式方法具備的一些嚴重缺點：
我們始終要記住，形式開發方法只是工具箱中的一種工具。注重實效的程式設計師批判地看待方法學，並從各種方法學中提取精髓，融合成每個月都在變得更好的一套工作習慣。應該不斷努力提煉和改善你的開發過程，絕不要把方法學的呆板限制當作你的世界邊界。
《程式設計師修煉之道》讀書筆記
第1章 你的知識資產 隨著你的知識的價值降低，對你的公司或客戶來說，你的價值也在降低。管理知識資產與管理金融資產非常相似，管理金融資產基本遵循 1.嚴肅的投資者定期投資 作為習慣 2.多元化是長期成功的關鍵 3.聰明的投資者在保守的投資和高風險 高回報的投資之間平衡他們的資產 4.投資者設法低買高賣...
程式設計師修煉之道 讀書筆記
注重實效的程式設計師的特徵 care about your craft 關心你的技藝 think about your work 思考你的工作 1 注重實效的哲學 我的 被貓吃了。負責 破窗理論。軟體的熵 定期為你的知識資產投資 2 注重實效的途徑 dry don t repeat yourself...
《程式設計師修煉之道》讀書筆記
出了問題後，要提出各種解決方案的選擇，而不是找藉口 不要說事情做不到，要說明接下來做什麼來挽回局面 我們看到過整潔 執行良好的系統，一旦窗戶開始破裂，就相當迅速的惡化 不要留著破窗戶不修 發現乙個bug就修復乙個，如果沒有足夠的時間進行恰當的修理，就用木板先訂起來 或許你可以先把 注釋起來，或是顯示...