看這本書即得一些筆記，權當後續回顧
第一章：實用的哲學
早期的採納者/快速的改編者
好奇批判的思考者
有現實感（設法理解你面臨的每個問題的內在本質，讓自己了解某個過程會有困難，需要多久時間）
多才多藝
thinking 思考你的事情 事後總結 持續改善
思考問題必須思考到更大的圖景
我的**被貓吃了 ， 蹩腳的藉口
不要害怕暴露弱點，並且提前做好備份計畫，考慮多個情況；
提供選擇備選項，而不是找藉口，可以提前溝通
軟體的熵
強者恆強，弱者恆弱理論， 不要容忍破窗戶 ，否則會越來越破敗，所以一定要防微杜漸
石頭湯與煮青蛙
做正向的催化劑 並且記住大圖景
破窗戶理論是人們失去與熵戰鬥的意願
而煮青蛙只是沒有注意到變化
所以當你設法催生變化時， 是石頭湯呢還是青蛙湯呢
足夠好的軟體
在軟體變得完美之前，讓使用者參與進來權衡是初版還是要完美的軟體，要知道何時止步
其實今天的了不起的軟體常常比明天的完美軟體更可取
知識資產
你的知識資產也有過時的，所以要及時更新你的知識資產
所以要養成良好的習慣，定期為你的知識資產投資
嚴肅的投資者定期投資--作為習慣
多元化是長期成功的關鍵
聰明的投資者在保守的投資和高風險/高回報的投資之間平衡他們的資產
投資者應設法低買高賣，以獲取最大的回報
應周期性地重新評估和平衡資產
學習的機會多種多樣， 跟別人的交談不但建立人際關係，也可以在這個過程找到不同的解決方案
批判地分析你讀到的和聽到的
交流 針對你想說什麼 ， 並且了解你的聽眾，他們可能對什麼感興趣 ，比較好的時機，讓聽眾參與進來
你說什麼和你怎麼說同樣重要 文件美觀 做傾聽者
第二章 ：注重實效的途徑
1.重複的危害
don't repeat yourself
為什麼注釋，糟糕的**才需要注釋 make it easy to reuse
2. 正交性 即減少依賴，防止修改一處，多處需要修改
3.可撤銷性
如果某個想法是你唯一的想法，再沒有什麼比這更危險的事情了。
不存在最終決策
4.用曳光彈找到目標
5.原型與便箋
架構、已有系統中的新功能、外部資料的結構或內容、第三方工具或元件、效能問題、使用者介面設計
原型製作的價值在於所學到的經驗教訓，這才是要點
prototype to learn
架構原型中尋求結果就要求熟悉：
主要元件的責任是否得到了良好的定義
主要元件間的協作是否得到了良好的定義
耦合是否得以最小化
6.領域語言
語言的界限就是乙個人的世界的界限
靠近問題領域程式設計--即貼近終端使用者，了解術語；終端使用者也是有分類的
7.估算
估算，以避免發生意外
去問做過這件事情的人，便於成功借鑑他人的經驗
在回答估算時，時基於問題的模型，還有範圍的
檢查需求， 分析風險， 設計實現整合， 向使用者確認
第三章 基本工具
工具可以放大你的才幹
1.純文字的威力
用純文字儲存知識---人能夠閱讀 和人能夠理解的區別
2.利用命令shell的力量， 主要是把固定的操作流程轉成自動化
3.用好一種編輯器
4.總是使用原始碼控制
5.除錯
要修正問題，而不是發出指責
不要恐慌
select 沒有問題
不要假定，要證明
6.學習一種文字操縱語言
7.**生成器
第四章：注重實效的偏執
你不可能寫出完美的軟體
沒有什麼比常識和坦率更讓人驚訝
按合約設計
語義不可變，即不可違反的法則；要注意跟政策的東西混為一談，因為政策會變
死程式不說謊，我們很容易陷入「它不可能發生」的心理狀態
如果它不可能發生，用斷言確保它不會發生，而不是任由它作為確定事項不管
但是需要注意斷言也可能有***，比如遍歷集合時，item.nextelements()只能呼叫一次，
如果使用它斷言，那麼就是除錯改變了被除錯系統的行為
何時使用異常，如果有多重判斷處理異常，可以直接try catch住所有異常，統一處理
怎樣配平資源
finish what you start
巢狀分配
關閉資源必須在明顯結束的地方進行關閉，不要再呼叫的某個方法裡呼叫
關閉資源以資源分配的次序相反的次序解除資源的分配
在**的不同地方分配同一組資源時，總是以相同的次序分配他們，降低死鎖
總之就是你要確定資源得到了適當釋放進行實際檢查
第五章 彎曲，或折斷
解耦與得墨忒耳法則
好籬笆促成好鄰居
minimize coupling between modules 使模組之間得耦合減至最少
元程式設計
再多的天才也無法勝過對細節的專注
動態配置--configure,don't integrate
put abstractions in code,details in metadata
時間耦合
併發情況，
analyze workflow to improve concurrency
design using services
always design for concurrency
它只是試圖
訊息佇列之發布/訂閱--模型與模型的試圖的分離。
separate views from models
模型--表示目標物件的抽象資料模型； 模型對任何試圖或控制器都沒有直接的了解
檢視--解釋模型的方式，它訂閱模型中的變化和來自控制器的邏輯事件
控制器--控制試圖、並向模型提供新資料的途徑。它既向模型、也向試圖發布事件
黑板字跡在牆上
直接從黑板上獲取最新資訊，並且加上他們的發現
每個接受不同的訓練，他們的專業反饋到黑板上
同時需要組織你的黑板-進行分割槽，並以某種方式組織黑板上的資料
use blackboards to coordinate workflow
第六章 當你程式設計時
不主動思考他們的**的開發者是靠巧合程式設計，**也許能工作，但卻沒有特別的理由說明
他們為何能工作
開發過程要注意必須對其進行測試
對開發工具生成的大量**，要理解它們在做什麼
靠巧合程式設計
時刻牢記我們也工作在雷區裡，記住士兵的故事，我們應該警惕，不要得出錯誤的結論
我們應該避免靠巧合程式設計--依靠運氣和偶然的成功----而是要深思熟慮地程式設計
當它能工作了，最好不要畫蛇添足。我們很容易被這樣的思路愚弄，我們一定要深究為什麼
能工作了，因為 它也許只是看起來能工作，多餘的和不必要的呼叫會使你的**變慢，多餘的呼叫
還會增加引入它們自己的新bug的風險
不要假定，要證明； 因為做事情都帶著假定，但假定很少帶入文件，所以以明確的事實作為基礎
don't program by coincidence
如何深思熟慮的編碼:
1.總是意識到你在做什麼
2.不要盲目地程式設計
3.按照計畫行事
4.依靠可靠的事物
5.為你的假定建立文件
6.不要只是測試你的**，還要測試你的假定
7.為你的工作分優先順序，把事件花在重要的方面，很有可能，它們是最難的事情；因為如果你的基本原則或者
基礎設施不正確，再花哨的鈴聲和口哨也是沒有用的
8.不要做歷史的奴隸；即不要讓已有的**支配將來的**
演算法速率
檢查執行事件和記憶體需求
o(1) 常量型
o(logn) 對數型 二分查詢
o(n) 線性型(順序查詢)
o(nlgn) 快速排序、堆排序的平均執行時間
o(n²) 平方律型 （選擇和插入排序）
常用估算
簡單迴圈
巢狀迴圈
二分法分而治之
組合estimate the order of your algorithms
測試你的估算
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...