应用Façade提升开发质量

目前我们有很多开发项目中都存在这样那样的问题，主要表现是开发混乱，耦合性高，开发人员开发还比较随意，没有设计，代码想到哪，写到哪，有点类似骑驴找马的编码方式，造成了我们系统的复杂度，以及混乱性，是系统衍生了很多缺陷，也给系统的稳定性，以及性能带来了较大影响，很多项目在结项后很长一段时间里，仍然在不停的修复，优化，重新部署。其实很多看似短平快的项目，到最后花费了更大的气力在维持。

开发管理人员一直也在根据经验制定相关规范，也在开发团队内部不断对新人开发过程、技能、规范等培训，能够起到一定的效益，但像是及时雨，坚持不到多久，开发的问题，又会冒出来很多。

通过对问题不断进行总结反思，从技术角度究其原因，大致有以下几点：

Ø 项目工期较紧，未经设计，仓促开发上线，而需求又一直在变化，导致雪球越滚越大，直到无法滚动

Ø 系统设计分析人员对于业务的关注，往往注重于技术本身或细枝末节，没有真正站在业务层面上思考问题，经常出现设计不足造成的推倒从来

Ø 开发人员长期随性而做，习惯了没有约束和个性化的开发方式，导致代码冗杂难懂。

Ø 项目的开发框架混乱，层次不清，甚至连高级开发人员自己都没完全理清调用逻辑。后来的开发人员不断在有问题的框架上开发系统

Ø 开发人员没有独立的或不合理分工，每个人都负担着一个模块的需求、设计、实现，很多开发人员数据库，业务逻辑，美工一起做了，这样就对开发技能要求较高，并且导致其每部分工作都不很到位。

Ø 产品开发对开发人员的要求比较高、人员的流动对开发的进度影响很大。

Ø 系统没有很好的复用，带来了有很多重复性和机械性的工作。

Ø 缺少拓展性，想在原有功能基础上增加新特性或新功能，就必须修改原代码

通过以上总结，相信大家不难发现，其实项目中问题最大的因素，是人为因素，很明显人又是软件的创造者，如果我们既有办法让人为不良因素不断较少，让有规律的事情不断固化，让我们的开发人员在开发过程中有章可循，有据可依，那么我们的问题将会大幅度较少。那么如何减少人为因素的干扰，很显然技术手段是个不错的选择，技术技术手段与传统的人为管理手段，更加容易执行，且管理成本较低，在一定程度上对系统提出了设计要求，同时减少了团队内部的反复的沟通，也给产物质量的检查提供了便利。

为此，工程中心制定了Façade框架，Façade框架其实是将行业内部也一直沿用有开发设计打包封装成我们的框架，通过这个框架能够使我们从技术角度解决为解决软件过程所遇到的问题，提升软件质量，提供强有力的一臂之力。

常用的设计准则：

• 分离关注点（Separation of concerns），按照功能将应用划分为尽可能不重复的功能点。由于关注点混杂在一起会导致复杂性大大增加，所以能够把不同的关注点分离开来

• 单一职责（Single Responsibility Principle），每个组件或模块应该只应负责一个特定职责或功能。单组件不要承载太多的功能

• 开闭原则（Open Closed Principle），软件实体应该是可扩展，而不可修改的。也就是说，对扩展开放，而对修改封闭。

• 最少知识原则（Principle of least knowledge），一个组件或者对象不应该知道其他组件或者对象的内部实现细节，而只要按照彼此的约定调用即可。

• 不要重复你自己（Don’t Repeat Yourself）

这些准则正式我们解决的所遇到问题的方法论。

Façade所要解决的问题，是降低人为带来的干扰因素，从两个方面解决开发管理不易触到的地方，加强对系统设计和降低开发人员的随性发挥。目前我们有两个解决方案：

• 面向接口接口

隔离调用者和实现者,便于团队编程，互不干扰，降低等待时间

上层对于下层仅仅是接口依赖，而不依赖具体类，换言之，就算下层实现类换了一遍，只要协议不变,上层依然不变

提供统一的接口容器，由容器对外提供的功能

• 面向切面编程

区分核心关注点和横切关注点，而不是胡子眉毛一把抓

核心关注点：核心的业务处理流程

横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似。比如权限认证、日志、事务处理

Façade框架的与传统的解决方案进行对比

面向接口编程

可以看出传统方案的调用方和被调用方有了过多的耦合，使我们的系统结构变成复杂了网状关系，牵一发而动全身，给开发分工，以及代码复用带来了极大的困难

调用方必须要了解内部业务逻辑，才能够实现整个系统功能，不符合最小知识原则，随着外部客户程序和各子系统的演化，这种过多依赖耦合面临很多变化的挑战

而Façade方案，其系统结构则简洁很多，调用方仅需关注Façade所暴露出来的功能，并调用，不关心其内在的具体实现，调用方和被调用方是松耦合关系，这样开发人员就能各司其职，关注自己的领域，并将其作好，不需要过多滴了解其他模块，可以说，对于不必要的信息，他隐藏了整个系统的复杂度

Façade方案的另一个优势在于，设计人员不是传统的想到哪，做到哪工作模式，而真正可以对业务展开进行领域分析设计，让设计人员的精力专注到业务本身，而非其他技术细节，而忽略了整个业务系统

面向切面编程

AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似。比如权限认证、日志、事务处理。Aop 的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来

如图所示

没有使用Façade之前的业务代码大致如下

而使用Façade之后，我们的SomeOperation()方法仅仅包含DoSomething()，而将 securtity关注点，执行前Logging关注点，执行后Logging关注点等共用的部分转移到横切业务逻辑中。给其他业务复用，避免了开发人员自己随意发挥，而共用同样的业务逻辑后，也给日后的需求变更带来了方便

面向切面编程的场景

• 异常，性能的跟踪日志

• 权限验证

• 参数检查

• 输入输出，格式转换,加解密

• 数据缓存

• 事物传播

• 注入测试

• 注入修补

• 第三方集成

待补充：

Façade在目前项目应用的情况统计

相关Façade使用者的心得体会，以及具体帮助项目解决了什么问题

后续的Façade执行办法，改进建议

总结：

所有的有规律的事情，都应该被转化为机械手臂，应该被安装在固定的平台上，自动地完成，在平台上的手臂越多，人参与的越少,人为因素的干扰带来的影响就会最小，这项工作可能规模小，未必看出优势，但规模愈大，优势愈加明显