今天讀完了《程序員修煉之道——從小工到專家》（《The Pragmatic Programmer》），深深的覺得這種經典的書籍是值得我們反復去閱讀的，可能每讀一遍都會有新的收獲。真的覺得這個中文譯名很low，以后還是要鍛煉自己讀英文原版的能力。
今天先記錄一下書中提到的一些tips，總共有70個。其實書里有快速參考指南，但是還是想記錄一下，加深一下印象，也方便以后加一些自己對這些tips的理解吧。
- Care About Your Craft
關心你的技藝
如果你不在乎能否漂亮地開發出軟件，你又為何要耗費生命去開發軟件呢？
- Think! About Your Work
思考！你的工作
關掉自動駕駛儀，接管操作。不斷地批評和評估你的工作。
- Provide Options, Don't Make Lame Excuses
提供各種選擇，不要找蹩腳的借口
要提供各種選擇，而不是找借口。不要說事情做不到；說明能夠做到什么。
- Don't Live with Broken Windows
不要容忍破窗戶
當你看到糟糕的設計、錯誤的決策和糟糕的代碼時，修正它們。
- Be a Catalyst for Change
做變化的催化劑
你不能強迫人們改變。相反，要向他們展示未來可能會怎樣，并幫助他們參與對未來的創造。
- Remember the Big Picture
記住大圖景
不要太過專注于細節，以致忘了查看你周圍正在發生什么。
- Make Quality a Requirements Issue
使質量成為需要問題
讓你的用戶參與確定項目真正的質量需求。
- Invest Regularly in Your Knowledge Portfolio
定期為你的知識資產投資
讓學習成為習慣。
- Critically Analyze What You Read and Hear
批判的分析你讀到的和聽到的
不要被供應商、媒體炒作、或教條左右。要依照你自己的看法和你的項目的情況去對信息進行分析。
- It's Both What You Say and the Way You Say It
你說什么和你怎么說同樣重要
如果你不能有效地向他人傳達你的了不起的想法，這些想法就毫無用處。
- DRY - Don't Repeat Yourself
不要重復你自己
系統中的每一項知識都必須具有單一、無歧義、權威的表示。
- Make It Easy to Reuse
讓復用變得容易
如果復用很容易，人們就會去復用。創造一個支持復用的環境。
- Eliminate Effects Between Unrelated Things
消除無關事物之間的影響
設計自足、獨立、并具有單一、良好定義的目的的組件。
- There Are No Final Decisions
不存在最終決策
沒有決策時澆鑄在石頭上的。相反，要把每項決策都視為是寫在沙灘上的，并為變化做好計劃。
- Use Tracer Bullets to Find the Target
用曳光彈找到目標
曳光彈能通過試驗各種事物并檢查它們離目標有多遠來讓你追蹤目標。
- Prototype to Learn
為了學習而制作原型
原型制作是一種學習經驗。其價值并不在于所產生的代碼，而在于所學到的經驗教訓。
- Program Close to the Problem Domain
靠近問題領域編程
用你的用戶的語言進行設計和編碼。
- Estimate to Avoid Surprises
估算，以避免發生意外
在著手之前先進行估算。你將提前發現潛在的問題。
- Iterate the Schedule with the Code
通過代碼對進度表進行迭代
用你在進行實現時獲得的經驗提煉項目的時間標度。
- Keep Knowledge in Plain Text
用純文本保存知識
純文本不會過時。它能夠幫助你有效利用你的工作，并簡化調試和測試。
- Use the Power of Command Shells
利用命令shell的力量
當圖形用戶界面無能為力時使用shell。
- Use a Single Editor Well
用好一種編輯器
編輯器應該是你的手的延伸；確保你的編輯器是可配置、可擴展和可編程的。
- Always Use Source Code Control
總是使用源碼控制
源碼控制是你的工作的時間機器——你能夠回到過去。
- Fix the Problem, Not the Blame
要修正問題，而不是發出指責
bug是你的過錯還是別人的過錯，并不是真的很有關系——它仍然是你的問題，它仍然需要修正。
- Don't Panic When Debugging
不要恐慌
做一次深呼吸，思考什么可能是bug的原因。
- "Select" Isn't Broken
“Select”沒有問題
在OS或編譯器、甚或是第三方產品或庫中很少發現bug。bug很可能在應用中。
- Don't Assume It - Prove It
不要假定，要證明
在實際環境中——使用真正的數據和邊界條件——證明你的假定。
- Learn a Text Manipulation Language
學習一種文本操縱語言
你用每天的很大一部分時間處理文本，為什么不讓計算機替你完成部分工作呢？
- Write Code That Writes Code
編寫能編寫代碼的代碼
代碼生成器能提高你的生產率，并有助于避免重復。
- You Can't Write Perfect Software
你不可能寫出完美的軟件
軟件不可能完美。保護你的代碼和用戶，使它（他）們免于能夠預見的錯誤。
- Design with Contracts
通過合約進行設計
使用合約建立文檔，并檢查代碼所做的事情正好是它聲明要做的。
- Crash Early
早崩潰
死程序造成的危害通常比有問題的程序要小得多。
- Use Assertions to Prevent the Impossible
用斷言避免不可能發生的事情
斷言驗證你的各種假定。在一個不確定的世界里，用斷言保護你的代碼。
- Use Exceptions for Exceptional Problems
將異常用于異常的問題
異?？赡軙馐芙浀涞囊獯罄鏃l式代碼的所有可讀性和可維護性問題的折磨。將異常保留給異常的事物。
- 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
用黑板協調工作流
用黑板協調完全不同的事實和因素，同時又使各參與方保持獨立和隔離。
- Don't Program by Coincidence
不要靠巧合編程
只依靠可靠的事物。注意偶發的復雜性，不要把幸運的巧合與有目的的計劃混為一談。
- Estimate the Order of Your Algorithms
估算你的算法的階
在你編寫代碼之前，先大致估算事情需要多長時間。
- Test Your Estimates
測試你的估算
對算法的數學分析并不會告訴你每一件事情。在你的代碼的目標環境中測定它的速度。
- Refactor Early, Refactor Often
早重構，常重構
就和你會在花園里除草、并重新布置一樣，在需要時對代碼進行重寫、重做和重新架構。要鏟除問題的根源。
- Design to Test
為測試而設計
在你還沒有編寫代碼時就開始思考測試的問題。
- Test Your Software, or Your Users Will
測試你的軟件，否則你的用戶就得測試
無情地測試。不要讓你的用戶為你查找bug。
- 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
使用項目詞匯表
創建并維護項目中使用的專用術語和詞匯的單一信息源。
- Don't Think Outside the Box - Find the Box
不要在盒子外面思考——要找到盒子
在遇到不可能解決的問題時，要確定真正的約束。問問你自己：“它必須以這種方式完成嗎？它真的必須完成嗎？”
- Start When You're Ready
等你準備好再開始
你的一生都在積累經驗。不要忽視反復出現的疑慮。
- Some Things Are Better Done than Described
對有些事情“做”勝于“描述”
不要掉進規范的螺旋——在某個時刻，你需要開始編碼。
- Don't Be a Slave to Formal Methods
不要做形式方法的奴隸
如果你沒有把某項技術放進你的開發實踐和能力的語境中，不要盲目地采用它。
- Costly Tools Don't Produce Better Designs
昂貴的工具不一定能制作出更好的設計
小心供應商的炒作、行業教條、以及價格標簽的誘惑。要根據工具的價值判斷它們。
- Organize Teams Around Functionality
圍繞功能組織團隊
不要把設計師與編碼員分開，也不要把測試員與數據建模員分開。按照你構建代碼的方式構建團隊。
- Don't Use Manual Procedures
不要使用手工流程
shell腳本或批文件會一次次地以同一順序執行同樣的指令。
- Test Early.Test Often.Test Automatically
早測試，常測試，自動測試
與呆在書架上的測試計劃相比，每次構建時運行的測試要有效得多。
- Coding Ain't Done 'Til All the Tests Run
要到通過全部測試，編碼才算完成
就是這樣。
- Use Saboteurs to Test Your Testing
通過“蓄意破壞”測試你的測試
在單獨的軟件副本上故意引入bug，以檢驗測試能夠抓住它們。
- Test State Coverage, Not Code Coverage
測試狀態覆蓋，而不是代碼覆蓋
確定并測試重要的程序狀態。只是測試代碼行是不夠的。
- Find Bugs Once
一個bug只抓一次
一旦測試員找到一個bug，這應該是測試員最后一次找到它。此后自動測試應該對其進行檢查。
- English is Just a Programming Language
英語就是一種編程語言
像你編寫代碼一樣編寫文檔：遵守DRY原則、使用元數據、MVC、自動生成，等等。
- Build Documentation In, Don't Bolt It On
把文檔建在里面，不要拴在外面
與代碼分離的文檔不太可能被修正和更新。
- Gently Exceed Your Users' Expectations
溫和地超出用戶的期望
要理解你的用戶的期望，然后給他們的東西要多那么一點。
- Sign Your Work
在你的作品上簽名
過去時代的手藝人為能在他們的作品上簽名而自豪。你也應該如此。
