《程序员修炼之道》备忘清单
1、關心你的技藝
如果你不在乎能否開發出漂亮的軟件，你又何必要耗費生命去開發軟件呢？
2、思考！你的工作
關掉自動駕駛儀，接管操作。不斷的批評和評估你的工作
3、提供各種選擇，不要找蹩腳的接借口
要提供各種選擇，而不是找借口。不要說事情做不到，說明能夠做什么
4、不要容忍破窗戶
當你看到糟糕的設計、錯誤的決策和糟糕的代碼時，修正他們
5、做變化的催化劑
你不能強迫別人改變。相反，要向他們展示未來會怎樣，并幫助他們參與對未來的創造
6、記住大圖景
不要太過專注于細節，以致忘了查看你周圍正在發生什么
7、使質量成為需求問題
讓你的用戶參與確定項目真正的質量需求
8、定期為你的知識資產投資
讓學習成為習慣
9、批判地分析你讀到的和聽到的
不要被供應商、媒體炒作、或教條左右。要依照你自己的看法和你的項目的情況去對信息進行分析
10、你說什么和你怎么說同樣重要
如果你不能有效地向別人傳遞你的了不起的想法，這些想法就毫無用處
11、不要重復你自己
系統中的每一項知識都必須具有單一、無歧義、權威的表示
12、讓復用變得容易
如果復用很容易，人們就會去復用。創造一個支持復用的環境
13、消除無關事物之間的影響
設計自足、獨立、并具有單一、良好定義的目的的組件
14、不存在最終決策
沒有決策是澆筑在石頭上的。相反，要把每項決策都視為是寫在沙灘上的，并未變化做好計劃
15、用曳光彈找到目標
曳光彈能通過實驗各種事物并檢查他們離目標有多遠來讓你追蹤目標
16、為了學習而制作原型
原型制作是一種學習經驗。其價值并不在于你所產生的膽碼，而在于所學的經驗教訓
17、靠近問題領域變成
用你的用戶的語言進行設計和編碼
18、估算，以避免發生意外
在著手之前先進行估算。你講提前發現潛在的問題
19、通過代碼對進度表示迭代
用你在進行實現時獲得的經驗提煉項目的時間標度
20、用純文本保存知識
純文本不會過時。他能夠幫你有效利用你的工作，并簡化調試和測試
21、利用命令shell的力量
當圖形用戶界面無能為力的時候使用shell
22、用好一種編輯器
編輯器應該是你手的延伸；確保你的編輯器是可配置、可擴展、可編程的
23、總是使用源碼控制
遠嗎控制是你的工作的時間機器——你能夠回到過去
24、要修正問題，而不是發出指責
BUG是你的過錯還是別人的過錯，并不是真的很有關系——它仍然是你的問題，它仍然需要修正
25、不要恐慌
做一次深呼吸，思考什么可能是BUG的原因
26、Select沒有問題
在操作系統或編譯器、甚或是第三方產品或庫中很少發現bug。bug很可能在應用中。
27、不要假定，要證明
在實際環境中——使用真正的數據和邊界條件——證明你的假定
28、學習一種文本操縱語言
你用每天用很長的時間處理文本，為什么不讓計算機替代你完成部分工作呢？
29、編寫能編寫代碼的代碼
代碼生成器能提高你的生產率，并有助于避免重復
30、你不可能寫出完美的軟件
軟件不可能完美。保護你的代碼和用戶，使它們能免于能夠遇見的錯誤
31、通過合約進行設計
使用合約建立文檔，并檢驗代碼所做的事情正好是它聲明要做的
32、早崩潰
死程序造成的危害通常比有問題的程序要小的多
33、用斷言避免不可能發生的事情
斷言驗證你的各種假定。在一個不確定的世界里，用斷言保護你的代碼
34、將異常用于異常的問題
x
35、要有始有終
只要可能，分配某資源的歷程或對象也應該負責解除其分配
36、使模塊之間的耦合減至最少
通過編寫“羞怯的”代碼，避免耦合
37、要配置，不要集成
要將應用的各種技術選擇實現為配置選項，而不是通過集成或工程方法實現
38、將抽象放進代碼，細節放進元數據
為一般情況編程，將細節放在被編譯的代碼庫之外
39、分析工作流，以改善并發性
利用你的用戶的工作流中的并發性
40、用服務進行設計
根據服務——獨立的、在良好定義、一致的借口之后的并發對象——進行設計
41、總是為并發進行設計
容許并發，你將會設計出更整潔、具有更少假定的接口
42、使視圖與模型分離
要根據模型和視圖設計你的應用，從而以低廉的代碼獲取靈活性
43、用黑板協調工作流
用黑板協調完全不同的事實和因素，同時又使各參與方保持獨立和隔離
44、不要靠巧合編程
只依靠可靠的事物。注意偶發的復雜性，不要把幸運的巧合與有目的的計劃混作一談
45、估計你算法的階
在你編寫代碼之前，先大致估算事情需要多長的時間。
46、測試你的估算
對算法的數學分析并不會會告訴你每一件事情。在你的代碼的目標環境中測試它的速度。
47、早重構、常重構
就和你會在花園里除草、并重新不知一樣，在需要時對代碼進行重寫、重做和重新架構。要鏟除問題的根源。
48、為測試而設計
在你還沒有編寫代碼時就開始思考測試的問題
49、測試你的軟件，否則你的用戶就得測試
無情的測試。不要讓你的用戶為你查找bug
50、不要使用你不理解的向導代碼
想到可以生成大量代碼。在你把他們合并進你的項目之前，確保理解這些全部代碼
51、不要搜集需求——挖掘他們
需求很少存在與表面上。他們深深地埋葬在層層假定、誤解和政治手段的下面
52、與用戶一同工作，以向用戶一樣思考
要了解系統實際上將如何被使用，這是最好的方法
53、抽象比細節活的更長久
投資于抽象，而不是實現。抽象能在來自不同的實現和新技術的變化的“攻擊”之下存活下去
54、使用項目詞匯表
創建并維護項目中使用的專用術語和詞匯的單一信息源
55、不要在盒子外面思考——要找到盒子
在遇到不可能解決的問題時，要確定真正的約束。問問你自己：“他必須以這種方式完成，嗎？它真的必須完成嗎？”
56、等你準備好再開始
你的一生都在積累經驗。不要護士反復出現的疑慮
57、對有些事情“做”勝于“描述”
不要掉進規范的螺旋——在某個時刻，你需要開始編碼
58、不要做形式方法的奴隸
如果你沒有把某項技術放進你的開發時間和能力的語境中，不要盲目的采用他
59、昂貴的工具不一定能制作出更好的設計
小心供應商的炒作，行業教條、以及價格標簽的有貨。要根據工作的價值判斷他們
60、圍繞功能組織團隊
不要把設計師與編碼員分開，也不要把測試員與數據劍魔分開。按照你構建代碼的方式構建團隊。
61、不要使用手工流程
shell腳本或壁櫥里文件會一次次地以同一順序執行同樣的指令
62、早測試，常測試，自動測試
與待在書架上的測試計劃相比，每次構建時運行的測試要有效的多
63、要到通過全部測試，編碼才算完成
64、通過“蓄意破壞”測試你的測試
在單獨的軟件副本上故意引入bug，以檢驗測試能夠抓住他們
65、測試狀態覆蓋，而不是代碼覆蓋
確定比測試重要的程序狀態。只是測試代碼行是不夠的
66、一個bug只抓一次
一旦測試員找到一個BUG，這應該是測試員最后一次找到它。伺候自動測試應該對其進行檢查
67、英語就是一種編程語言
像你編寫代碼一樣編寫文檔：遵守不重復自己原則、使用元數據、MVC、自動生成，等等。
68、把文檔建在里面，不要拴在外面
與代碼分離的文檔不太可能被修正和更新
69、溫和地超出用戶的期望
要理解你的用戶的期望，然后給他們的東西要多那么一點
70、在你作品上簽名
過去時代的手藝人為能子啊他們的作品上簽名而自豪。你也應該如此
71、要學習的語言
厭倦了C、C++、Java？試試Python、Golang、Erlang、Elixir。用其中的一種或多種語言在家里開發一個小項目
72、x
73、怎樣維持正交性
? 設計獨立、良好定義的組件
? 使你的代碼保持解耦
? 避免使用全局數據
? 重構相似的函數
74、應制作原型的事物
? 架構
? 已有系統中的新功能
? 外部數據的結構或內容
? 第三方工具或組件
? 性能問題
? 用戶界面設計
75、架構問題
? 責任是否得到了良好定義？
? 協作是否得到了良好的定義？
? 耦合是否得以最小化？
? 你能否確定潛在的重復
? 接口定義和各項約束是否可接受
? 模塊能否在需要時訪問所需數據
76、調試檢查清單
? 正在報告的問題是底層Bug的直接結果，還是只是癥狀？
? Bug真的在編譯器里？在OS里？或者是在你的代碼里？
? 如果你向同事詳細解釋這個問題，你會說什么？
? 如果可以代碼通過了單元測試，測試是否足夠完整？如果你用該數據運行單元測試，會發生什么？
? 造成這個bug的條件是否存在于系統中的其他任何地方？
77、函數的墨忒耳法則
某個對象的方法應該只調用屬于以下情形的方法：
? 它自身
? 傳入的任何參數
? 它創建的對象
? 組件對象
78、怎樣深思熟慮地編程
? 總是意識到你在做什么
? 不要盲目的變成
? 按照計劃行事
? 依靠可靠的事物
? 為你的假定建立文檔
? 不要只是測試你的代碼，還要測試你的假定
? 重要：為你的工作劃分優先級
? 不要做歷史的奴隸
79、何時進行重構
? 你發現了對“不重復自己”原則的違反
? 你發現事物可以更為正交
? 你的知識擴展了
? 需求演變了
? 你需要改善性能
80、劈開戈爾迪斯結
在解決不可能解決的問題時，問問你自己：
? 有更容易的方法嗎？
? 我是在解決正確的問題嗎？
? 這件事情為什么是一個問題
? 它必須以這種方式完成嗎？
? 它真的必須完成嗎？
81、測試的各個方面
? 單元測試
? 集成測試
? 驗證和校驗
? 資源耗盡、錯誤以及恢復
? 性能測試
? 可用性測試
? 對測試自身進行測試
總結
以上是生活随笔為你收集整理的《程序员修炼之道》备忘清单的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： perl 引用（一）
- 下一篇： [召集] .NET Framework基