【软件工程】软件架构的通用方法

软件架构命题比较大，需要考虑的因素非常多，例如功能、性能、稳定性、扩展、重用。如果每个软件在设计阶段能把所有方面考虑到，可能不需要维护兄弟不断吐槽。

敏捷开发将可以运行的软件重要性定义在完善的文档之上，有点夸张了。没有完善的文档，开发的兄弟等着维护烦死你吧。

这篇博客目标不是为了详细描述各种架构的差异、架构的已有模式、框架等等，我的主要目的是总计一些开发的实践。好的实践，可以在每个阶段看到软件逐渐成型，可以支持测试兄弟早期接入、可以让维护兄弟提前知道系统哪些点可以看到，在什么情况下如何响应。

1、分析目标

承认做网站的现在非常主流，但是软件确实有很多种，而且绝大多数用户是感觉不到软件的存在，尤其是在嵌入式领域。极端情况下例如教学，可以不考虑架构，写一行helloworld没什么重用性。但是稍微复杂一点的软件，尤其是在商用开发的时候，软件开发一定要考虑如何测试、如何上线、怎么扩展、怎么维护。在生产环境，出现了异常如何处理，要增加新的功能要如何操作。

（1）通过story获取软件片段

无论如何，第一步都是分析软件要达成的目标，例如显示网页，笔者最常用的是数据驱动型的设计，实际上，大部分系统也可以用这个办法抽象。

数据1：原始数据，可以是文件、操作数、配置数据、记录等。操作1：各种加工包括常用的增删改查、映射等。输出1：输出到用户界面、输出到磁盘、输出到播放设备的数据格式。

例如数据为界面上面获得的用户名、工号、邮箱、电话，操作为用户的提交（从story获得）动作，输出为数据库1 employee表。

通过和客户的不断接触总结，将形成大量的基本片段，这个片段的总和就是要设计的软件。

（2）抽象子系统

上图省略了操作，实际绘制的时候可以合并到数据。通过第一步，系统中通用的部分逐渐划归子系统，各个子系统要求高内聚低耦合。。。最终设计出包、库、类、代码文件。

（3）增加必要的子系统

作为商用软件，如果不是一次开发只使用一次，一般都要增加完成各种任务的子系统。

前两步都是业务处理子系统的整理，这次在图中简化描述，一般作为商用系统肯定是不够的，图中增加了几个必要的子系统。

日志系统记录系统运行过程中的状态，运维阶段非常重要的手段，商用系统一定要有。自动测试代码一般不发布，但是在开发过程中比不可少，尤其是敏捷中增加新功能story时可以检测代码可用性。维护操作系统可以动态配置某些功能开关、可以模拟实际业务有助于缩短系统定位恢复时间。系统检测分散在不同业务模块、服务器中，定时检测业务通断（心跳）、系统健康状态（磁盘剩余、CPU占用率、网络带宽等）、发布打包系统将各个子系统独立打包作为后续应用的库。

通过上述步骤软件产品的基本架构就基本定义好了，注意发布前要和测试、运维、销售等多个部门有足够的沟通，千万不要出现代码开发了一大半改架构的情况，劳民伤财啊！

2、收集分析类似产品

对同样的业务逻辑，有哪些类似产品？针对每个产品，有哪些用户在使用，反馈怎么样，尤其是有哪些方面是要重点改进的。

针对子系统，查找开源库有没有可以实现大部分功能的，每个子系统要收集3个备选方案。软件产品最重要的好处就是可以重用，所以最理想的状态是安装已有的软件，按照业务要求配置完成即可满足功能需求。其次的状态是各个子系统有成熟的方案、框架，但是自己要开发部分功能，预先要了解有哪些功能需要开发，工作量有多少。

按照上述表格整理的文档包括PPT、对比测试报告等，是多个部门沟通的基础，只有做了对比才能更容易获得公司的认可。

3、快速搭建原型

开发的第一个版本往往要有所取舍，如果采用快速原型，则可以在真正发布前提前体验一个差不多的。

搭建的原型主要是给客户演示，不用对所有场景有响应，只要能说明情况即可。最简单的原型只要用文档描述即可，但是建议还是要有一定的交互，可以百度一下“产品经理快速原型工具”。

客户认可系统的功能后，要快速开发一个可用的系统，作为产品的第一个版本，当然第一个版本只有部分功能，并且效率、容量等指标可能不满足。

4、功能模块替换

根据人力，灵活安排子系统的逐个替换，例如数据库由本地一个表扩展为多个表，由单个服务器扩展到多服务器，增加备份、主备系统等。每个开发阶段能让客户看到系统的逐步改进，比让客户等半年再一次接受仍然有缺陷的系统，好很多。（这有点像卖东西，大家都喜欢先少称点再逐渐增加，不喜欢称多了再往下减）

这个方法确实增加了部分工作量，但是和客户的更多互动，也让客户有更多信心。

5、持续开发

按照上面的步骤如果能走到这里，而没有收到预算什么莫名其妙原因的影响，系统将进入一个稳定开发阶段，项目组成员的工作习惯、特长等也都磨合好了。接下来，不断的查找用户不满意的地方，通过提升性能、容量、并发、稳定性、增加功能，一个项目可以持续进账了：）