架构整洁之道(六)-设计一个好维护的软件

一、背景知识

1. 简单复习一下前面的知识点。

   • 软件架构设计十分重要。否则随着时间推移软件会变得无法维护。

   • 怎么就算好？能够降低维护成本，并且能长期维持低成本。这就要程序员每次改代码少做决策，少修改代码。

   • 这就要求现在的代码解耦合+易复用。

   • 其实只要解耦合，往往就容易复用。

   • 所以，好的软件架构要做好三件事，解耦，解耦，还是特么的解耦。

   • 解耦合的过程中，往往要使用函数指针。函数指针应该在约定好的情况下，小心使用。因为整个面向对象编程对架构最重要的，就是限制函数指针的使用。

二、设计步骤

1. 分模块。 先将目标分解成若干个模块。

2. 找变化。 确定哪些模块是和业务流程相关的，可能要经常变化的。哪些是不怎么变的。

3. 定接口。 找到不变的模块，设计好他们的数据结构。

   设计好数据结构之后，定义好API，加上注释描述这些接口是干嘛的。

4. 推整体。 使用各个模块的API，推导能否完整的构造程序。适当调整。

5. 常变模块，数据驱动。 找到可能要经常变化的模块，再次想办法把不变的部分分割出来。

   给不变的部分封装成API。

   变化的部分，尽可能使用数据来表示，或者使用配置表示。数据与逻辑分离，策略和机制分离。 尽可能将变化使用数据的方法表达出来。

6. 完善接口，单元测试。 搭建好框架后，真实的实现API。完善数据结构。这样写也特别好测试。

三、设计原则

1. 函数指针，规范使用。 函数指针需要按照所有程序员共同的约定使用。否则，就仿佛到处使用goto一样，让代码难以理解，难以找到bug。是通过面向对象的编程范式整理出来的。

   参考第四篇。

2. 变量赋值，入口唯一。 变量的赋值，应该尽可能控制在模块的入口处，统一处理。如果赋值的地方被分散开来，就会变得特别难以维护。是通过函数式编程范式整理出来的。

   参考第四篇。

3. 紧凑正交，solid原则。

   紧凑性，是希望一个模块，一个函数，包含的信息点，尽可能保持在人类的认知能力范围内。一般模块维持在400-800物理行。结构体成员，API数量，最好在7-2到7+2.

   不要有超大函数。

   参考之前第五篇。

   正交性，不要用全局变量。一个模块内，不要操作其它模块的数据结构。事实上，单一职责原则，依赖倒置原则，接口隔离原则，开放封闭原则，都是为了正交性。

四、案例

1. 我想实现一个电话本的功能。电话本所有的成员可以被显示，每个成员可以被选中操作。可以在gui界面增删改查。

   • 分模块。

     1. 电话本数据操作模块。

     2. 电话本用户操作控制模块。

     3. 电话本成员显示模块。

     ----实际情况可能还能继续细化。要根据实际情况来看。

   • 找变化

     1. 数据操作，无非是增删改查。其实变化不大。

     2. 用户的操作控制模块，是可能有很多需求变化的。因为和用户沾边。比如，希望操作的时候，除了姓名，电话，还要加个邮箱操作。

     3. 电话本成员显示。这个假设是不怎么变化的。<—说的是样式不怎么变化了。样式的变化放在配置文件中，一旦定了，一般不会有太多变化。一般都是，选择框，下拉框，输入框，对话框等。

   • 定接口

     1. 数据操作，需要有增删改查的接口。

     2. 电话本成员的显示。根据具体情况定。比如，获取当前窗口显示的所有条目。获取当前选中的条目。获取当前屏幕最大显示多少行。获取当前条目的号码显示的是多少。获取用户名叫什么等。

        显示的元素根据具体情况定。

        将API写出来，加上注释。

   • 推整体。

     使用当前给出的API，能不能正常的显示和操作呢？

   • 常变模块，数据驱动

     对于用户操作模块，是经常可能变化的。最好再次细分到底什么地方更容易变。将变化的部分放到一个数据表里。

     比如要加邮箱的操作：

     你可能就要写成

     {“号码”,fnAction1}

     {“邮箱”,fnAction2}。

     用表格的方法，不断可以扩展各种需求增加的时候的变化。或者说，号码的操作方式要有所变化，直接换掉对应的处理函数。总之，就是要找到变化的部分，尽可能把变化的部分控制在这小范围中。

     像策略模式一样，让其可变。

     不变的部分继续留出接口。

   • 接口实现，单元测试。

     经过上面的操作，框架就搭建起来了。接下来，就是面向接口编程。

2. 再统一代码的命名风格，书写规范。

3. 坚持设计的原则。这样就可以写出容易维护的代码。