软件设计的思考与关注点

 

软件设计是一个十分复杂且没有规律可遵循的思维发散过程。设计软件系统是非常有挑战性的，因为一方面需要你聚焦在今天的需求，同时要求可以适应未来对功能的修改和增加。

面对软件最大的敌人—需求的变化，我们更多的是通过堆积木的方式堆砌代码。

随着系统的上线运营，客户需求不断的变化与扩充、程序BUG的不断涌现，我们天天在为了修正BUG而干十万火急的工作，下班了还提心吊胆实施地是否给自己提了除错单。面对一堆高深且杂乱无章的代码、面对一个接一个的BUG、面对一个又一个的需求单，我们抱怨、救急、茫然、苦不堪言，眼前看不到一丝希望。

对于困惑，我们束手就擒了吗？没有。我们搬来了一堆设计方法论，什么CMMI、RUP、XP、TDD，还有结对编程、四色原型等等。拿来了国外先进的方法论，我们自豪的说我们的设计多牛多牛，设计理念多么的先进。可现实落实下去了吗？几乎没有。我们根本没有理解如何去实践，我们只是了解皮毛然后在尝试，可悲的是我们在实践过程中没有去总结，没有去改进。结果呢？我们的设计仍旧纠结于细节的泥潭，设计的人力耗进去了，貌似也有些输出成果，只是这些成果对质量没有本质的提升，仅仅能看到稍许眼前利--开发人员轻松了却又纠结了，我是否该完全按设计去做，照搬又不能实现需求？怎么办？

我们每个人都希望能够把设计做好并尽力最大努力，但随着不停的添加临时性的修复，越来越多的代码变得难以维护和改进，项目也一步步陷入泥潭。

系统的依赖关系与复杂度让我们对系统望而生畏，领导一拍板--重新设计开发，我们又重新沉迷于初期的美好架构与愿景，似乎眼前一片光明大道。可实现了？不说大家都知道答案。

我们到底应该如何去做设计？什么样的设计才是好的设计呢？业界的可维护性、可扩展性、可复用性、灵活性等大家耳熟能详，说的时候也是信手拈来，可实践中如何去实现，如何才能满足了？我们又迷茫了。

首先看一个分层与包结构关系图，我们不讨论其合理性，但第一眼的印象是不是觉得很晕？

太复杂了，可现实是残酷的，软件设计与开发的复杂性一直伴随在我们身边，问题域的复杂性、管理开发过程的困难性、软件实现的灵活性等等导致了软件开发就像一匹脱缰的野马，我们无力掌控。

导致复杂性的根本原因是什么？依赖。代码的变乱，根本原因就是由于太多不良依赖或者模块失去单一性所致。如何解除依赖？我们先看看计算机组成结构图：

计算机的各个组件为什么能轻松组合运行？关键是抽象层次之间以某种定义好的方式进行交互，在给定层的内外之间有清晰的边界，在不同抽象层的不同部件之间，存在清晰的分离关注。

从计算机的组装看软件的设计：

从上图看，面对系统的复杂性，设计的核心是分离关注点与模块化/组件化，如何实现模块化开发呢？我认为应该从职责、协作、服务、变化四个方面着手去设计，即：

（1）分析出各组件的职责；

（2）发布组件的服务；

（3）建立组件之间的协作关系；

（4）组件本身如何应对变化；

关于划分职责、发布服务、建立协作、应对变化四个方面，后续再逐一总结发布。