1.關(guān)心你的技藝
Care About Your Craft
如果你不在湖能否漂亮的開發(fā)出軟件，你又為何要耗費生命去開發(fā)軟件呢？
2.思考！你的工作
Think! About Your Work
關(guān)掉自動駕駛儀，接管操作。不斷地批評和評估你的工作。
3．提供各種選擇，不要找蹩腳的借口
Provide Options, Don't Make Lame Excuses
要提供各種選擇，而不是找借口。不要說事情做不到；說明能夠做什么。
4.不要容忍破窗戶
Don't Live with Broken Windows
當(dāng)你看到糟糕的設(shè)計、錯誤的決策和糟糕的代碼時，修正它們。
5.做變化的催化劑
Be a Catalyst for Change
你不能強(qiáng)迫人們改變。相反，要向他們展示未來可能會怎樣，并幫助他們參與對未來的創(chuàng)造。
6.記住大圖景
Remember the Big Picture
不要太過專注于細(xì)節(jié)，以至忘了查看你周圍正在發(fā)生什么。
7.使質(zhì)量成為需求問題
Make Quality a Requirements lssue
讓你的用戶參與確定項目真正的質(zhì)量需求。
8.定期為你的知識資產(chǎn)投資
Invest Regularly in Your Knowledge Portfolio
讓學(xué)習(xí)成為習(xí)慣。
9.批判地分析你讀到的和聽到的
Critically Analyze What You Read and Hear
不要被供應(yīng)商、媒體炒作、或教條左右。要依照你自己的看法和你的項目的情況去對信息進(jìn)行
分析。
10.你說什么和你怎么說同樣重要
It's both What You Say and the Way You Say it
如果你不能有效地向他人傳達(dá)你的了不起的想法，這些想法就毫無用處。
11.不要重復(fù)你自己
DRY - Don't Repeat Yourself
系統(tǒng)中的每一項知識都必須具有單一、無歧義、權(quán)威的表示。
12.讓復(fù)用變得容易
Make It Easy to Reuse
如果復(fù)用很容易，人們就會去復(fù)用。創(chuàng)造一個支持復(fù)用的環(huán)境。
13.消除無關(guān)事物之間的影響
Eliminate Effects Between Unrelated Things
設(shè)計自足、獨立、并具有單一、良好定義的目的的組件。
14.不存在最終決策
There Are No Final Decisions
沒有決策是澆鑄在石頭上的。相反，要把每項決策都視為是寫在沙灘上的，并為變化做好
計劃。
15.用曳光彈找到目標(biāo)
Use Tracer Bullets to Find the Target
曳光彈能通過試驗各種事物并檢查它們離目標(biāo)有多遠(yuǎn)來讓你追蹤目標(biāo)。
16.為了學(xué)習(xí)而制作原型
Prototype to Learn
原型制作是一種學(xué)習(xí)經(jīng)驗。其價值并不在于所產(chǎn)生的代碼，而在于所學(xué)到的經(jīng)驗教訓(xùn)。
17.靠近問題領(lǐng)域編程
Program Close to the Problem domain
用你的用戶的語言進(jìn)行設(shè)計和編碼。
18.估算，以避免發(fā)生意外
Estimate to Avoid Surprises
在著手之前先進(jìn)行估算。你將提前發(fā)現(xiàn)潛在的問題。
19.通過代碼對進(jìn)度表進(jìn)行迭代
Iterate the Schedule with the Code
用你在進(jìn)行實現(xiàn)時獲得的經(jīng)驗提煉項目的時間標(biāo)度。
20.用純文本保存知識
Keep Knowledge in Plain Text
純文本不會過時。它能夠幫助你有效利用你的工作。并簡化掉時和測試。
21.利用命令shell的力量
Use the Power of Command Shells
當(dāng)圖形用戶界面無能為力時使用shell。
22.用好一種編輯器
Use a Single Editor Well
編輯器應(yīng)該是你的手的延伸；確保你的編輯器是可配置、科擴(kuò)展和可編程的。
23.總是使用源碼控制
Always Use Source Code Control
源碼控制是你的工作的時間機(jī)器--你能夠回到過去。
24.要修正問題，而不是發(fā)出指責(zé)
Fix the Problem, Not the Blame
bug是你的過錯還是別人的過錯，并不是真的很有關(guān)系--它仍然是你的問題，它仍然需要
修正。
25.調(diào)試時不要恐慌
Don't Panic When Debuging
做一次深呼吸，思考什么可能是bug的原因。
26.“Select”沒有問題
"Select" Isn't Broken
在OS或編譯器、甚或是第三方產(chǎn)品或庫中很少發(fā)現(xiàn)bug。bug很可能在應(yīng)用中。
27.不要假定，要證明
Don't Assume It - Prove It
在實際環(huán)境中--使用真正的數(shù)據(jù)和辯解條件--證明你的假定。
28.學(xué)習(xí)一種文本操縱語言
Learn a Text Manipulation Language
你用每天的很大一部分時間處理文本，為什么不讓計算機(jī)替你完成部分工作呢？
29.編寫能編寫代碼的代碼
Write Code That Writes Code
代碼生成器能提高你的生產(chǎn)率，并有助于避免重復(fù)。
30.你不可能寫出完美的軟件
You Can't Write Perfect Software
軟件不可能完美。保護(hù)你的代碼和用戶，使它（他）們免于能夠預(yù)見的錯誤。
31.通過合約進(jìn)行設(shè)計
Design with Contracts
使用合約建立文檔，并檢驗代碼所做的事情正好是它聲明要做的。
32.早崩潰
Crash Early
死程序造成的危害通常比有問題的程序要小得多。
33.用斷言避免不可能發(fā)生的事情
Use Assertions to Prevent the Impossible
斷言驗證你的各種假定。在一個不確定的世界里，用斷言保護(hù)你的代碼。
34.將異常用于異常的問題
Use Exceptinos for Exceptional Problems
異常可能會遭受經(jīng)典的意大利面條式代碼的所有可讀性和可維護(hù)性問題的折磨。將異常保留給
異常的事物。
35.要有始有終
Finish What You Start
只要可能，分配某資源的例程或?qū)ο笠矐?yīng)該負(fù)責(zé)解除其分配。
36.使模塊之間的耦合減至最少
Minimize Coupling Between Modules
通過編寫“羞怯的”代碼并應(yīng)用得墨忒耳法則來避免耦合。
37.要配置，不要集成
Configure, Don't Integrate
要將應(yīng)用的各種技術(shù)選擇實現(xiàn)為配置選項，而不是通過集成或工程方法實現(xiàn)。
38.將抽象放進(jìn)代碼，細(xì)節(jié)放進(jìn)元數(shù)據(jù)
Put Abstractions in Code, Details in Metadata
為一般情況編程，將細(xì)節(jié)放在被編譯的代碼庫之外。
39.分析工作流，以改善并發(fā)性
Analyze Workflow to Imporve Concurrency
利用你的用戶的工作流中的并發(fā)性。
40.用服務(wù)進(jìn)行設(shè)計
Design Using Services
根據(jù)服務(wù)--獨立的、在良好定義、一致的接口之后的兵法對象--進(jìn)行設(shè)計。
41.總是為并發(fā)進(jìn)行設(shè)計
Always Design for Concurrency
容許并發(fā)，你將會設(shè)計出更整潔、具有更少假定的接口。
42.使視圖與模型分離
Separate Views from Models
要根據(jù)模型和視圖設(shè)計你的應(yīng)用，從而以低廉的代碼獲取靈活性。
43.用黑板協(xié)調(diào)工作流
Use Blackboards to Coordinate Workflow
用黑板協(xié)調(diào)完全不同的事實和因素，同時又使各參與方保持獨立和隔離。
44.不要靠巧合編程
Don't Program by Coincidence
只依靠可靠的事物。注意偶發(fā)的復(fù)雜性，不要把幸運的巧合與有目的的計劃混為一談。
45.估算你的算法的階
Estimate the Order of Your Algorithms
在你編寫代碼之前，先大致估算事情需要多長時間。
46.測試你的估算
Test Your Estimates
對算法的數(shù)學(xué)分析并不會告訴你每一件事情。在你的代碼的目標(biāo)環(huán)境中測定它的速度。
47.早重構(gòu)，常重構(gòu)
Refactor Early, Refactor Often
就和你會在華園里除草、并重新布置一樣，在需要時對代碼進(jìn)行重寫、重做和重新架構(gòu)。要
鏟除問題的根源。
48.為測試而設(shè)計
Design to Test
在你還沒有編寫代碼時就開始思考測試問題。
49.測試你的軟件，否則你的用戶就得測試
Test Your Software, or Your Users Will
無情地測試。不要讓你的用戶為你查找bug。
50.不要使用你不理解的向?qū)Тa
Don't Use Wizard Code You Don't Understand
想到可以生成大量代碼。在你把它們合并進(jìn)你的項目之前，確保你理解全部這些代碼。
51不要搜集需求--挖掘它們
Don't Gather Requirements - Dig for Them
需求很少存在于表面上。它們深深地埋藏在層層假定、誤解和政治手段的下面。
52.與用戶一同工作，以像用戶一樣思考
Work with a User to Think Like a User
要了解系統(tǒng)實際上將如何被使用，這是最好的方法。
53.抽象比細(xì)節(jié)活得更長久
Abstractions Live Longer than Details
“投資”于抽象，而不是實現(xiàn)。
54.使用項目詞匯表
Use a Project Glossary
創(chuàng)建并維護(hù)項目中使用的專用術(shù)語和詞匯的單一信息源。
55.不要在盒子外面思考--要找到盒子
Don't Think Outside the Box - Find the Box
在遇到不可能解決的問題時，要確定真正的約束。問問你自己：“它必須以這種方式完成嗎？
它真的必須完成嗎？”
56.等你準(zhǔn)備好再開始
Start When You're Ready
你的一生都在積累經(jīng)驗。不要忽視反復(fù)出現(xiàn)的疑惑。
57.對有些事情“做”勝于“描述”
Some Things Are Better Done than Described
不要掉進(jìn)規(guī)范的螺旋
58.不要做形式方法的奴隸
Don't Be a Slave to Formal Methods
如果你沒有把某項技術(shù)放進(jìn)你的開發(fā)時間和能力的語境中，不要盲目地采用它。
59.昂貴的工具不一定能制作出更好的設(shè)計
Costly Tools Don't Produce Better Disigns
小心供應(yīng)商的炒作，行業(yè)教條，以及價格標(biāo)簽的誘惑。要根據(jù)工具的價值判斷它們。
60.圍繞功能組織團(tuán)隊
Organize Teams Around Fucntionality
不要把設(shè)計師與編碼員分開，也不要把測試員與數(shù)據(jù)建模員分開。按照你構(gòu)建代碼的方式構(gòu)建
團(tuán)隊。
61.不要使用手工流程
Don't Use Manual Procedures
shell腳本或批文件會一次次地以同一順序執(zhí)行同樣的指令。
62.早測試，常測試，自動測試。
Test Early. Test Often. Test Automatically
與呆在書架上的測試計劃相比，每次構(gòu)建試運行的測試要有效得多。
63.要到通過全部測試，編碼才算完成。
Coding Ain't Done 'Til All the Tests Run
就是這樣。
64.通過“蓄意破壞”測試你的測試。
Use Saboteurs to Test Your Testing
在單獨的軟件副本上故意引入bug，以檢驗測試能夠抓住它們。
65.測試狀態(tài)覆蓋，而不是代碼覆蓋
Test State Coverage, Not Code Coverage
確定并測試重要的程序狀態(tài)。只是測試代碼行是不夠的。
66.一個bug只抓一次
Find Bugs Once
一旦測試員找到一個bug，這應(yīng)該是測試員最后一次找到它。此后自動測試應(yīng)該對其進(jìn)行
檢查。
67.英語就是一種編程語言
English is Just a Programming Language
像你編寫代碼一樣編寫文檔：遵守DRY原則、使用元數(shù)據(jù)、MVC、自動生成、等等。
68.把文檔建在里面，不要栓在外面
Build Documentation In, Don't Bolt It On
與代碼分離的文檔不太可能被修正和更新。
69.溫和地超出用戶的期望
Gently Exceed Your Users' Expectations
要理解你的用戶的期望，然后給他們的東西要多那么一點。
70.在你的作品上簽名
Sign Your Work
過去時代的手藝人為能在他們作品上簽名而自豪。你也應(yīng)該如此。
檢查清單
---------------------------
71.要學(xué)習(xí)的語言
厭倦了C、C++和JAVA？試試CLOS、Dylan、Eiffel、Objectve C、Prolog、Smailltalk或TOM。它們每一種都有不同的能力和不同的“風(fēng)味”。用其中的一種或多種語言在家里開發(fā)一個小項目。
72.WISDOM離合詩
What do you want them to learn? 你想讓他們學(xué)到什么？
What is their interest in what you've got to say? 他們對你講的什么感興趣？
How sophisticated are they? 他們有多富有經(jīng)驗？
How much detail do they want? 他們想要多少細(xì)節(jié)？
Whom do you want to own the information? 你想要讓誰擁有這些信息？
How can you motivate them to listen to you? 你如何促使他們聽你說話？
73.怎樣維持正交性
·設(shè)計獨立、良好定義的組件。
·使你的代碼保持解耦。
·避免使用全局?jǐn)?shù)據(jù)。
·重構(gòu)相似的函數(shù)。
74.應(yīng)制作原型的事物
·架構(gòu)
·已有系統(tǒng)中的新功能
·外部數(shù)據(jù)的結(jié)構(gòu)或內(nèi)容
·第三方工具或組件
·性能問題
·用戶界面設(shè)計
75.架構(gòu)問題
·責(zé)任是否得到了良好定義？
·寫作是否得到了良好定義？
·耦合是否得以最小化？
·你能否確定潛在的重復(fù)？
·接口定義和各項約束是否可接受？
·模塊能否在需要時訪問所需數(shù)據(jù)？
76.調(diào)試檢查清單
·正在報告的問題是底層bug的直接結(jié)果，還是只是癥狀？
·bug真的在編譯器里？在OS里？或者是在你的代碼里？
·如果你向同事詳細(xì)解釋這個問題，你會說什么？
·如果可疑代碼通過了單元測試，測試是否足夠完整？如果你用該數(shù)據(jù)運行單元測試，會發(fā)生什么？
·造成這個bug的條件是否存在于系統(tǒng)中的其它任何地方？
77.函數(shù)的得墨忒耳法則
某個對象的方法應(yīng)該只調(diào)用屬于以下情況的方法：
·它自身
·傳入的任何參數(shù)
·它創(chuàng)建的對象
·組件對象
78.怎樣深思熟慮地編程
·總是意識到你在做什么。
·不要盲目地編程。
·按照計劃行事。
·依靠可靠的事物。
·為你的假定建立文檔。
·不要只是測試你的代碼，還要測試你的假定。
·維尼的工作劃分優(yōu)先級。
·不要做歷史的奴隸。
79.何時進(jìn)行重構(gòu)
·你發(fā)現(xiàn)了對DRY原則的違反。
·你發(fā)現(xiàn)事物可以更為正交。
·你的知識擴(kuò)展了。
·需求演變了。
·你需要改善性能。
80.劈開戈爾迪斯結(jié)
在解決不可能解決的問題時，問問你自己：
·有更容易的方法嗎？
·我是在解決正確的問題嗎？
·這件事情為什么是一個問題？
·是什么使它如此難以解決？
·它必須以這種方式完成嗎？
·它真的必須完成嗎？
81.測試的各個方面
·單元測試
·集成測試
·炎癥和校驗
·資源耗盡、錯誤及恢復(fù)
·性能測試
·可用性測試
·對測試自身進(jìn)行測試
以上內(nèi)容摘自《程序員修煉之道》