閱讀筆記五

2022-07-25 02:24:07 字數 1933 閱讀 2581

兩個系統的比較,功能類似,但是結局不同。

這兩個系統特點有什麼不同?是什麼導致了不同的結局?

特點:微觀層面特點:

1. 沒有統一的概念將不同的部分組織起來

2. **風格不一致

3. 控制流無法**,即控制流的流向很複雜

4. 額外的資料快取,其目的讓資料停留在更方便的地方(但是,容易造成資料的不一致性,維護或擴充套件不方便)

5. 沒有人了解整個系統,沒有任何文件

巨集觀層面特點:

1. 系統沒有彈性,無法變更和新增新功能

2. 版本週期過長,低品質的軟體

3. 對第三方支援協議,涉及太多內部結構。會出現難以理解的、不容易復現的錯誤。

4. 團隊新成員不理解整個系統,不能搞請狀況,流失率高

原因:造成的惡果的原因:

1. 沒有清晰的需求。這個是專案開始之初,團隊就不知道要構建什麼。這個是混亂的乙個重要原因。

2. 系統結構難以理解,壞的架構設計只會招致更壞的設計(因為想解決問題,只能選用阻力最小的方法)

3. 缺乏內聚,不相關的功能放在一起,沒有清晰的角色定義

4. 不必要的耦合。系統沒有最底層,沒有控制中心,所有元件必須一開始就建立。這使得**層次的測試不能進行。

5. 沒有共同的**風格,沒有共同的庫,沒有共同的命名習慣。重複的**到處被使用。

6. 開發周期過長,造成整個系統測試、迭代困難,軟體質量沒***,這個即使惡果,又是原因之一

------------

而比較成功的設計,往往是乙個持續的過程,不僅僅表現為幾個特徵

如設計之城的各階段的特徵:

在設計早期:

1. 確定了主要的功能領域,並推出初步架構

2. 系統中各獨立部分的位置關係體現為傳統的分層結構。並且,這些是基本的系統設計,可以隨功能模組新增進行擴充套件。

3. 一些基本關注點的決定:

1) 頂層檔案結構

2) 如何對事物命名

3) 內部"展示"風格

4) 共同的編碼慣例

5) 選擇單元測試

6) 一些基礎設施的選擇(如版本控制、系統的構建與持續整合)

在第二階段,功能擴充套件:

1. 新**的定位

一開始就有系統結構清晰的總體檢視,所以,新的功能單元可以新增到正確的功能區域,而不是為了一時方便,**隨意新增。(這樣,有的時候開發者的工作會需要動寫腦筋,但是在系統維護和擴充套件時,就變得容易了)

2. 系統的一致性

頂層設計的良好風格和決定,為底層**好處,**是統

一、整潔的。清晰的定義,確保沒有重複的**、介面慣例和常見設計模式被普遍使用、沒有特殊生命週期的物件和資源管理問題。(這個重點是在於減少功能重複)

3. 架構增長

沒有什麼是一層不變的,架構應該是方便擴充套件、可重構的。這樣,**可以快速增長,同時又保持好的內部結構,新增新的功能不是問題。

4. 延遲設計決定

這部分應該是需求問題。yagni(如果不是馬上需要,就不要去做),早期只設計中要的部分,將餘下的決定推遲。特別是,不確定的需求,需要猜測。

5. 保持品質

結對程式設計、對**複審、單元測試。對不正確、不合適的變更都要拒絕。開發者需要對設計負責。

6. 技術債務管理

什麼是技術債務?為了趕時間,對於不太重要的功能被砍掉,允許小的**"瑕疵"存在,發布時避免高風險的改動。這些都應該被標記為技術債務。

應該選擇合適的時間,及時集中清理這些技術債務,在後續版本中修改。

7. 單元測試 打造設計

單元測試在很大程度上定性了**設計,它迫使我們實現好的結構,保證可測性。

8. 遵守設計

新的成員可以比較容易地拿起**開始工作。開發團隊動態地遵守架構設計,專案原則規定沒有人"擁有"某部分設計,而是所有人都應該寫出高品質的**,可以改動系統的所有地方。

未來:1. 沒什麼是一成不變的,在整潔的背景下,突出的技術爭論應該被解決掉。著重於適應性強的架構和靈活的**結構。

閱讀筆記五

軟體需求閱讀筆記五 軟體需求模式的第五章 基礎需求模式。這周閱讀的是軟體需求模式的第五章。基礎需求模式是所有種類的系統都可能需要的一些東西。基礎需求模式包括系統間介面需求模式,系統間互動需求模式,技術需求模式,遵從標準需求模式,參考需求需求模式,文件需求模式。系統間介面需求模式是定義於與其他系統的介...

閱讀筆記五

基礎需求模式 想必大家都聽過這樣一句話 再長的路,一步一步也能走完 再短的路,不邁開雙腳也無法到達。現在我對這句話是深有感悟,時間過的很快,不知不覺 軟體需求模式 這本書的第一部分已經讀完,第二部分已在進行中,這段時間的閱讀讓我學到了很多很多。以前,總覺得那麼厚還那麼無聊的書根本讀不進去,所以沒有認...

c primer plus閱讀筆記 五

cont time a a.show illegal 對於乙個const物件,無法確定呼叫成員函式show 是否會改變a的資料成員,所以將會報錯 為此,提出了const成員函式限定該函式無法修改當前物件的資料成員,如下 class time 對於運算子過載的成員函式來說,運算子左邊的為物件,運算子右...