這本書裏包含了很多的看似粗淺樸素的道理，實則是若干經驗的心血總結。
比如誰都知道不要對自己家的破窗戶置之不理，可實際中聽到太多的妥協：這個代碼已經這樣了，只能繼續在上面貼上醜陋的workaround，這其實是一種對責任的推卸和對未來的不負責，當然現實不是完美的，有時救火隊員也不得不放下破窗戶而遷就其他，但最爲一個pragmatic程序員，保持追求完美的心態還是很有必要的，正因爲這個心態，我們纔會去追求代碼的優美、設計/實現的正交、DRY(Dont' Repeat Yourself)原則...
我們看到太多重複造輪子的故事。
正如書中提到“鞋匠的孩子沒鞋穿”，作爲一個pragmatic程序員，合理地使用工具/庫/以及自己積累的開發的輪子，會讓自己的productivity不斷提升。這讓我想起公司裏一個讓人崇拜的“牛”，產品一直想把進程內cache做成多進程共享，正在大家還在討論該怎麼做的時候，“牛”已經用短短几天時間完成了，衆人再次崇拜一把，原來“牛”是備有很多現成代碼的，完成這個功能只是把之前積累的封裝良好的模塊重用就可以了。
記得四年前剛開始工作時從公司拿到的第一本書，就是這本《程序員修煉之道》(英文版)，作爲新入職員工study group的學習材料，當時在senior engineer帶領下和其他同事一起學習了這本書。雖然之前就聽說這是一本好書，但當時看的時候只是覺得，講的都有道理，但這些是很自然的阿，幹嗎花這麼大的篇幅說來說去？所以只是囫圇吞棗地翻過也就扔在一邊了。
之後也看過很多類似的書籍，《修煉之道》也一直是公司新人的必備學習材料，而我卻一直再沒重拾這本書仔細通讀一遍，直到最近周筠老師發給我中文電子版，我才又從書架上翻出當年的英文版，對照着中文電子版仔細通讀了一遍。
此次重讀，感受頗多，也頗能理解爲何公司一直選用此書作爲新人教材。
另外一個書中推崇的方法：曳光彈，自己之前用prototype，但一直猶豫於代碼是否需要重用，原則上prototype的代碼是應該拋棄型的，但在有時候前期做的一些工作其實是爲了確定方案、構建框架，而這些其實是會作爲後起工作的基礎的。事實上在項目先期是值得仔細考慮究竟該採用prototype還是曳光彈，它們的適用場景會有所不同（對於產品開發，曳光彈的應用場景可能相對會更多一些）
當然，至於書中提到的對知識資產的管理（知識投資）、溝通和交流的重要性等等，我想這就不單單對於程序員適用了，任何一個人要想有所作爲的，這些方面的重要性都毋庸多說了。而對於自動化和文本處理等方面的經驗，也是在很多書中都提到的經驗之談（Unix編程藝術、卓有成效的程序員...）
最後，說一下這本書的翻譯，譯者馬維達，最早是在學校時讀過他翻譯的ACE文檔及相關資料，收益頗多，ACE可謂網絡編程技術的集大成者，而這本《修煉之道》則可謂編程的集大成者，從項目管理、軟件架構和設計、代碼編寫和測試，各方面在此書中都有精到的闡述。此書的翻譯質量應該說很是準確，基本很實在真實地表達了原書的意思，但正因直譯，可能有些語句理解上會有一點難度（比如P146, "只要對於那些被耦合在一起的模塊而言，這是衆所周知的和可以接受的，你的設計就沒有問題。"），但細讀這本書，這些有所晦澀的內容還是能理解的，當然一點建議是作者可以適當加些“譯註”，這樣會讓理解更容易和順暢（比如書中直接用古魯來翻譯Guru，如果能加些解釋可能會更好，又比如Law of Demeter，原書沒有解釋得太清楚，如果能多加些解釋可能會更便於理解）
感謝周筠老師讓我有機會重溫這本優秀的書籍，爲了完成作業，也爲了讓自己認識提升。
其他的一些感悟：
正交性（高內斂，最後達到兩個模塊之間互補影響）
曳光彈或是原型（輕量級引導程序，直達目標，方便調整）
斷言式編程，異常使用（暴露程序的問題，不要隱藏他）
解耦與墨忒爾法則（低耦合，減少依賴）
算法數率與重構（更優質的代碼）
無處不在的自動化（減少重複代碼，和無意義的代碼，不僅會讓編程更有趣，而且會減少錯誤）
這些算是比較高級的技巧了。對於初學變成的人其實不太友好。過多的限定總是會讓新手止步不前。
不過《程序員修煉之道》還提到了幾條對於任何階段的程序員都應該遵循的法則
1.你的知識資產
你應該一直投資知識資產，這是你成長的根本
包括但不限與，定期讀書，定期學習新的語言，嘗試新的工具
2.破窗原則
任何時候你都應該使用你當時最高水品的技術去完成一個項目，如果你發現又不好的設計或實現應該修正它。就算時間不夠你至少應該打上一個補丁，以警告和提示開發人員這個地方需要修補。
3.打上你的標籤
不再懷有僥倖，在你負責和修改的地方打上標籤。迫使自己編寫更高水平的代碼。
我的源碼讓貓吃了
對於工作勇於負責，正確評估自己的負責範圍，別找一些蹩腳的藉口。
Provide Options,Don't Make Lame Excuses.選擇各種選擇，不要找蹩腳的接口。
軟件的熵
軟件無序增長被稱爲“軟件腐爛”(Software rot)
對於軟件中錯誤應該及時修復，千萬別把軟件弄“髒”了，否則軟件將迅速惡化。
Don't Live with Broken Windows.不要容忍破窗戶
石頭湯與煮青蛙
讓他們瞥見未來，你就能讓他們聚在你周圍。
Be a Catalyst for Change.做變化催化劑
很多軟件災難都是從小事開始，以至於積少成多，影響了團隊。
Remember the Big Picture.記住大圖景
足夠好的軟件
所有系統都必須滿足其用戶的需求，才能獲得成功。讓用戶參與到你的工作吧，讓他們去權衡。但是過度修飾和過於求精，而損壞完好的程序就有點畫蛇添足了。
Make Quality a Requirements lssue.使質量成爲需求問題
你的知識資產(Knowledge Portfolios)
知識是有時效的資產（expiring asset）
經營知識資產：定期投資、多元化、管理風險、低買高賣、重新評估和平衡
Invest Regularly in Your Knowledge Portfolios.定期爲你的知識資產投資
每年至少學一種新語言，每個月至少閱讀一本書，閱讀非技術書籍，上課，參加本地用戶組織，試驗不同的環境，跟上潮流，上網。
學習時，也要進行批判的思考。咕嚕們和互聯網不一定時最權威的。
Critically Analyze What You Read and Hear.批判分析你讀到的和聽到的。
交流（Communcation）
在說話前要做到以下準備：
1.知道要說什麼
2.知道要對誰說
3.選擇什麼時候說
4.說話的風格(簡報；論述；幽默；嚴肅)要讓文檔看起來漂亮說話是一個互動行爲(Not noly Speaker but alse Listener)禮貌回覆一切別人向你提出的問題。
It's Both What You Say and the Way You Say it.你說什麼和你怎麼做一樣重要
重複的危害
DRY原則（Don't reapeat youorself）：系統中的每一項知識都必須具有單一，無歧義，權威的表示
四種重複：
加強的重複（impsed duplication）：環境似乎要求重複（信息多種表示，註釋，文檔與代碼，語言問題）
無意的重複（inadvertent duplication）：沒有意識到信息的重複
無耐性的重複（impatient duplication）：開發者偷懶，似乎那樣更容易
開發者之間的重複（interdeveloper duplication）：大家重複同樣的東西
複用是解決重複一個最好的方法
Make it easy to Rease.讓複用變得容易
正交性
如果兩個或多事物中的一個發生變化，不會影響其他事物，這些事物就是正交的。
Eliminate Effect Between Unrelated Things.消除無關事物之間的影響。
自足（self－contained）的組件：獨立，具有單一，良好定義的目的。
正交的好處：提高生產效率，降低風險。
經常問問自己：如果我顯著地改變某個特定功能背後地需求，有多少模塊會受影響。
編碼：讓代碼保持解耦，避免使用全局數據；避免編寫相似地函數
可撤銷性
如果某個想法是你的唯一的想法，在沒有什麼比這更危險的事情了。
一個靈活的框架隨時適應變化的需求。
“薛定諤的貓”——任何結果都是可能的。
需求隨時在變，而軟件就變不起了，如果連軟件框架都變來變去，那軟件一定會失敗。
曳光彈
做軟件的時候可以時不時地拋出一個曳光彈，看看打中目標沒有。
Use Tracer Bullets to find the Target.用曳光彈找到目標。
曳光彈代碼並非用過就扔的代碼，你編寫它是爲了保留它。
曳光彈代碼有點：
用戶能夠及早看到能工作的東西；
開發者構建了一個他們能在其中工作的結構；
有一個集成的平臺；
有了可用於演示的東西；
能感覺到工作的進展；
原型製作生成用過就扔的代碼；曳光彈雖然簡約，但卻是完整的，最終構成系統骨架一部分。
原型與便箋
爲工作流和應用邏輯等動態事物製作原理，便箋是一個很好的選擇。
應制作原型的事物：
1.架構；2.已有系統中的新功能；3.外部數據的結構或內容；4.第三方工具或組件；5.性能問題；6.用戶界面；
怎樣使用原型：
在製作原型時可忽略的細節：正確性，完整性，健壯性，風格；
用一些“膠合劑”把組件粘起來
用便箋、索引卡片在白板上將系統建模；
原型嘛，又不是曳光代碼，用完就扔了它。
領域語言
語言的界限就是一個人的世界的界限；
用業務的語言去描述業務問題，而不用編程語言，這樣就不會鑽牛角尖。
舉個例子：在一組X.25線路上偵聽由ABC規則12.3定義的交易，把它們轉譯成XYZ公司的43B格式，在衛星上行鏈路上重新傳輸，並存儲起來，供
分析使用將來。
剪裁後的小語言：
From X25Line1 (Format=ABC123){
Put TELSTAR1 (Format=XYZ43B);
Store DB;
}
用戶又添加一個需求：不應存儲餘額爲負的交易，而應以原來的格式在X.25線路上發送回去：
From X25Line1 (Format=ABC123){
if (ABC123.balance<0){
Put X25Line1 (Format=XYZ43B);
}
else{
Put TELSTAR1 (Format=XYZ43B);
Store DB;
}
}
Program Close to the Problem domian（靠近問題領域編程）
使用小型語言擴展現有語言
估算
Estimate to avoid surprise（估算，以避免發生意外）
130工作日和6個月，哪個顯得更精確呢？
估算來自：
理解提問內容，注意問題域的範圍；
建立系統的模型；
把模型分解爲組件；
給每個參數制定值；
計算答案；
追蹤估算能力；
Iterate the Schedule with the Code.（通過代碼對進度表進行迭代）
讓工具變爲雙手的延伸
純文本的威力
Keep knowledge in Plain Text.用純文本保存知識。
文本的威力：不過時；槓桿作用（每一樣工具都可以工作在純文本上）；更易於測試；
純文本是永遠的公共通信標準。
Shell遊戲
別受限於GUI界面，回到文本操作吧，讓Shell成爲你的朋友。
Use the Power of Command Shells.利用命令Shell的力量。
Cygwin，UWIN是Windows下的Unix Shell工具實現。
強力編輯
Use s Single Editor Well.用好一種編輯器。
編輯器特性：可配置，可擴展，可編程；
Emacs是一個很好的編輯器，Vi也是，EditPlus也是。
源碼控制
進步遠非遊變化組成，而是取決於好記性。不能記住過去的人，被判重複過去。
源碼控制系統（SCCS）是一個長效的Undo功能。我們可以在主幹上開發，也可以生成一些完整的分支提供給客戶。如果分支情況良好，可以考
慮將分支和主支合併。
Always Use Source Code Control.總是使用源碼控制。
無論怎麼樣，只要你在計算機上工作就要使用它。
VSS,CVS,PCVS,SVN都是很不錯的版本控制系統，還有就是ClearCase.
調試
調試的目的：解決問題
Fix the Problem,Not the Blame.修正問題而不是指責。
面對Bug千萬不要恐慌或者認爲那是不可能的，既然發生了就要積極面對它。
如何暴露Bug:
1.最好可以和報告Bug的人面談一下，這樣可以蒐集更多的數據；
2.人工合成測試不能足夠地演練應用，必須設計測試邊界條件同時實現在現實中用戶地使用模式；
測試策略
別讓Bug離你太遠，否則會捉不到它地。
1.使數據可視化：Variable name = data value.(直觀地數據表達方式)
2.跟蹤：
a.把小診斷消息打印到屏幕上或者文件中，例如什麼printf或者System.out.println之類的；
b.棧的蹤跡(Stack trace)。
3.橡皮鴨：對着別人解釋你的代碼，說着說着Bug就出來了；
4.消除過程：找問題先找自己的問題，再找別人的問題；再提交Bug報告前，必須先消除你代碼中的Bug.
造成驚訝的要素：發生了，就認了把，然後努力去解決它。
Don't Assume it-Prove it.不要假定，要證明。
以後就別在說：“ Oh，My god”了。
文本操縱
Learn a Text Mainpulation Language.學習一種文本操縱語言。
用途列舉：數據庫維護，屬性訪問，測試數據生成，寫書，接口，生成文檔……
代碼生成器
Write Code that Writes Code.編寫能編寫代碼的代碼。
被動代碼生成器：只運行一次來生成結果
1.創建新的源文件；
2.在變成語言只間進行一次轉換；
3.生成查詢表及其他運行時很昂貴的資源；
主動代碼生成器：在每次需要其結果時被使用
取某項知識的一種表示形式，將其轉換未你的應用需要的所有形式，說白了就是格式轉換。
世界上沒有完美的代碼，也沒有完美的程序員。只有防衛性地編碼和注重實效地程序員。
按合約設計（DBC）
Design with Contracts.通過合約進行設計
用合約的方法幫助軟件模塊進行交互；
程序做它生命要做的事情，用文檔記載這樣的聲明，並進行校驗；
例程對世界狀態的期望：
前條件（precondition）：調用例程必須的條件；
後條件（postcondition）：例程完成後世界的狀態；
類不變項（class invariant）：類確保從調用者角度看，條件總爲真；
Liskov替換原則：子類必須要能通過基類的接口，而使用者無須知道其區別；
實現DBC：斷言與語言支持（Java：iContract）
不變項的用法：1.循環不變項；2.語義不變項
死程序不說謊
Crash Early.早崩潰
有時候寧願要程序崩潰，也千萬不要讓它把壞數據寫入；
檢查每一個可能的錯誤——特別是意料之外的錯誤——是一種良好的實踐；
斷言式編程
If It Can’t Happen,Use Assertions to Ensure That Won’t.
如果它不可能發生，用斷言確保它不會發生
不能用斷言代替真正的錯誤處理
Java斷言類實現
import java.lang.System;
import java.lang.Thread;
public class Assert{
public static void TEST(Boolean conition){
if(!conition){
System.out.println(“Assertion Failed”);
Thread.dumpStack();
System.exit(1);
}
}
}
如何使用異常
Use Exceptions for Exceptional Problems.將異常用於異常問題
對於出錯或可能出錯的地方儘量使用異常拋出，if來if去多麻煩。
怎麼配平資源
Finish What You Start.要有始有終
記得釋放你的資源，否則世界會因爲你佔有太多資源不堪重負，最終崩潰；
嵌套分配
1． 以與資源分配的次序相反的次序解除資源的分配；
2． 在代碼的不同地方分配同一組資源時，總是以相同的次序分配它們；
無論是誰分配的資源，它都應該負責解除該資源的分配；
在Java開發中使用完某個對象都，將其設爲NULL，這可以使垃圾回收器將它自動回收。
解耦與得墨忒耳法則
好籬笆促成好鄰居
對象間直接得橫貫關係有可能很快帶來依賴關係得組合爆炸：如果n個對象相互瞭解，那麼對一個對象得改動就可能導致其他n-1個對象都需要改動。
函數的得墨忒耳法則
儘可能遵守得墨忒耳法則的“羞澀”代碼
Minimize Coupling Between Modules.
使模塊間耦合減至最少
元程序設計
再多天才也無法勝過對細節專注；
動態配置：對於算法、界面之類，應該使用配置選項，而不是通過集成或工程實現；
Configure，Don’t Integrate.要配置，不要集成
元數據驅動的應用
Put Abstractions in Code, Details in Metadata.將抽象放進代碼，細節放進元數據
在一個複雜工作流系統中，你將通過編寫規則，而不是修改代碼來配置它。
時間耦合
Analyze Workflow to Improve Concurrency.分析工作流，以改善併發行
在多個消費者進程間進行快速而粗糙的負載平衡的一種途徑：飢餓的消費者（hungry consumer）模型
Design Using Services.用服務進行設計
在併發設計時應該注意公共變量，對其加以保護。同時也要保證線程安全
Always Design for Concurrency.總是爲併發進行設計
它只是視圖
模塊具有單一的，定義良好的責任
模塊間不需要互相知道太多
一件事件就是一條特殊消息
發佈/訂閱：Subscriber只對感興趣的話題向Publisher進行訂閱，而Publisher負責監聽並分發消息。
MVC架構：
模型：表示目標對象的抽象數據模型。模型對任何視圖或控制器沒有直接的瞭解；
視圖：解釋模型的方式。它訂閱模型中的變化和來自控制器的邏輯事件；
控制器：控制視圖，並向模型提供新數據的途徑。它既向模型，也向視圖發佈時間；
黑板
黑板系統讓我們完全解除了我們的對象之間的耦合，並提供一個“論壇”，只是消費者和生產者都可以在那裏匿名、異步地交換數據；
對黑板進行分區並組織上面資料以防止組合爆炸；
黑板方式地編程消除了太多接口需要，從而能帶來更優雅、更一致地系統
Use Blackboards to Coordinate Workflow.用黑板協調工作流
編程不是機械工具
靠巧合編程
避免靠巧合編程，不要依靠運氣和偶然地成功，而要深思熟慮地編程；
巧合編程：實現地偶然；語境地偶然；隱含地假定；
Don’t Program by Coincidence.不要靠巧合編程
深思熟慮地編程
1． 總是意識到自己在做什麼
2． 不要盲目地編程
3． 按照計劃行事，不管計劃寫在哪裏
4． 依靠可靠地事務
5． 爲你地假定建立文檔
6． 不要只是測試你的代碼，還要測試你的假定
7． 爲你的工作劃分優先級
8． 不要讓已有地代碼支配將來的代碼
算法的效率
推薦：Sedgewick關於算法的書
常識估算：
簡單循環O（n）；嵌套循環O（n*n）;二分法O（nlgn）；組合：效率失控
Estimate the Order of Your Algorithms.估算你的算法的階
Test Your Estimate.測試你的估算
重構
重寫、重做和重新架構代碼合起來，成爲重構（refactoring）
應該重構代碼的條件：
1． 重複，違反DRY原則
2． 非正交設計
3． 過時的知識
4． 性能不好
Refactor Early,Refactor Often.早重構，常重構
如何進行重構：
1． 不要試圖在重構的同時增加功能；
2． 在開始重構之前，確保你擁有良好的測試；
3． 採取短小，深思熟慮的步驟
易於測試的代碼
單元測試是對模塊進行演練的代碼，也是針對合約的測試
Design to Test.爲測試而設計
測試驅動法：先測試代碼，再進行模塊測試
Print法——>即興測試
Test Your Software,Or Your Users Will.測試你的軟件，否則你的用戶就得測試
邪惡的嚮導
慎用設計嚮導，否則那些自動生成的代碼會讓你崩潰
Don’t Use Wizard Code You Don’t UnderStand.不要使用你不理解的嚮導代碼
需求之坑
Don’t Gather Requirements—Dig for them.不要蒐集需求——挖掘它們
挖掘需求
需求是對需要完成的某件事的陳述
“我能否在你們工作時在這裏呆上一週”——注意不要妨礙別人工作
Work with a User to Think Like a User.與用戶一同工作，以像用戶一樣思考
建立需求文檔
將挖掘出來的需求建立需求文檔；
看待用例的一種方式是強調其目標驅動；
把形式化的模板用作備忘錄；
規定過度
製作需求文檔時的一大危險是太具體；
需求不是架構，需求不是設計，也不是用戶界面，需求是需要；
看遠些
Abstractions Live Longer than Details.抽象比細節活得更長久
再摸一層薄薄的薄荷
許多項目的失敗都被歸咎於項目範圍的增大——也稱爲特性膨脹，蔓延特性論或需求蔓延
維護詞彙表
對用戶和領域專家的屬於進行有條例地記錄並隨時維護
Use a Project Glossary.使用項目詞彙表
把話說出來，放在Web上，大家一起看。
解開不可能解開的謎題
自由度
Don’t Think Outside the Box—Find the Box.不要在盒子外面思考——要找到盒子
對於各種約束和條件邊界，應該從更高角度看，忽略一些不適用的約束，並確定你確實擁有自由度。
一定有更容易的方法
對於“不能解決的問題”經常問問自己：
1． 它真的必須完成嗎？
2． 它必須以這種方式完成嗎？
3． 是什麼使它如此難以解決？
4． 這件事爲什麼是一個問題？
5． 你是在設法解決真的的問題，還是被外圍的技術問題轉移了注意力？
6． 有更容易的方法嗎？
等你準備好了
Listen to Nagging Doubts—Start When You’re Ready.傾聽反覆出現的疑慮——等你準備好再開始
是良好的判斷，還是拖延？
對於無法判斷項目是否拖延，可採取一種行之有效的技術構建原型，而對於有困難的地方，可進行“概念驗證”(proof of concept)
最可怕的事情：花了幾周認真開發，卻發現原來只要一個原型。
規範陷阱
注：這裏的規範通常就是我們平常說的設計
程序規範就是把需求規約到程序員能夠接管的程度；規範也是與用戶的約定，一份隱含的合約。
Some Things Are Better Done than Described.對有些事情“做”勝於“描述”
應把需求挖掘、設計以及實現視爲同一個過程，而不要信任：需求分析、編寫規則、編碼是獨立的分開進行的。因爲這些步驟本身就是無縫的。
太細的規範可能會演變爲“分析癱瘓”(analysis paralysis)
圓圈與箭頭
盲目採用任何形式方法，其結果往往令人失望
形式方法缺點：
1． 大多數形式方法結合圖和文字說明，但用戶通常喜歡原型
2． 形式方法鼓勵專門化，大家更希望瞭解整個系統，而不是冰山一角
3． 元數據讓我們運行時改變應用特徵，而大多數形式方法鼓勵你在對象間建立靜態關係
Don’t Be a Slave to Formal Methods.不要做形式方法的奴隸
批判地看待方法學而從中提取精華，融合到每項工作中。
Expensive Tools Do Not Produce Better Designs.昂貴地工具不一定能製作出更好地設計。
注重實效的團隊
不要留破窗戶——對軟件質量負責，要及時修復缺陷和錯誤，可以考慮配置一個“質量官員”；
煮青蛙——確保每個人都主動監視環境變化，要不要設置一個“首席水情檢測官”呢？
交流——沉默寡言的團隊是最糟糕的團隊，導致文檔、設計、編碼……一切工作的混亂；
不要重複你自己——還是要團隊內的交流（項目資料管理員）；
正交性——項目活動不會孤立發生，Organize Around Functionality Not Job Functions.圍繞功能，而不是工作職務進行組織；
自動化——確保一致和準確的方式是使團隊所做每件事情自動化；
給團隊每個成員足夠空間，支持他們，讓他們在項目中以自己的方式閃亮。
無處不在的自動化
我們需要保證項目的一致性和可重複性，而人工流程不能保證一致性，也無法保證可重複性，因此我們應該儘可能的使用自動化。
一切都要自動化
Don’t Use Manual Procedures.不要使用手工流程
通過一些自動化工具，如cron等，使任務（例如備份、夜間構建等）在無人照管的情況下自動地、週期地運行。
讓如makefile進行如項目編譯、生成代碼、迴歸測試、信息生成（包括Web信息）以及最終的構建等，此類工具還有Ant
構建自動化：在晚上進行完整構建，運行所有測試
自動化管理：包括了資料與網站自動生成，一些工作流程自動化等；
推薦書目《項目自動化之道-如何建構、部署》
無情的測試
Test Early,Test Often,Test Automatically.早測試，常測試，自動測試
測試如捕魚，捕什麼魚用什麼測試
好的項目擁有測試代碼可能比產品代碼還要多
Coding Ain’t Done ‘Til All the Test Run.要到通過全部測試，編碼纔算完成
測試種類：
1． 單元測試：對某個模塊進行演練的代碼
2． 集成測試：組成項目的主要子系統能工作，並很好協同
3． 驗證和校驗：滿足客戶需要嗎？
4． 資源耗盡、錯誤和恢復
5． 性能測試、壓力測試和負載測試
6． 由真實用戶在真實環境條件下進行可用性測試
測試方法：
1． 迴歸測試：測試輸出的對比
2． 測試數據：大量的、強調邊界條件的、展現特徵統計屬性的數據
3． 演練GUI系統
4． 對策是進行測試：Use Saboteurs To Test Yout Testing.通過“蓄意破壞”測試你的測試。（故意引發一些測試）
5． 徹底測試：覆蓋分析（Coverage Analysis）Test State Coverage,Not Code Coverage.測試狀態覆蓋，而不是代碼覆蓋
6． 測試時間：當項目開始後，隨時測試，千萬不要流到最後一分鐘
Find Bugs Once.一個Bug只抓一次.
全都是寫
文檔和代碼時同一底層模型的不同視圖，不要讓文檔變成二等公民
將文檔與代碼進行結合，使用如JavaDoc之類的工具自動產生文檔
Treat English(Chinese) as Just Author Programming Language.把英語（中文）當作又一種編程語言
Build Documentation In, Don’t Bolt It On.把文檔建在裏面，不要拴在外面.
匈牙利表示法：把變量類型信息放在變量名自身裏.
不應出現源碼註釋：
1． 文件種的代碼導出的函數列表
2． 修訂歷史
3． 該文件使用其他文件列表
4． 文件名
可執行文檔：例如數據庫Schhema或帶有標記的純文本
DocBook是一種機遇SGML的標記語言
極大的期望
項目的成功是由它在多大程度上滿足了用戶的期望來衡量
Gently Exceed Your Users’ Expectations.
溫和地超出用戶的期望
管理期望（managing expectations）：主動控制用戶對他們能從系統中得到什麼應該抱有的希望.
如果你和用戶緊密協作，分享他們的期望，並同他們交流你正在做的事情，那麼當項目交付時，就不會發生多少讓人喫驚的事情了.
傲慢與偏見
Sign Your Work.在你的作品簽名
尊重別人的代碼，對自己的代碼負責，使自己的簽名變成質量的保證。爲自己的代碼負責，告訴別人“這就是我的代碼”。
其他的好書推薦：
推薦書籍目錄如下，後續蛤蟆會陸續增加到本篇當中
1、《程序員修煉之道》
2、《重構》
3、 《設計模式》
4、《測試驅動發開》
5、《UNIX編程藝術》
6、《算法導論》
7、《計算機程序設計藝術》
8、《數據結構》 叫這個數目的書很多，推薦作者是：Ellis Horowitz, Sartaj Sahni, Susan Anderson-Freed
9、《代碼大全》