程式碼整潔之道閱讀筆記_第3次
第13~17章
13、併發程式設計：單一權責原則、儘可能減小同步區域、限制資料作用域、有些java類不是執行緒安全，測試執行緒程式碼。由於對併發程式設計應用不多，只是簡單的理解為以上幾點。
14、逐步改進：漸進不改進之名大動其結構保持可執行、測試驅動開發
15、JUnit內幕：以例項描述JUnit程式碼整潔之道
16、重構SeriaDate：作者例項重構jfree.org一個開源的類SeriaDate
17、味道與啟發：作者總結從註釋、環境、函式、一般性問題、java、名稱、測試7個小項程式碼整潔之道。
哈哈，看了300多頁內容，附錄沒去看了，感覺被17章暴擊了，但還是看內容比較好。
第一次寫閱讀筆記主要是強化下一次閱讀消化能力。
最後加一句，漂亮好看也是生產力，程式碼如此武器也如此
相關推薦
程式碼整潔之道閱讀筆記_第3次
第13~17章 13、併發程式設計：單一權責原則、儘可能減小同步區域、限制資料作用域、有些java類不是執行緒安全，測試執行緒程式碼。由於對併發程式設計應用不多，只是簡單的理解為以上幾點。 14、逐步改進：漸進不改進之名大動其結構保持可執行、測試驅動開發 15、JUni
程式碼整潔之道 讀書筆記 - 第3章 函式
短小 函式的第一規則是要短小。第二條規則是還要更短小。 函式20行封頂最佳。 if語句、else語句、while語句等，其中的程式碼塊應該只有一行，而且，塊內呼叫的函式擁有較具說明性的名稱，還能起到文件的作用。 只做一件事 函式應該做一件事。做好這件事。只做這一件事。 每個函式一個抽象層級 自頂
程式碼整潔之道 讀書筆記 - 第5章 格式
垂直格式 1、推薦單檔案200行程式碼左右，最長不超過500行。 2、每一組思路完整的程式碼，中間用空白行區隔。 3、緊密相關的程式碼應該互相靠近。 4、本地變數和實體變數應該在類的頂部宣告。 5、概念相關的程式碼應該放在一起，相關性越強，距離越短。 6、自上向下展示函式呼叫依賴順序。被呼叫的函式
程式碼整潔之道 讀書筆記 - 第6章 物件和資料結構
資料結構、物件的反對稱性 物件（物件式程式碼）曝露行為，隱藏資料。便於新增新物件型別而無需修改既有行為，同時也難以在既有物件中新增新行為。 資料結構（過程式程式碼）曝露資料，沒有明顯的行為。便於向既有資料結構新增新行為，同時也難以向既有函式新增新資料結構。 在任何系統中，我們有時會希望能夠靈活地新增新資
程式碼整潔之道 讀書筆記 - 第8章 邊界
1、使用第三方程式碼，如果使用邊界介面，就把它保留在類或近親類中。避免從公共API中返回邊界介面，或將邊界介面作為引數傳遞給公共API。 2、瀏覽和學習邊界，不要在生產程式碼中試驗新東西，而是編寫測試來遍覽和理解第三方程式碼。Jim Newkirk把這個叫做學習性測試。 3、學習性測試的好處不只是免費，能
程式碼整潔之道 讀書筆記 - 第10章 類
類應該短小 1、單一權責原則（SRP） 系統應該由許多短小的類而不是少量巨大的類組成。 每個小類封裝一個權責，只有一個修改的原因，並與少數其他類一起協同達成期望的系統行為。 2、內聚 類應該只有少
程式碼整潔之道讀書筆記--函式
好函式的需要滿足： 1. 短小: 經過漫長的試錯，經驗告訴我，函式就該小。 一個強制性的原則是，程式碼長度最好20行封頂。 2.程式碼塊和縮排: if、else、while語句等，其中的語句只有一個，就是一個函式呼叫語句；
程式碼整潔之道讀書筆記--物件和資料結構
1.過程式程式碼VS面向物件程式碼 過程式程式碼便於在不改動既有資料結構的前提下新增新函式。面向物件程式碼便於在不改動既有函式的前提下新增新類。 反過來說： 過程式程式碼難以新增新資料結構
程式碼整潔之道讀書筆記--註釋
註釋的恰當用法是彌補我們在用程式碼無法表達意圖是遭遇的失敗。注意，我用來“失敗“一次。我是說真的。我們總無法找到不用註釋就能表達自我的方法，所以總要有註釋，這並不值得慶賀。 程式設計師應當負責將註釋保持在可維護、有關聯、精確的高度。我同意這一說法
程式碼整潔之道讀書筆記--類
1.類的組織 遵循標準的Java約定，類應該從一組變數列表開始。如果有公共靜態常量，應該先出現。然後是私有靜態變數，以及私有實體變數。很少會有公共變數。 公共函式應跟在變數列表之後。把由某個公共函式呼叫的私有工具函式緊隨在該公共函式後面，這符合了自頂向下
程式碼整潔之道讀書筆記——第二章：有意義的命名
第二章 有意義的命名 2.1 介紹 在軟體開發中，我們各種命名，不斷的命名，有這麼多的命名，一定要做好它！ 2.2 名副其實 選個好名字要花很多時間，而且對於我們中國的程式設計師來說，選一個好的英文名字更要精挑細選，但是省下來的時間遠比花掉的多，一個名稱基本就答
程式碼整潔之道讀書筆記——第一章：整潔程式碼
軟體質量，不僅僅依賴於專案架構和專案管理，同樣重要的是程式碼質量！！！ 序 神在細節之中，其實幹什麼事都一樣，從小到大，一直明白一個道理：細節決定成敗！ 軟體架構在開發中佔據重要地位。其次，巨集達建築的最細小的部分，比如關不緊的門、有點沒鋪平的地板，甚至是凌亂的桌
我讀-程式碼整潔之道---讀書筆記整理
第一章 整潔程式碼 "我可以列出我留意到的整潔程式碼的所有特點,但其中有一條是根本性的,整潔的程式碼總是看起來像是某位特別在意他的人寫的.幾乎沒有改進的餘地,程式碼作者設麼都想到了,如果你企圖改進它,總會回到原點,讚歎某人留給你的程式碼" ---Michael Feat
程式碼整潔之道-第2章-有意義的命名-讀書筆記
第 2 章 有意義的命名 15-28 2.1 介紹 文章列出取個好名字的幾條簡單規則。 2.2 名副其實 程式碼的模糊度：即上下文在程式碼中未被明確體現的程度。 2.3 避免誤導 程式設計師必須避免留下掩藏程式碼本意的錯誤線索。應當避免使用與本意相悖的詞。 提防使用不同之處較小的名
《程式碼整潔之道》學習筆記一（前三章）
我們都曾經瞟一眼自己親手造成的混亂，決定棄之於不顧，走向新的一天。 我們都曾經說過有朝一日要回頭清理。 當然，那是我們都沒聽過勒布朗法則：稍後等於永不（Later equals never）。 隨著混亂的增加，團隊的生產力不斷下降，趨向於零。 假如你是位醫生，病人請求你
斷舍離 ——《程式碼整潔之道》讀書筆記
注：只看了書的前十章 第一章 為什麼要整潔程式碼 1、程式碼永不消失 程式碼就是銜接人腦理解需求的含糊性和機器指令的精確性的橋樑。哪怕未來會有對現在高階程式語言的再一次抽象——但這個抽象規範自身仍舊是程式碼。 所以既然程式碼會一直存在下去，且自己都幹了程式設計師這一行了，就好好的對待它吧。 2、讀遠比寫
《程式碼整潔之道》讀書筆記
最初我喜歡這本書可能是因為非技術方面的原因，這本書中有很多我喜歡的插圖。這本書的第一章的第一句話是這樣說的：讀這本書通常有兩個原因：1. 你是一名程式設計師。2. 你想成為更好的程式設計師。我們需要更好的程式設計師。 這本書的每一章都可以總結出一句話，其實每章開始的
[學習筆記] 《程式碼整潔之道》（一）
[學習筆記] 《程式碼整潔之道》—第1章 整潔程式碼 程式設計：將需求明確到機器可以執行的細節程度 —> 程式碼 保持程式碼整潔：讓營地比你來時更乾淨！ [學習筆記]《程式碼整潔之道》—第2章 有意義的命名 名副其實 說起來簡單，但這是很嚴肅的事！
[學習筆記] 《程式碼整潔之道》（三）
[學習筆記] 《程式碼整潔之道》—第4章 註釋 什麼也比不上放置良好的註釋來的有用！ 什麼麼也比不上亂七八糟的註釋更有本事搗亂一個模組！ 什麼也不會比陳舊、提供錯誤資訊的註釋更有破壞性！ 註釋的恰當用法是彌補我們程式碼表達意圖時的失敗。 註釋總
程式碼整潔之道 第9章 單元測試
1.TDD三定律 定律一 在編寫能通過的單元測試前，不可編寫生產程式碼 定律二 只可編寫剛好無法通過的單元測試，不能編譯也算不通過 定律三 只可編寫剛好足以通過當前失敗測試的生產程式碼 這樣寫程式，我們每天就會編寫數十個測試，測試將覆蓋所有生產程式碼。測試程式碼