22 死程式不說謊
早崩潰。不要破壞（trash），寫入錯誤的資料
23 斷言式程式設計
如果它不可能發生，用斷言確保它不會發生。
斷言時不要有***
24 何時使用異常
理解需求，異常是留給意外事件的
25 怎樣配平資源
要有始有終：分配資源，使用它，釋放它
巢狀的分配（一次性不只乙個資源）
·以與資源分配的次序相反解除資源的分配，如果乙個資源含有對另乙個資源的引用，就不會造成資源被遺棄
·在**不同的地方分配同一組資源，總是以相同的次序分配他們，這將降低死鎖的可能性。
26 解耦與得墨忒耳法則
遵循得墨忒耳法則雖然可以減少模組之間的依賴，但是會帶來很多委託方法出現，不僅增加無關的**，還影響**的執行速度，所以需要根據不同的場景折衷，違反規範來贏取效能的改進。
27 元程式設計
元資料·元資料（metadata）:描述應用的配置選項：調協引數、使用者偏好
·元資料嚴格意義上是資料的資料，寬泛意義上是對任何對應用進行描述的資料。（除了偏好外，還有資源等）
·元資料是在執行時被訪問和使用，而不是在編譯時。
把抽象放在**，把細節放在元程式
28 時間耦合
一開始程式設計都是按照時間的順序去進行。但是一旦需要併發時，就出現了麻煩。
利用uml的活**，分析工作流。
29 它只是檢視
我們基於分而治之的理念將程式分成若干個模組，但是怎麼管理組織不同模組（類）之間依賴確實乙個難題。
我們從事件（event）這個概念出發，將新變化傳送給感興趣的物件。、
corba event service 允許參與物件通過事件通道（公共匯流排）傳送和接受通知。
mvc（模型-檢視=控制器）模式有效地讓模型與gui分離，又與管理檢視的控制項分離。
模型：表示圖示物件的抽象資料模型。模型對任何檢視或控制器都沒有直接的了解
檢視：解釋模型的方式。它定業模型中的變化和來自控制器的邏輯事件
控制器：控制檢視。並向模型提供新資料的途徑。它既向模型也向檢視發布事件。
仍然有耦合，情看下一節 黑板
30 黑板
將警探辦案將線索資訊張貼在黑板的例子指出黑板方法的特性：
- 沒有物件需要知道另外其他物件的存在，他們從黑板中檢視資訊，並新增他們的發現。
- 使用黑板的物件或者模組都有乙個共同點就是圍繞同乙個目標或者功能，如在例子中是破案。
對於複雜多變的工作流，我們可以黑板來協調。
·資料到達的次序無關緊要
·在收到某項事實會觸發適當的規則。
31 靠巧合程式設計
為什麼不能靠巧合程式設計（看起能工作）：
·它也許不是真的能工作依靠的邊界條件知識偶然，在另乙個條件下又不能工作了
·沒有記入文件的行為可能隨著庫的下次發布而變化
·多餘的呼叫讓**變慢
·多餘的呼叫可能引入bug
深思熟慮地程式設計
·總是意識到自己在做什麼
·不要盲目程式設計，構建不完全理解的應用和使用你不熟悉的技術
·按照計畫行事，有條不紊！！！
·依靠可靠的事物，如可靠的庫。
·為你的假定建立文件。
·為你工作劃分優先順序，時間花在重要和最難的方面。
·不做歷史的奴隸，加入已有的**不適用了，盡快替換。
32 演算法速率
對於演算法使用的資源。處理、記憶體進行估算。
o()表示法對我們度量的事物值設定了上限。
一些常見的o()表示法
o(1)
o(lg(n))
o(n)
o(nlg(n))
o(n^2)
o(n^3)
o(c^n)
雖然我們不用去設計編寫排序等演算法，但是 估算演算法的階 有利我們對自己編寫的程式的運**況有一定了解
33 重構
重構=重寫+重做+重新架構
何時進行重構：
·重複（dry）
·非正交設計
·過時的知識
·效能
早重構，常重構
怎樣重構：
·不要在重構同時增加功能
·在開始重構之前確保擁有良好的測試，盡可能經常執行這些測試，這樣能及早發現問題。
·採取短小的步驟，並在每個步驟後進行測試，避免長時間的除錯。
34 易於測試的**
單元測試：針對合約進行測試。
為測試而設計：
在設計模組甚至是單個例程時既設計其合約也設計測試該合約的**。
35 **的嚮導
不要使用你不理解的嚮導**
36 需求之坑
不要蒐集需求，挖掘它們。
應該用明了的陳述句表達需求。有時候在陳述需求中會夾帶著商業政策，而 商業政策是經常改變的。所以我們需要將商業政策與需求做區分。
在討論使用者介面時，需求、政策和實現之間區別可能會變的模糊不清。
重點 找出使用者 為何做特定事情的原因，而不是他們目前做這件事情的方式。
建立需求文件：用use case（用例）來描述系統的特定用法。
相應的用例模板
抽象比細節活得更長久
維護專案的詞彙表，利於溝通。
37 解開不可能解開的謎題
當遇到乙個迷途難以解開的時候，解決的方法可能不在你現在思考的範圍內。所以需要重新確定方法的約束，有些約束是絕對約束，而有些約束是先入為主。
不要在盒子外面思考-要找到盒子：我們需要確定問題的自由度，也就是約束
想想特洛伊木馬
一定有更容易的方法
·有更容易的方法？
·你是在設法解決問題還是被外部的技術問題轉移注意力
·這件事情為什麼是乙個問題
·是什麼使它難以解決
·它必須以這種方式完成嗎？
·它真的必須完成嗎？
38 等你準備好
傾聽反覆出現的疑慮-等你準備好再開始
是良好的判斷還是拖延
- 拖延：對於概念的驗證出現「浪費時間」的厭煩
- 良好的判斷，隨著原型進展，肯呢個在某個時刻得到啟示，突然意思到某個前提是錯誤的。
39 規範陷阱
對於有些事情，「做」勝於「描述」
40 圓圈與箭頭
不做形式方法的奴隸
工具只是工具，要為我所用。
第四次讀後感
我是乙隻it小小鳥 讀後感 老師的強烈推薦以及周圍同學們的好評促使我讀了這本書。在這忙碌的一周裡，基本上很少有機會好好休息，但我基本上一有一點點空閒時間，我就會開啟pdf閱讀這本書。這本書和之前看的軟工書有很大的不同，以前的書基本上都是技術開發方面的，就是 移山之道 vsts開發指南 也只能算是帶有...
《程式設計師修煉之道》 讀後感
前些時間把 程式設計師修煉之道 讀了一遍。一本好書啊。且不說裡面的一些程式設計技巧 這個詞應該比較貼切 比如正交性 高內斂，最後達到兩個模組之間互補影響 曳光彈或是原型 輕量級引導程式，直達目標，方便調整 斷言式程式設計，異常使用 暴露程式的問題，不要隱藏他 解耦與墨忒爾法則 低耦合，減少依賴 演算...
《程式設計師修煉之道》讀後感
看到這個書名的時候，會不自覺的想起周星馳在 喜劇之王 中的經典橋段，手拿一本 演員的自我修養 激勵著很多懵懂青年。就像這本書的自序所講的，這是一本包含有許多樸素的經驗，寫給注重實效的程式設計師的一本 演員的自我修養 剛剛步入程式設計隊伍的我，正需要這樣一本書給予我經驗，也因為是多年精心耕耘的結果，一...