浅谈架构设计

浅谈架构设计

 

        大家经常会提到一个词叫“架构设计”，有些人认为架构设计就是技术架构；提出了若耦合强内聚，有些人认为架构设计就是把时下最流行的三大框架拼起来加上些功能；有些人认为架构设计是用一些高深的技术拼装起来一个扩展性最高、安全性最好的程序架构；而我理解的架构设计，是针对当前的使用人员、产品（项目）目标、未来规划三个方面制定出的最合适的设计开发标准、设计开发流程和技术框架。

    那么什么是好的架构设计呢？

    先说架构设计的目的吧……我们在开发过程中，经常会遇到几个问题：

    1、           开发人员的经验不足，并且一直在重复的造轮子，太多的个性化开发。

    2、           可重用功能的支撑力度不够，经常被动的出一些临时性方案。

    3、           架构设计不完善，很多新的需求无法满足。

    4、           技术架构文档缺失，沟通成本高。

    而这些问题将直接导致产品（项目）开发效率低、产品（项目）质量低和产品（项目）后期维护成本高。

    这就是架构设计要解决的问题，也是架构设计的目标。采用前沿技术也好、随便搭出来一套也罢，能够解决开发效率和维护成本的问题，就是好的架构设计。

    那么想做好架构设计，要做的事情有哪些呢？

    架构设计，要贯穿于整个产品和项目的研发周期。在前期的需求分析阶段，架构设计应该对业务画面草图设计提出设计规范；在功能设计阶段，架构设计要对功能设计的实现方案抽象；在框架开发的时候，要将框架的设计思想和技术方案共享出来。

    业务设计规范

    业务设计有多种展现形式，包括业务模式图、业务架构图、功能架构图等等，不过真正能够和研发讨论的落地设计，就是画面设计了，而画面的设计，就要遵循架构设计的标准，标准有三个，分别是布局规范、业务处理过程规范和人机交互规范。

    布局规范需要在业务设计时尽量利用已有的布局方案，这不仅可以让画面展示更加统一，同时容易让使用者快速形成使用习惯，无论在哪个画面，都可以快速定位自己想要看到的东西，而非常关键的，是可以节约开发成本，降低维护成本。

    业务处理规范需要在业务设计时尽量利用成熟的统一的处理过程，例如表单修改后会自动刷新列表，那么尽量让所有业务类似。若没有特殊和非常必要的需求，不要把业务处理过程太过个性化。这样既可以加速业务设计的过程，同时也可以降低同研发人员的共同成本。

    人机交互规范需要在业务设计时尽量遵循已有的人机交互规范，例如如何新建，如何删除某条记录等等。这样可以让使用者缩短学习周期，更加容易上手操作各个功能，同时可以简化功能设计。

    详细设计抽象

    详细设计主要是填充画面的内容和数据的过程，在这个过程，架构师要全程参与，并对画面、事件处理和画面初始化进行抽象，最大化的提取出可重用部分进行封装。

    抽象画面

    在画面内容填充过程中，总有些画面的内容是类似的，例如常见的查询结果显示类型，画面主体部分上面是查询表单，下面是结果列表。该类画面可以抽象出一个模板，以后有新的画面时直接继承该模板即可。

    抽象事件处理

    在画面中的链接或者按钮执行时，该事件的处理过程虽然内容不同，但同样有共通和可重复使用的内容。例如每次关闭打开的窗口时，主窗口内容刷新。还有保存的时候我们经常要做各种校验规则，这些都可以抽象出一个个单独的实现组件，在每次调用时均执行这个过程。抽象事件处理就是对事件执行过程的一个抽象，规范了某类事件处理必须要完成的几个点。

    抽象初始化过程

    每个画面在最初展示的时候，都需要做一些处理，有些处理简单，有些处理复杂，例如在包含树的画面在最初展示的时候要默认选中一个节点，有些根据业务不同要查询出不同的数据等等，这些处理同样有着他们共通和需要规范的地方。可以实现对不同组件的初始化过程的封装，例如默认选中树中的某个节点，默认使表格中某条记录高亮等等。

    技术方案共享

    在项目开发过程中，经常会出现只有架构师很少的情况，那么很多核心技术的攻关、架构的设计及实现、疑难问题解决、框架使用的培训等等好多功能等着架构师来做。这就会导致在架构师这个点上形成一个瓶颈，直接影响着开发效率和产品质量，而解决这个问题，需要在框架设计过程中有更多的核心人员参与，共同讨论、共同设计和共同开发。同时形成API文档、DEMO、Wiki等多个外围的支撑体系。

    框架开发的风险分析

    框架开发过程，是不是人到位了，技术高大上了，就可以开发出完美的框架了呢？未必那么遂人愿。框架开发的风险是非常高的。

    技术框架本身会包含两个部分，第一个是框架标准，第二个是可重复利用功能库。框架标准可理解为API，是骨架；可重复利用功能库则是一个逐渐积累的组件库，是肉。

首先API的规范合理性是不容易实现的，需要有大量的业务做支撑，光凭会议室几个人的讨论是无法满足千变万化的业务需求的。

    其次抽象程度的把控也是存在风险的，抽象性太高，那么太通用，很多个性化的要求无法实现；抽象性太低，意义就不大了，那就相当于框架把业务功能实现了。需要多次迭代才可稳定。

    最后就是对各种不同的框架需求的响应速度存在风险，多数时候当大家真正开发时才会想起某些功能需要封装到可重复利用组件库中，而这时在人员不够充足时间较短的条件下很难快速实现某个组件，需要尽早提出并尽早讨论方案。

    基本上要说的就是这么多，还有很多需要注意的地方，慢慢补充吧。