文章目錄

• 前言
• 僵化性（Rigidity）
• • • 原文
    • 我的理解
• 脆弱性（Fragility）
• • • 原文
    • 我的理解

---

前言

最近讀Robert C. Martin（Bob大叔）的書《敏捷軟件開發(fā)》，準備圍繞這本書開一個專題來寫點讀書總結(jié)。本文是這個專題的第一篇。

設(shè)計模式有六大原則：單一原則；里氏替換原則；依賴倒置原則；接口隔離原則；迪米特原則；開閉原則。軟件腐化可以理解為是設(shè)計模式六大原則的對立面。

當軟件出現(xiàn)以下七種特征之一時，就說明軟件正在腐化：僵化性（Rigidity）、脆弱性（Fragility）、牢固性（Immobility）、粘滯性（Viscosity）、不必要的復(fù)雜性（Needless Complexity）、不必要的重復(fù)（Needless Repetition）、晦澀性（Opacity）。

---

僵化性（Rigidity）

原文

很難對系統(tǒng)進行改動，因為每個改動都會迫使許多對系統(tǒng)其他部分的其他改動。

我的理解

僵化性（Rigidity）和下面講的脆弱性（Fragility），都是在操作公用資源或者調(diào)用公用方法時最常見，當我們對系統(tǒng)進行改動時，所需改動的內(nèi)容已經(jīng)和已有內(nèi)容發(fā)生耦合。

---

脆弱性（Fragility）

原文

對系統(tǒng)的改動會導致系統(tǒng)中和改動的地方在概念上無關(guān)的許多地方出現(xiàn)問題。

我的理解

以我現(xiàn)在項目的架構(gòu)為例：數(shù)據(jù)庫直接為 Web后端（使用.NET開發(fā)） 和 數(shù)據(jù)分析端（使用Python開發(fā)） 兩者提供服務(wù)，換句話說， Web后端 和 數(shù)據(jù)分析端 都是直接訪問和維護數(shù)據(jù)庫。但是，當我們在 Web后端 里使用ORM映射數(shù)據(jù)庫時，造成了一些耦合，這將影響到 數(shù)據(jù)分析端 對數(shù)據(jù)庫的訪問和維護。

下面是使用微軟的ORM框架創(chuàng)建數(shù)據(jù)庫時，所遇到的兩種場景。

場景1：

場景2：

場景1采取 CodeFirst模式（代碼優(yōu)先模式） ------先創(chuàng)建Web后端模型層代碼，然后通過Web后端模型層代碼自動生成數(shù)據(jù)庫并完成映射；場景2采取 DBFirst（數(shù)據(jù)庫優(yōu)先模式） ------先創(chuàng)建數(shù)據(jù)庫，然后通過數(shù)據(jù)庫來生成Web后端模型層代碼并完成映射。

場景1中，數(shù)據(jù)庫由 Web后端開發(fā)工程師 獨自維護（因為數(shù)據(jù)庫由EF代碼生成而來），此場景下， 數(shù)據(jù)分析師 如果想要在數(shù)據(jù)庫里修改表結(jié)構(gòu)，需要去找 Web后端開發(fā)工程師，由 Web后端開發(fā)工程師 先修改EF模型層代碼，然后再把改動映射到數(shù)據(jù)庫上去。但是在實際工作過程中， 數(shù)據(jù)分析師 經(jīng)常忘了這樣去做，而是自己直接去修改數(shù)據(jù)庫，這就會造成 Web后端模型層代碼 和數(shù)據(jù)庫映射時對不上，Web后端的代碼就會發(fā)生一些莫名其妙的Bug。所以，選擇使用 CodeFirst模式 ，在我們實際項目的場景中就產(chǎn)生了 脆弱性（Fragility）。

為了解決上述 脆弱性（Fragility） 問題，我們選擇用場景2的 DBFirst模式 去替代場景1的 CodeFirst模式 。數(shù)據(jù)庫由 后端開發(fā)工程師 和 數(shù)據(jù)分析師 共同維護，每次Web后端在使用數(shù)據(jù)庫前，從數(shù)據(jù)庫往 Web后端模型層 手動更新一遍即可，由 數(shù)據(jù)分析師 所做的數(shù)據(jù)庫改動就將同步更新到 Web后端模型層 中。

---

總結(jié)

以上是生活随笔為你收集整理的软件腐化的七个特征之僵化性和脆弱性（设计模式原则的反面） （《敏捷软件开发》读书总结第一篇）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。