软件腐化的七个特征之僵化性和脆弱性（设计模式原则的反面） （《敏捷软件开发》读书总结第一篇）

前言

最近读Robert C. Martin（Bob大叔）的书《敏捷软件开发》，准备围绕这本书开一个专题来写点读书总结。本文是这个专题的第一篇。

设计模式有六大原则：单一原则；里氏替换原则；依赖倒置原则；接口隔离原则；迪米特原则；开闭原则。软件腐化可以理解为是设计模式六大原则的对立面。

当软件出现以下七种特征之一时，就说明软件正在腐化：僵化性（Rigidity）、脆弱性（Fragility）、牢固性（Immobility）、粘滞性（Viscosity）、不必要的复杂性（Needless Complexity）、不必要的重复（Needless Repetition）、晦涩性（Opacity）。

僵化性（Rigidity）

原文

很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其他改动。

我的理解

僵化性（Rigidity）和下面讲的脆弱性（Fragility），都是在操作公用资源或者调用公用方法时最常见，当我们对系统进行改动时，所需改动的内容已经和已有内容发生耦合。

脆弱性（Fragility）

原文

对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

我的理解

以我现在项目的架构为例：数据库直接为 Web后端（使用.NET开发） 和 数据分析端（使用Python开发） 两者提供服务，换句话说， Web后端 和 数据分析端 都是直接访问和维护数据库。但是，当我们在 Web后端 里使用ORM映射数据库时，造成了一些耦合，这将影响到 数据分析端 对数据库的访问和维护。

下面是使用微软的ORM框架创建数据库时，所遇到的两种场景。

场景1：

场景2：

场景1采取 CodeFirst模式（代码优先模式） ------先创建Web后端模型层代码，然后通过Web后端模型层代码自动生成数据库并完成映射；场景2采取 DBFirst（数据库优先模式）------先创建数据库，然后通过数据库来生成Web后端模型层代码并完成映射。

场景1中，数据库由 Web后端开发工程师独自维护（因为数据库由EF代码生成而来），此场景下，数据分析师如果想要在数据库里修改表结构，需要去找Web后端开发工程师，由 Web后端开发工程师先修改EF模型层代码，然后再把改动映射到数据库上去。但是在实际工作过程中，数据分析师经常忘了这样去做，而是自己直接去修改数据库，这就会造成Web后端模型层代码和数据库映射时对不上，Web后端的代码就会发生一些莫名其妙的Bug。所以，选择使用 CodeFirst模式 ，在我们实际项目的场景中就产生了脆弱性（Fragility）。

为了解决上述 脆弱性（Fragility） 问题，我们选择用场景2的DBFirst模式去替代场景1的CodeFirst模式。数据库由后端开发工程师和数据分析师共同维护，每次Web后端在使用数据库前，从数据库往Web后端模型层手动更新一遍即可，由数据分析师所做的数据库改动就将同步更新到 Web后端模型层中。