Contents
根據10 Classic Books Every Serious Developer Should Read (Soft & Share翻譯文)，首推的書為The Pragmatic Programmer: From Journeyman to Master
The Pragmatic Programmer作者Andrew Hunt 和 David Thomas為他們的書擷取了精華，如果您還沒有看這本書，可以先睹為快，如果看過了，也可當座右銘。
實用的軟體開發訣竅
關心你的工藝 Care About Your Craft
如果不想做出好作品，何必花一生的時間開發軟體呢?
提供選項，不要給站不住腳的理由 Provide Options, Don’t Make Lame Excuses
與其給與藉口，不如給選項。 不要說做不到，要告訴對方什麼可以做到。
做改變的催化劑 Be a Catalyst for Change
我們無法強迫別人改變，取而代之的是要秀給他們未來可以是什麼樣子，並幫助他們參與，一起創造。
讓品質成為需求的項目 Make Quality a Requirements Issue
讓使用者參與專案真實的品質需求決策。
嚴格分析讀到與聽到的資訊 Critically Analyze What You Read and Hear
不要被兜售的人、媒體炒作或教條給左右。 依你個人、團隊和專案的狀況分析。
OAOO(Once and Only Once)規則 DRY—Don’t Repeat Yourself
系統中的每一部分，都必須有一個單一的、明確的、權威的代表。
消除無關事物間的影響 Eliminate Effects Between Unrelated Things
設計的組件要能自給自足、各自獨立，且有單一與妥善定義的目的。
運用曳光彈找到目標 Use Tracer Bullets to Find the Target
曳光彈讓你對準目標做多種嘗試並觀察距離目標有多近。
在接近問題的領域做計畫 Program Close to the Problem Domain
用你使用者懂的語言來做設計與編程
採用迭代循環的程序做編程 Iterate the Schedule with the Code
以你實踐時所得的經驗推敲專案的時間刻度(如幾天一個迭代)。
善用命令Shells的威力 Use the Power of Command Shells
當圖形使用者介面不切斷shell時請用shell 。
程式碼控制是必要的 Always Use Source Code Control
程式法控制系統就像你工作的時光機-你隨時可回去之前的版本。
除錯時不要驚慌 Don’t Panic When Debugging
深呼吸思考! 想想什麼造成這個瑕疵(bug)。
不要只做假設-證明它 Don’t Assume It—Prove It
在實際的環境下-以真正的資料和邊界條件來證明你的假設。
做會自動幫你寫程式碼的編程 Write Code That Writes Code
程式碼產生器將提升你的生產力且幫你避免複製.
依合約做設計 Design with Contracts
以合約做紀錄並查驗所寫的程式是否就是合約所要的，不要做過多也不要做過少，設計要恰到好處。
以斷言(assertions)避免不可能 Use Assertions to Prevent the Impossible
斷言(assertions)證實你的假設。 在這什麼都不確定的世界請採用斷言來保護你的程式碼。
由誰開始就由誰結束
如果由哪個例行物(routine)或標的物(object)分配一個資源，也應該由其負責收回此資源。
設定，不是整合 Configure, Don’t Integrate
為一個應用以設定的選擇來實踐技術選項，而不是用整合或工程的方式來做。
分析流程以改善同步 Analyze Workflow to Improve Concurrency
在你的使用者流程中多多利用同步的概念 。
總以同步來做設計 Always Design for Concurrency
納入同步概念，你的設計介面將比較乾淨且比較少假設(if…)。
使用白板協調工作流程 Use Blackboards to Coordinate Workflow
採用白板來協調各種事務與代理人， 同時也給每位參與者個人的獨立與隔離空間。
估計你邏輯運算的次序 Estimate the Order of Your Algorithms
在編碼前先估量一下要每一樣會花多少時間。
早點重構, 經常重構 Refactor Early, Refactor Often
正如你可能需要為花園除草和重新佈置，重寫、重工以及重新架構程式碼有時也是必須的。 如此才能根本解決問題。
如果你不測試自己的軟體，你的使用者將會幫你測試 Test Your Software, or Your Users Will
要徹底、毫不留情地測試。 不要留瑕疵(bugs)給你的使用者發現。
不是收集需求-要挖出需求 Don’t Gather Requirements—Dig for Them
需求很少在表面上出現。 他們被深深埋在很多層假設、錯誤認知與政治下。
抽象比細節長久 Abstractions Live Longer than Details
投資抽象(abstraction)，而非實作。 抽象(Abstractions)經得起變更的槍林彈雨，就算採用不同的實作和新的科技也還是有用。
不只要跳脫框框思考-還要知道框框在哪裡 Don’t Think Outside the Box—Find the Box
當遇到無法理解的問題，找出實際的限制。 問自己: “一定要用這種方式來做嗎? 追根究底，這有需要做嗎? ”
有些事情做了比描述還好 Some Things Are Better Done than Described
不要掉入談規格的螺旋 — 到某一點時就該動工寫程式。
花大錢買工具不代表你的產品設計會因此變好 Costly Tools Don’t Produce Better Designs
要警覺廠商的炒作、業界的教條以及標價所造成的氛圍。 請以工具實際的績效做判斷的標準。
不要用手動程序 Don’t Use Manual Procedures
一個外殼文稿程序(shell script)或批次檔(batch file)將執行同樣的指令，以同樣的順序，一次又一次。
沒跑完測試都不算完成編碼 Coding Ain’t Done ‘Til All the Tests Run
不用多說。
測試應包含型態覆蓋, 不是只看程式碼覆蓋 Test State Coverage, Not Code Coverage
指認出並測試重大的程式狀態(program states)。 測試完每一行程式其實還不夠。
英文也算是寫程式的語言之一 English is Just a Programming Language
當你要寫程式的時候寫紀錄: 實踐DRY原則、使用後設資料(metadata)、MVC 、自動生成等等。
逐漸地超越你使用者的期待 Gently Exceed Your Users’ Expectations
下去了解你使用者的期待，然後交付比期待好一點點的東西。
多動腦筋! 關於你的工作 Think! About Your Work
關掉自動導航模式，拿回你的掌控權。 經常地批判與評價你自己的工作。
別忽視破窗效應 Don’t Live with Broken Windows
當你看到很糟糕的設計、錯誤的決策和很爛的程式碼請想辦法修正。
記住事情的全貌與長遠的遠景 Remember the Big Picture
不要因為太專注細節而忘了看周遭發生的事物 。
經常投資你的知識組合 Invest Regularly in Your Knowledge Portfolio
讓學習成為你的習慣。
你說什麼與你如何表達都很重要 It’s Both What You Say and the Way You Say It
如果沒有被有效的溝通怎麼棒的想法都沒有用。
讓它容易重複使用 Make It Easy to Reuse
如果容易重複使用的話就會有很多人如此做。 建立一個支持重複使用的環境。
沒有所謂的最終決定 There Are No Final Decisions
沒有一個決定是刻在石頭上的。 相反的 ，考慮每一個決定是寫在海灘的沙子上，且計畫變更。
製做原型來學習 Prototype to Learn
製作原型是個學習經驗。 其價值並非你產出的這些程式碼，而是你從中學得的功課。
事前估算以避免意外 Estimate to Avoid Surprises
開始前先估計。 你將是先發現潛在問題 。
將知識存於純文字檔 Keep Knowledge in Plain Text
純文字檔(Plain text)永不會過時 ，它幫助你工作上的槓桿也簡化除錯與測試。
好好使用單一的編輯器 Use a Single Editor Well
編輯器應該就像你手的延伸；確定你的編輯器可被設定、延展且可被編程。
解決問題，不是抱怨 Fix the Problem, Not the Blame
瑕疵是你造成的或是別人造成的其實並不重要—它仍是你的問題 ，且需要你去解決。
有問題時先別假設你選的外部系統出問題 “select” Isn’t Broken
其實很少問題出在操作系統(OS)或編譯器(compiler) ，或是你選的第三方產品或函式庫 (library) 。 大多問題都出現在你寫的用程式中
學習一種純文字操作語言 Learn a Text Manipulation Language
你每天花大部分的時間用純文字工作，為何不讓電腦幫你分擔一些工作呢?
你不可能寫出完美的軟體 You Can’t Write Perfect Software
軟體不可能完美。 請保護你的程式與你的使用者 ，免於受害於無法避免的錯誤 。
如有問題早點崩潰比較好 Crash Early
死的程式通常比跛的程式少做很多破壞。
採用例外處理解決例外的問題 Use Exceptions for Exceptional Problems
典型的雜亂程式碼(spaghetti code)其可讀性與可維護性的問題容易導致例外發生。為例外儲備例外處理。
盡量減少模組間的耦合 Minimize Coupling Between Modules
編寫”害羞”程式碼並採用得墨忒耳定律（Law of Demeter，縮寫LoD）以避免耦合。
把抽象(Abstractions)置入程式碼，把細節放入後設資料 Put Abstractions in Code, Details in Metadata
為一般的案例寫程式，將特殊狀況放在編譯的程式基底外。
以服務的觀點來設計 Design Using Services
以服務的觀點來設計—獨立、在妥善定義下同時並行的物件、一致的介面。
分開視圖和模型 Separate Views from Models
低成本的方式，分別以模型和視圖的角度來設計應用程式，取得更大的彈性。
不要用瞎貓碰到死耗子的方法寫程式 Don’t Program by Coincidence
請只依靠可靠的事物。 小心偶然事物將讓事情變得複雜，不要混淆剛剛好做對就以為達到計劃中的目的。
測試你的估計 Test Your Estimates
演算法的數學分析不能告訴你所有的事。 請在目標環境下試著計時你的編碼。
設計前考量測試 Design to Test
在寫第一行程式碼前先想想要如何做測試 。
不要用你不懂的精靈程式碼 Don’t Use Wizard Code You Don’t Understand
精靈(Wizards)可產生大量的程式碼。 在你把它併入你的專案前請先確定你了解它所有的一切 。
與使用者合作並如使用者思考 Work with a User to Think Like a User
最好的方法是洞見系統將被如何使用。
編纂專案的詞彙表 Use a Project Glossary
於單一來源建立並維護一個專案所有的特殊名詞和字彙。
當準備就緒的時候就開始 Start When You’re Ready
你已經不斷在你的生涯旅途中累積經驗。 不要忽視一直煩擾你的疑惑。
不要成為正規方法的奴隸 Don’t Be a Slave to Formal Methods
不要盲目採用任何不適合你真正開發實踐和能力情境的技術。
圍繞著功能來組織團隊 Organize Teams Around Functionality
不要將設計人員與編碼人員分開，也不要分開測試人員與資料建模人員。 團隊建立的方式要像程式建立的方式。
早點測試.經常測試. 自動測試 Test Early. Test Often. Test Automatically.
隨著每一次建置(build)做測試將比束之高閣的測試計畫有效多了。
用破壞者來測試你的測試是否有效 Use Saboteurs to Test Your Testing
故意帶入某些瑕疵(bugs)另做一個程式碼的版本來驗證所做的測試能否抓到這些瑕疵(bugs)。
每個瑕疵只讓你找到一次 Find Bugs Once
一旦被人類的測試員找到瑕疵，這應該是人類測試員最後一次找到這個瑕疵才對。 從此之後應該讓自動化測試幫你抓它出來 。
將文件紀錄內建, 不是拴上 Build Documentation In, Don’t Bolt It On
文件紀錄如果和程式碼分開而非內建就比較不可能在程式碼更新時也一起被修改。
在你的作品上簽名 Sign Your Work
早期的工藝家都會以自己的作為為榮並在作品上簽名。你應該也是如此。
你可能會感興趣
- 購買 Pragmatic Programmer 原文電子書 ( 電子書中文介紹 )
- [電子書] Clean Code
- [電子書] Clean Architecture
- 使用 e-mail 訂閱 Soft & Share 內容發布 – 透過 e-mail 提早收到 Soft & Share 發布的好康訊息！
- Soft & Share 特價課程與學習資訊分享 加入這個社團追蹤特價課程與學習資訊
- 追蹤這個 Twitter ，追蹤特價課程與學習資訊