浅谈软件设计过程中的可拓展设计

我正在参与掘金创作者训练营第6期，点击了解活动详情

可拓展的理解

可拓展本质上是关注软件的生命周期，解决的问题是 ———尽量避免或者推迟软件发展过程中的“垃圾进垃圾出”的晚期阶段。

可拓展分为技术方面和业务方面。

技术方面：可伸缩性

系统访问压力增加后，能够通过简单地增加更多的硬件设备以支撑访问压力。

技术方面的可拓展，主要为两个部分，既硬件/中间件/数据库等方面的弹性部署，和应用各种设计模式和设计原则的业务架构方面。

设计模式：GoF

设计原则：SOLID

业务方面：可拓展性

需求变化后，能够比较容易地扩展以支持新需求。

自己的理解

自己对可扩展的理解：

业务上的可拓展，可以大致划分为两部分，一部分是业务流程拓展新的业务场景，第二部分是业务流程因为业务场景变化进行的自拓展。

在适配不同业务场景的拓展时：

可拓展，类似于面向对象中的多态。

通过抽象，把某个业务流程提取出来，在整个流程中形成一个虚拟的类似于接口的过程

通过继承，把之前抽象的流程给具体实现，并根据相应的业务进行调整

在适配新的业务时，只需要根据业务类型去适配该抽象的流程即可。

在适配自拓展时：

主要对于现有整个流程的切分，做到整体业务流程上的切分，切分得到单一职责下的若干个子流程，这些子流程共同服务于整个模块的功能。（功能内聚）

在自拓展时，基于穿糖葫芦的原理，只需要修改某几个子流程，便可以做到最小代价实现业务需求

可行的步骤

1. 对业务现状进行摸排，包括但不限于业务流程、核心模块、模块职责、参与方，形成业务现状清单文档

2. 梳理技术债务，深入业务流程推演业务发展方向。技术债务代表系统发展过程中一些可拓展的点没有做到的地方，如果不着手安排治理，这些债务也会是未来的系统发展中可拓展实践一定会遇到的问题。而理解业务的发展方向，本质上就是做优先级排序。

3. 与需求方达成共识，将这些技术债务合理的安排进每个迭代中去。

4. 在具体的迭代中

   1. 基于业务演进，对大的改动作出合理的技术方案
   2. 技术方案要考虑业务上的拓展点，例如：关联需求、需求的演化方向。可以多跟需求方做沟通，需求的分类也遵循28定律，大部分的需求都是持续演进和迭代的，我们重点关注这部分的可拓展性
   3. 编码过程中，遵循开发原则
   4. 编码结束后，需要对技术方案进行Double Check，要求方案和代码实现尽量一致（出现偏差可视情况决定改方案还是改代码）

5. 记录完成情况，做数据总结，通过数据计算ROI，并反馈到下一次迭代做决策参考。