讀書筆記 《修改軟體的藝術》

最近讀了《修改軟體的藝術》一書，這本書講述了作者對關於如何寫比較容易維護**的的經驗，並把他們整理成了 9 條實踐方式。

它們分別是

這9條實踐可以隨意跳著看，雖然它們有前後順序，但是不按順序看，不影響對他們的理解。

總的來說，這本書對有幾年程式設計經驗的人有一定的啟發。裡面有的有些實踐可以在日常編碼的過程中實行。依據對它們的理解，我做了相應的筆記，以及自己的一下想法。

其中引用格式部分是我自己看法。

引用

3.最後實現設計

3.2 編寫可持續性**的注意事項

3.3 意圖導向程式設計

3.4 降低複雜度

5.重構遺留**

重點摘要

軟體開發者需要領域建模，這就是需要我們去學習領域設計的知識；

開發者需要在善於提出沒人想過的問題。這就要要去需要在需求評審的時候提出，多問產品為什麼需要這樣？出發點是什麼？

內聚內聚就是每個片段都只關注一件事，乙個類應該只有乙個目的；

不同層次的抽象可以幫助我們對元件的關係建立起大局觀，也可以讓我們可以只在需要的時候關注細節。

**的層次從高往下應該是從抽象 -> 實體

鬆散耦合

鬆散耦合的**不直接依賴它所使用的**，而是通過乙個中間層來呼叫；

意外耦合是缺乏優質**特質的一種體現

鬆散耦合的**讓實體之間的***更少，而且更容易測試、復用、擴充套件

封裝良好

高質量的**是封裝良好的，它隱藏了實現細節

封裝就是：讓做什麼，隱藏如何做

封裝良好的軟體是由外而內而不是由內而外設計的。

在用物件來實現系統的時候，讓每個物件自身和所處的環境複製，系統中的每個物件都有自己的用途

預設封裝，必要時再暴露

面向介面程式設計，而不是面向實現程式設計

封裝良好的**有助於我們管理複雜度，讓呼叫者不必關係被呼叫者的實現細節，所以更容易修改

**自主

**自主，是指讓它自己管理自己的職責，不應該互相干預。

自主的原則是:

資料和控制邏輯要分開

沒有冗餘

軟體不應該自我複製，要沒有冗餘

沒有冗餘的**以為這我們可以只在乙個地方修復 bug 和進行更改

3.1 阻礙了可修改**的產生

在實現設計之前，需用明確是什麼阻礙了可修改**的產生

缺乏封裝

一部分**對另一部分 「知道」 得越多，則依賴越重，無論顯示的還是隱式的

濫用繼承

少用繼承，多用組合

僵化的實現

當缺乏抽象的時候，兩個或多個行為之間會有太多的共同性，導致冗餘和非必要的複雜性，讓**難以使用。僵化的實現難以修改，難以在日後新增新的差異性

內聯**

沒有正常阻隔一拉

3.2 編寫可持續性**的注意事項

這個規則是在平時寫**的時候容易被忽略的，需要重視

意圖導向程式設計是指，將所有公用介面的**都委託到不同的方法中，就可以消除這些重複工作。這樣**讀起來就像一段指令碼或乙個選單，因為它保持同樣抽象層次。

在寫公用的應用程式介面、方法，或者暴露給外部的其他服務，不要在那個方法中放入任何實現。而是將其委託給其他方法。

3.4 降低複雜度

乙個條件（if）語句的複雜度是 2， 兩個 if 語句就是的複雜度是4， 這種複雜度是指數型增長的。複雜度越高，越容易出現 bug 所以要降低複雜度

降低複雜度的手段一般有多型，將條件語句的建立放在物件的建立階段而不是使用階段

以下內容來自極客時間的專欄 《左耳聽風》，第 38| 程式設計正規化遊記（9）程式設計的本質

任何演算法都會有兩個部分，乙個是 logic 部分，這是用來解決實際問題的。另乙個是 control 部分，這是用來決定用什麼策略來解決問題。logic 部分是真正意義上解決問題的演算法，而 control 部分只是影響解決這個這個問題的效率。程式執行的效率問題和程式的邏輯其實是沒有關係的。我們認為，如果將 logic 和 control 部分有效地分開，那麼**就會變得更容易改進和維護

有效分離 logic 、control 和 data 是寫出好程式的關鍵所在

logic 是程式複雜度的下限，然後，我們未來控制程式，需要再搞出很多控制**，於是 logic + control 的相互交織成為了最終程式的複雜度

分離 logic 和 control

dsl

程式設計正規化

程式設計的本質：

重構是指在不改變外部行為的前提下對**的內部結構進行重組和重新包裝

怎樣重構

1.只要**執行沒有問題，就不要去修改它，能正常執行，就不用重構

2.只有在那些要修改、新增新功能的**，才進行重構

3.重構的時候要遵循漸進式、小步修改的原則

《軟體測試的藝術》讀書筆記（上）

一 測試的目的。測試是為發現錯誤而執行程式的過程。乙個成功的測試用例 是發現程式中存在錯誤的測試用例。二 測試用例設計的原則 1 測試用例中乙個必需部分是對預期輸出進行定義。2 測試用例的編寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況。3 檢查程式是否 未做其應該做的...

讀書筆記 軟體人才 管理的藝術

圖靈之前送了兩本書，一本是 軟體人才 管理的藝術 還有一本書 黑客與畫家 這幾天把第一本書看完了，雖然有些章節不是那麼好，但總體上來說還是不錯的，所以才有下 本書適合it敏捷個人，適合所有it人員閱讀，而並非只是管理者 我們每個人都有領導，無論你是技術管理者，還是走專業路線，你的工作之一，就是弄明白...

讀書筆記 軟體人才 管理的藝術

圖靈之前送了兩本書，一本是 軟體人才 管理的藝術 還有一本書 與畫家 這幾天把第一本書看完了，雖然有些章節不是那麼好，但總體上來說還是不錯的，所以才有下 本書適合it敏捷個人，適合所有it人員閱讀，而並非只是管理者 我們每個人都有領導，無論你是技術管理者，還是走專業路線，你的工作之一，就是弄明白你的...