程序員應該知道的97件事-讀書筆記

1. 謹慎行動
1. 技術債務就像一筆貸款。在短時間內，你能從中獲得好處，可是，在清償以前，你要付出利息。代碼裏的捷徑使得新功能更難於加入，也會影響到代碼重構。它們是軟件缺陷和失敗測試用例的滋生地，聽任它們的時間越長，狀況就會越糟糕。
2. 每每是狀況不可收拾時，你纔不得不對它們進行修正，而那時你已沒有足夠的時間，也承擔不起由此帶來的風險
3. 必須時刻追蹤技術債務，儘快的或者當狀況急劇惡化的時候，當即將其償還。每當你無可奈何欠下了技術債務，就要當即記錄到人物卡上或者等級到問題追蹤系統裏，以保證其不會被遺忘
2. 函數式編程原則的應用
1. 函數式編程能極大地提升你的代碼質量
2. 引用透明性：函數無論在什麼時候何地被調用，都保持一致的行爲，一樣的輸入獲得一樣的輸出結果
3. 試問本身「用戶會怎麼作」（你不能算是用戶）
1. 咱們都愛假設別人的心思跟咱們同樣，但事實上不是這回事。心理學上把這種心理狀態叫作虛假同感誤差(false consensus bias)。當人們的想法和行爲跟咱們不一樣時，咱們極可能會（在潛意識裏）將他們歸位「能力低下」的人
2. 用戶卡住的時候，他們會縮小他們的注意力範圍，因而更難以看到在屏幕其餘區域上顯示的解決方法。由於用戶注意力範圍縮小，使用tool tip的效果賽過點擊幫助菜單
3. 用戶都傾向於能用就好。他們一旦找到一種可用的方法，就會一直用下去，無論它有多麼費勁。所以，提供一條顯而易見的操做途徑，要好過提供兩三條捷徑
4. 編碼標準的自動化
1. 編碼標準應該是動態的，不是一成不變的。隨着項目的進展，項目需求的改變，一些在剛開始時顯得靈活的標準可能在幾個月後會變得不夠靈活
5. 美在於簡單
1. 風格之美、和諧、優雅及優美的節奏盡在於簡單——柏拉圖
2. 優美的代碼有許多共同的屬性，首要的一點就是簡單。一個應用或一個系統不管有多麼複雜，其中每一個單獨的組成部門都保持着它的間接性。
3. 不管通過多少時間，乾淨、簡單、可測試的代碼保證了系統的可維護性，也確保了系統在整個生命週期裏能快速開發升級
4. 美來自於簡單，亦存在於簡單
6. 在你重構以前
1. 重構代碼的最佳起點就是清理已有的基礎代碼和基於這些代碼寫的測試
1. 咱們都以爲本身能夠比原有系統作得更好，這是由於咱們沒有向原有系統中的錯誤學習
2. 避開重寫一切的誘惑
1. 儘量多的重用代碼是最好的選擇，不管代碼是多麼的醜陋，畢竟它已經被測試過了，也被審查過了
2. 拋棄舊代碼——尤爲是存在於產品中的代碼——也意味着拋棄了經年累月測試並實戰過的代碼，以及你還未知曉的周邊代碼和bug補丁。這會浪費大量的時間、精力和多年積累下來的知識
3. 逐步增長的小改動賽過一次性的大改動
4. 在每次迭代以後，要確保已有的測試用戶都已經過
1. 假如已有的測試用例還沒能覆蓋到你所作的修改部分，那就增長新的測試用例
5. 我的好惡和利己主義不能參雜到開發中來
1. 若是代碼的風格或結構不符合你的我的喜愛，你也不能把這看成代碼重構的正當理由。即便你以爲本身能夠比上一個程序員作得更好，也不能將它做爲重構的理由。
6. 新技術不是重構的充分理由
1. 關於重構的最差勁的理由之一就是當前代碼跟咱們目前擁有的很酷的技術相比已經遠遠落後了，咱們相信用新的語言或框架來完成這些功能會更加優雅。
2. 除非成本效益分析結果代表這種新的語言或框架能在功能性、可維護性或生產力上會有顯著的提高，不然，最好仍是棄之不用
7. 要記住人老是會犯錯誤的
1. 重構不能一直保證新代碼會超過——或至關於——原先的代碼
7. 謹防共享
1. 建立共享的代碼庫以前，應該仔細檢查上下文環境
8. 童子軍規則
1. 若各團隊能把系統當成一個總體來維護，再也不「各人自掃門前雪」，咱們將看到軟件系統裏無可挽回的退化局面會終結，並且會逐漸變得更好
2. 把代碼搞得一團糟的行爲也應該像社會上亂丟垃圾行爲同樣不受待見，由於是該作的卻沒有作到的行爲
3. 團隊要相互幫助，相互清理代碼，這對每個人都有好處，而不只僅是他們本身
9. 在責備別人以前先檢查本身的代碼
1. 假如使用的工具是一個被普遍使用的、成熟的，不一樣技術領域都在用的產品，那就幾乎沒有理由去懷疑它的品質
2. 若是其餘人報告說有問題，而你卻沒法重現時，那就走過去看看他們究竟是怎麼操做的
10. 謹慎選擇你的工具
1. 如今的應用程序不多從零開始構建的
2. 從小範圍開始，只採用相對必需的工具
11. 領域語言裏的代碼
12. 代碼就是設計
1. 大幅削減建形成本，致使的結果倒是質量惡化
2. 軟件設計只有經過了一系列嚴格的測試驗證以後才能算完成
3. 咱們的但願在於改良的程序設計語言及設計的最佳實踐
4. 偉大的設計是由偉大的設計者做出的，他們窮盡一輩子精通了該門技藝
13. 關於代碼佈局的麻煩事
1. 易於檢索
2. 清晰的佈局
3. 緊湊格式
14. 代碼審查
1. 代碼審查能提供改嗎質量，下降差錯率。一個組織很須要這樣一個硬性的、正式的過程
2. 代碼審查的目的不只僅是簡單的更正代碼錯誤，其目的應該是共享知識、創建統一的編碼指導標準
3. 代碼審查的時候態度要溫和，確保評語是有建設性的，不是刻薄的
4. 在代碼審查會議上，對代碼格式應該不作評論
5. 主要着眼於在團隊成員之間分享知識，拋開諷刺性的評語
15. 編寫代碼的理由
1. 避免使用可更改的全局變量，由於這會讓全部使用它們的代碼段產生依賴
16. 對註釋的一個註釋
17. 代碼說不清，註釋來補充
1. 沒法給代碼增長價值的註釋就是噪音。那些只會 模仿代碼的註釋沒法給讀者提供更多的信息
2. 應該像對待代碼同樣對待註釋。每一段註釋應該爲讀者注入一些價值，不然純粹就是浪費，還不如刪除，或者乾脆重寫
18. 不斷學習
1. 你須要爲你本身的教育負起責任
2. 儘可能爲本身找到一個導師。若是本身就是最厲害的傢伙，那會阻礙你的修習之路。雖然你能夠從其餘人身上學到點什麼，可是，在那些更聰明、經驗更豐富的人身上，你能學到更多。若是找不到導師，就換一個地方
3. 每一年學習一門新的語言，至少要學用一門新的技術或工具。這能夠幫助你拓寬新思路，充實你當前的技術儲備
19. 易用不是一種能力
1. 好的API要遵循一致的抽象層次，並展示出它的一致性和對稱性，最終組成一份表達充分的詞彙表。
2. API應該提供一種表達充分的語言，給予上層一份豐富的詞彙表，讓它能據此請求和回覆那些有用的問題
3. 易用而且通過深思熟慮的API詞彙表能夠致使上層使用富有表現力的、易於理解的代碼
20. 早部署，常部署
1. 發佈工程師(Release Engineer)
2. 按期在一個乾淨的環境中運行和測試安裝過程，可讓你檢查出代碼中那些基於開發或測試環境所作的假定是否合理
3. 把部署放到最後意味着那些圍繞着部署假定的代碼會變得更加複雜
4. 全部權衡事項宜早不宜遲
21. 區分業務異常和技術異常
1. 因爲領域邏輯的緣由沒法完成調用而產生的業務異常，是契約的一部分，拋出異常只是按原路徑返回錯誤的一種替代方式，客戶端應該知道而且隨時準備處理它
22. 有針對性的勤加練習
1. 有針對性的勤加練習就是經過執行一項任務來提升自身的能力，關乎技巧和技術
2. 作有針對性的練習就是爲了精通這項任務，並非完成任務
3. 有償開發的首要目標是完成一個產品，而有針對性的練習的首要目標是提升你的水平。二者是不同的
4. 精英執行者也至少須要10000個小時的有針對性的聯繫才能成爲專家
5. 偉大在很大程度上就是有意識選擇的結果
6. 達到專家水平的主要因素就是花時間去作帶有針對性的練習
7. 有針對性的練習意味着多練習你不擅長的東西
8. 學習改變你的東西，學習改變你行爲的東西。祝你好運！
23. 領域特定語言
24. 不要怕搞砸
1. 熟練的外科醫生都知道爲了手術必需要開幾道切口，可是，她也知道這切口都是臨時的，會癒合的
2. 對於改變的麻痹式恐懼在開始時就會讓你的項目陷入到這種投鼠忌器的狀態
3. 做爲一個外科醫生，爲了給痊癒騰出空間，她一點都不懼怕切除壞死組織
25. 不要在你的測試代碼裏裝可愛
1. 在你的代碼裏寫入文本的時候，不管是註釋、日誌、對話框或者測試數據，都要問一下本身若是這些公開出去的話會怎麼樣。這樣會讓你少臉紅幾回
26. 不要忽略那個錯誤
1. 不顧紅燈亮起，繼續前行，結果只會招致更大的損失。要在時機初現的時候就動手，把損失較少到最小
27. 不要只學習語言，還要了解它的文化內涵
28. 不要把程序釘死在老地方
29. 不要期望「魔法會在此發生」
1. 沒有開發經驗的經理會認爲程序員作的事情很簡單，而沒有管理經驗的程序員也認爲經理所作的事情很簡單
30. 不要重複你本身
1. 應用裏的每一行代碼都會被維護到，它們就是將來bug的潛在來源
2. DRY的要求是「在一個系統內，每一塊知識必須有一個單一的、明確的、權威的表示」
3. 將重複的過程調用自動化
4. 凡有痛苦的手工過程存在的地方，均可以使用自動化，手工過程原本就應該被自動化和標準化
31. 別碰那些代碼！
1. 開發人員——甚至是高級開發人員的訪問權限都應該不能超越開發服務器
2. 如同開發人員不須要訪問開發服務器以外的任何服務器同樣，QA團隊和用戶也不須要接觸開發服務器上的任何東西
3. 發佈經理是惟一能訪問這兩臺服務器的人
4. 不管在哪一種狀況下——從根本上說，就是永遠不要讓開發人員有訪問產品服務器的權限
5. 若是代碼有問題，產品服務器不是修復它的地方
32. 封裝行爲，而不只僅是狀態
33. 浮點數不是真正的數
1. 浮點數的精度是有限的，是能夠窮盡的。甚至在分佈範圍內的間隔也不是均勻的
34. 開源助你實現雄心壯志
1. 經過給別人的軟件編寫測試代碼，能讓你學得更快，超過軟件開發裏其餘任何一個活動
35. API設計的黃金法則
1. 鎖定API：能夠試着把絕大多數的類和方法都表上final，以此來阻止用戶的重載或代碼的濫用，避免將來你在更改選擇時受到約束
2. 單元測試是實踐中極端重要的一部分
3. API設計的黃金法則：只爲你開發的API編寫測試代碼是不夠的，你還必須給使用API的代碼編寫單元測試
36. 高手神話
1. 若是某人看上去像是個高手，那是由於他擁有多年的學習和思惟精煉過程的積累。「高手」往簡單上講就是一個有着無窮好奇心的聰明人
2. 咱們不須要高手，咱們須要能幫助其餘人在他們領域裏成爲專家的專家
37. 加班加點，事倍功半
38. 如何使用bug跟蹤器
1. 一個好的bug報告須要具有三樣東西：
1. 若是重現該bug，儘量準確的描述，間隔多久後bug會再出現一次
2. 本應該發生什麼，至少按你本身的看法來講
3. 實際上發生了什麼，或者至少是你記錄到的儘量多的信息
2. bug不是工做的標準單元，不能像一行行代碼那樣精確地衡量着你的努力。（其實代碼行也只是粗略衡量）
39. 代碼的去蕪存菁
1. 經過刪除基礎代碼中那些使人不快的功能特性，下降了全局代碼熵的水平
2. 編寫代碼是由於他們增長價值，而不是取悅你本身
3. 若是你如今不須要，那如今就不要寫
4. 額外代碼的編寫和維護老是會花更長的時間。一團小小的額外代碼「雪球」隨着時間的推移會變成一項龐大的須要維護工做
5. 程序員發明了額外的需求，既不記錄在文檔裏，也沒通過討論確認這個額外功能特性。這需求實際上就是捏造出來的。
6. 系統需求不是程序員設定的，而是客戶要作的
40. 安裝我吧
1. 記住，客戶也下載了競爭對手的框架。你知道的，競爭對手老是在論壇裏宣稱他們的框架比你的好不少
41. 進程間通訊對應用程序響應的影響
1. 許多性能管理著做仍然執着於數據結構和算法，這些因素在某些狀況下是會起一些做用，可是在現代多層企業應用中並不處於主導地位
2. 響應時間極大地依賴於對刺激做出響應的遠程進程間通訊的數量。
3. 用於響應刺激的遠程IPC數目越多，響應時間就會越大。如何減小？
1. 吝嗇原則，優化進程間的接口，只爲互動過程準備最小數量的正確的數據
2. 在可能的狀況下，並行執行進程間通訊，這樣總的響應時間會主要取決於時延最長的IPC
3. 緩存前次IPC的結果，未來的IPC就可能不用再執行，直接用命中的本地緩存來代替
42. 保持構建的整潔
1. 忽略事情也是腦力勞動
2. 來自於構建的警告是有用的。你要在開始注意到它們的時候就着手清除，不要等到最後「大掃除」的時候再去作
3. 讓構建保持乾淨，不僅是消滅編譯錯誤或者測試失敗：警告信息也是「代碼衛生」裏重要且關鍵的一部分
43. 知道如何使用命令行工具
1. 設計良好的IDE不過就是一套命令行工具的圖形化前端
44. 通曉兩門以上編程語言
1. 一個程序員的編程技巧跟他能駕輕就熟處置的不一樣編程範例數目直接相關
2. 只懂得一種語言的程序員會被那種語言禁錮住她的思想
3. 編程範式：過程式、面向對象、函數式、邏輯型、數據流……
4. 每一個程序員最好能在兩種不一樣的範式下有熟練的編程技能，理想一點就是掌握五種編程範式
5. 程序員應該對學習新語言始終保持着興趣，特別是對於不熟悉的範式
45. 瞭解你的IDE
46. 瞭解你的侷限性
1. 你的資源是有限的。你只有這麼點時間、這點錢去作你的事情，包括還要花錢花時間讓你的知識、技能和工具跟上時代。因此，你的工做要如此投入、如此快速、如此靈活、如此持久。你的工具也就這點威力，你的目標機器也就這點功率。所以，你不得不考慮一下你有限的資源
2. 對於小數組，線性查找頗有競爭力
47. 知道你下次提交的內容
1. 代碼要在頭腦裏有着清晰的意圖和有限且可達的目標
2. 知道你下次所要提交的東西。若是你沒法完成，就丟棄掉更改，而後按照你已有的理解，定義出一項你確信能完成的新任務。只要有須要也要作一些投機試驗，可是不要在無心之中陷入到投機模式中。
3. 千萬不要把猜測獲得的東西放入代碼庫裏。
48. 大型、相關性的數據屬於數據庫
49. 學習外語
1. 付出總會有回報，時機遲早會來
2. 在今天，跟簡單的編程實用工藝相比，大型項目更像是社會性的事業
3. 懂另一門語言，就是擁有了另外一個靈魂
4. 要懂得何時傾聽，而不是交談，要知道多數語言是沒有文字的
5. 對於不可言說的，必須保持沉默——Ludwig Wittgenstein
50. 要學會估算
1. 估算就是對價值、數值、質量及其擴展項目做出近似的計算和判斷。估算是基於實際數據和以往經驗的實際衡量——在計算的時候不能讓但願和願望摻雜進來。估算是一個近似值，估算是不可能精確地
2. 目標是對所要達到的商業目標的陳述
3. 承諾就是答應在某個日期或者某個事件發生之時，提交否和某個質量水平的指定功能
4. 估算、目標和承諾三者是相互獨立的，可是，目標和承諾要基於合理的估算。
5. 軟件估算的首要用途不是爲了預測一個項目的產出成果，而是爲了測定一個項目的目標是否足夠現實，從而使項目處於控制之下實現這些目標。
6. 估算的用途是爲了讓適當的項目管理和計劃成爲可能，容許項目的各利益相關方基於現實目標做出承諾
51. 學着說「Hello, World」
52. 讓你的項目能表達它本身
53. 連接器並不神祕
1. 要想知道可執行文件爲何是這個大小，能夠看一下連接器選擇生成的map文件。map文件就是一張包含了可執行文件裏全部符號及它們地址的列表。它告訴你庫裏的哪些模塊連接進來了，以及每一個模塊的大小。由此你就能看出可執行文件體積膨脹是從哪裏發源的
54. 臨時解決方案的壽命
1. 當系統裏容納了太多臨時解決方案的時候，它的熵或者或內部複雜度會隨之增長，而它的可維護性卻在下降
2. 征服臨時解決方案的最佳途徑是讓它們變得多餘，提供一個更優雅、更有用的解決方案
55. 使接口易於正確使用，難於錯誤使用
1. 好的接口是易於正確使用，難以錯誤使用
2. 易用的接口看上去很天然，由於它們讓你作你想作的事情
3. 要記住接口的存在是爲了方便使用者，而不是實現者
56. 讓不可見的更加顯眼
1. 修復bug不能算是有進展。調試就是一種浪費。只有讓浪費的時間暴露在關注之下，這樣你纔會認識到什麼致使了時間的浪費，並開始檢討當初應該細心一點
2. 若是你的項目還處於可跟蹤的狀態之下，但僅僅一個星期以後，你卻發現進度上已經延遲六個月了，這時你碰到問題了——最大的問題可能不是它長達六個月的延遲，而是有股隱形的力量已經強大到掩蓋了項目延遲六個月這個事實
3. 單元測試的編寫提供了該代碼單元便於作單元測試的證據。它有助於揭示代碼存在（或不存在）你但願它能表現出的品質，例如低耦合和高內聚
4. 單元測試的運行提供了該代碼行爲的證據。它有助於揭示代碼擁有（或不擁有）你所但願的它在運行時能表現出的品質，例如健壯性和正確性
5. 可見性能讓人充滿信心，讓人以爲進展是真實的，而不是虛幻的，是有備而來的，而不是憑空想象的，是能夠重複的，而不是偶爾爲之的
57. 在並行系統中使用消息傳遞可得到更好的伸縮性
1. 人們一次次碰到的併發問題幾乎都跟易變的共享內存有關係
2. 要麼放棄併發，要麼放棄共享內存
3. 數據流系統：在一個數據流系統裏，沒有明確的編程控制流，只有一系列有向圖的算子，用數據路徑相鏈接。創建起關係後，再把數據「灌」入系統
4. 要想充分駕馭計算機硬件內建的並行能力，使用消息傳遞是一條比共享內存編程更爲成功的路徑
58. 帶給將來的消息
1. 每一行代碼都是帶給將來某我的的消息
59. 錯失採用多態的機會
60. 奇聞軼事：測試人員是你的朋友
61. 二進制文件僅此一份
62. 有代碼有真相
63. 擁有（及重構）構建腳本
1. 構建腳本也是代碼。它們如此重要以致於你最好本身親自來作
64. 結對編程，感覺流程
1. 在任務輪轉到另外一個結對以前，你沒必要非把它結束掉不可
2. 有告終對編程、合適的結對及任務的輪轉方式，新來者會很快認識代碼和其餘團隊成員
65. 特定領域類型賽過原始類型
1. 使用靜態類型語言的話，可以從編譯器那裏獲得一些幫助，而那些擁抱動態類型語言的人會更傾向於依賴他們的單元測試
66. 預防錯誤
1. 應該尊重用戶的偏好來輸入信息，而不是數據自己
2. 爲全部動做提供不一樣層次的撤消操做——尤爲是那些可能會破壞和修改用戶數據的操做
3. 用日誌記錄撤銷動做，而且加以分析，凸顯出界面的哪部分會誘導用戶犯下無心識的錯誤
67. 專業程序員
1. 在專業程序員身上惟一最重要的一點就是我的責任感。專業程序員對他們的職業、估算、承諾的日程、錯誤和技藝都勇於負起責任，從不會把責任推卸到別人身上
2. 若是你是一名專家，你就要對本身的職業負責，對閱讀和學習負責。你負責跟上這個行業和技術的發展。不少程序員都認爲這應該由僱主來給他們培訓。對不起，這錯得離譜
3. 對於多數項目而言，問題跟蹤系統的存在就是粗枝大葉的徵兆。只有巨無霸型的系統纔有bug列表，bug數量纔會大到須要自動化管理
4. 專家是能夠信賴的。他們對本身的職業負責，對代碼的正常工做負責，對他們技藝的質量負責。即使是最後期限迫近，他們也不會放棄原則。事實上，隨着壓力增大，專家會更加有條不紊，他們認爲這是正確的
68. 把一切都置於版本控制之下
1. 許多項目都有一個活躍的開發分支，以及一個或多個爲當前正在支持的已發佈版本所建立的維護分支
69. 放下鼠標，遠離鍵盤
70. 閱讀代碼
71. 讀懂人性
1. 相互理解的能力不是來自於共享的定義，而來自於共同的經驗和生活方式
72. 常常從新發明輪子
1. 若是對軟件開發中更深層次的東西一無所知，你就沒有足夠的能力創造出永恆之做
2. 從新發明輪子對於一個開發人員的教育和技能培養來講很重要，就像健美運動員練舉重同樣
73. 抗拒單件模式的誘惑
1. 單件是值得抗拒的：
1. 單一實例的需求一般都是想象出來的。在許多狀況下，它都是純粹的投機，認爲未來也不要更多的實例。在一個應用的設計裏傳播這種投機性，勢必致使在某些時候會很痛苦。由於好的設計會擁抱需求的變化，而單件不會
2. 在概念上獨立的代碼單元之間，會因單件引起潛在的依賴關係。該問題的存在既由於這種關係難於察覺，又由於它們在單元之間產生了沒必要要的耦合
3. 單件承載了不明顯的持久狀態，這會妨礙到單元測試。
4. 多線程會把更深的缺陷帶給單件模式。
2. 單件的清理最後會變成挑戰：
1. 對於明確的釋放單件可能沒有足夠的支持。例如，在一個插件架構中，一個插件只有全部對象清理乾淨以後再卸載纔是安全的
2. 沒有命令用於程序退出時隱含的清理單件。
3. 必須把你對單件模式的使用限制在那些只要實例化一次的類裏面。不要從任何代碼那裏來訪問單件的全局訪問點
74. 通向高性能之路佈滿了髒代碼炸彈
1. 在咱們努力創造乾淨的代碼過程當中，軟件度量會成爲一個威力強大的工具
75. 簡單來自於刪減
1. 挽回糟糕工做所耗費的時間會比預想的要多
2. 處置壞代碼的最好方法是完全轉變編程思路，堅持無情的代碼重構、移動或者刪除壞代碼
3. 代碼應該是簡單的，它只有最小數量的變量、函數、聲明和其餘一些語言必需的句法。額外的行、額外的變量……額外的一切，應該當即清除掉。那裏全部的，那裏保留下來的，應該恰好足夠完成任務、完成算法或者執行計算，除此以外的任何東西都是多餘的。意外引入的沒必要要噪音只會使得流程晦澀難懂，使得重要內容隱匿無蹤
76. 單一職責原則
1. 單一職責原則：把全部會爲同一個緣由而更改的東西聚集在一塊兒，把全部會爲不一樣理由而更改的東西獨立開來——優秀設計的最根本原則之一
77. 從Yes開始
1. 從yes開始實際上就是做爲一名技術領導的核心內容
2. 一般，你會發現只要你知道提出要求時的背景，就會找到其餘能夠用來回應要求的方法
3. 若是你能表述出一個使人信服的理由來講明爲何這個功能要求跟現有產品格格不入，那麼你就有可能就大家是否正在構建一個正確的產品進行一次破有建設性的溝通。不管此次溝通的結論是什麼，每一個人都會更加關注這個產品是什麼，以及不是什麼
4. 從yes開始意味着你要和你的同事們並肩做戰，而不是相互對立
78. 請轉回去作自動化、自動化、自動化
79. 充分利用代碼分析工具
1. 不要讓測試成爲質量保證的終點——充分利用現有的分析工具，也不要懼怕推出你本身的工具
80. 爲必需行爲測試，而不是偶發行爲
1. 測試的一個常見缺點就是與實現細節焊死在一塊兒，而這些細節都是偶然的，跟所要求的功能關係不大
2. 白盒測試用代碼結構來決定什麼是測試用例所須要的
81. 測試要嚴密而具體
1. 構造軟件設計的方式有兩個：一個是讓它足夠簡單，沒有明顯的缺陷；另外一個是讓它變得很是複雜，以致於看不出有什麼缺陷——Tony Hoare (快速排序的發明人，1980年得到圖靈獎)
82. 在睡覺的時候（或度週末的時候）進行測試
1. 將橫跨不一樣部門和團隊的服務器組成池，確保資源可以充分利用
83. 軟件開發的工程嚴密性來自測試
1. 測試是通向軟件可再生產性和高質量的真正途徑，咱們把回頭爭論是否要進行測試的行爲視爲極不專業的作法
84. 關於狀態的思想
85. 一人技短，二人技長
1. 僅僅做爲一名技術專家已經不夠了，你還必須高效的與其餘人一塊兒工做
86. 錯上加錯就是貌似正確（而且難以糾正）
87. 我寫代碼爲人人，人人爲我寫代碼
1. 創造軟件是技術活動和社會活動的混合
2. 咱們和每一個人一塊兒分擔着提升成功可能性的責任
3. 咱們不多不多會寫只給本身用的代碼
88. Unix工具是你的好朋友
89. 使用正確的算法和數據結構
90. 冗長的日誌會讓你睡不安枕
1. 太多的日誌等於沒有日誌
91. WET掩蓋了性能瓶頸
1. DRY - Don't Repeat Yourself
2. WET - Write Every Time
3. DRY能夠幫助咱們找出並修復性能瓶頸，這在WET代碼裏是很難發現的
92. 當程序員和測試人員開始合做的時候
93. 編寫代碼時要像餘生都要給它提供支持同樣
1. 你會發現多年前編寫的代碼依然影響着你的職業生涯，無論你是否樂意這樣。
2. 你的身後流下了一條鮮明的軌跡，其中蘊含你的知識、態度、主張、專業主義、誠意以及對於你設計編寫的每個方法、類、模塊的投入程度
94. 使用實例編寫小函數
95. 測試爲人而寫
96. 你應該關心你的代碼
1. 貧乏的技術基礎之上不會產生好的程序員
2. 好的程序員依賴於採用專業途徑，即便有現實世界的束縛和軟件工廠的壓力，也一直想着寫出最好的軟件
3. 與其餘程序員一塊兒和氣共事。沒有一個程序員是一座孤島。幾乎沒有程序員是單槍匹馬工做的；多數工做都是程序員抱團做戰的
4. 你要但願團隊有可能寫出最好的軟件，而不是讓你本身顯得很聰明
97. 心口不一的客戶
1. 不要簡單的用客戶的言辭來重申他們告訴你想要的是什麼。在與客戶談話過程當中，要換他們的言辭，而後從他們的反應裏判斷
2. 在交談中使用可視化目標有助於加大注意力的廣度，提升信息的保持率