软件|软件分析与设计：分析什么？如何设计？( 三 ) 软件

设计是包含原则的，这些原则应该是大家都去遵循的，比如分层原则，这个在软件设计中非常常见，原则是平时大家开发过程经验的结晶，以分层原则为例，可以深入思考，为什么要分层、分层解决了什么问题、要分多少层、如何去分层，只有深入思考了这些原则，在新的场景中再去做设计时，就会得心应手，而不是僵硬地去套用分层原则。

2 设计原则
设计原则，每个设计者有自己的理解，很难有统一的设计原则，只能在局部上达成一致，比如分层原则，这个大家比较容易达成的，设计原则应该是一系列的原则组成集合，并非是单一。设计原则是在大量实践过程中沉淀出来的，我更想说的是如果你对看到的某些原则能结合自己的经历讲得出来，说明你是有过真正实践和思考的，否则这些设计原则也仅仅是一些文字，转化不了设计经验和设计能力，这里列出一些常用的设计原则。
系统性原则抽象分层原则领域原则复用原则简易原则成本效率原则正交原则扩展原则演进原则 3 2个设计案例
对于上面提到的9个设计原则，这里主要聊的是系统性原则和正交原则，系统性原则是站在全局上思考系统之间的交互，这个是非常重要的，相当于是指明灯，当看懂了整个系统未来的样子，在当下每一步的执行都清楚知道是为了什么。反之没有这个系统性原则，所做的事都只是关注点状事情，不成体系。以2.3节中的例子来讲，当分析出来要做的事情后，如下图画出系统架构图。从系统架构图中可以看出系统之间的交互是怎样的、链路逻辑是怎样的（注：逆向链路没有表达出来）。

我们在数学中学习过正交，最简单的理解是两条线是垂直的，在软件中我们看到一些逻辑中包含了很多的逻辑，每次修改的时候，改了这个逻辑结果影响了另外一个逻辑，说明我们的逻辑耦合度比较高。正交原则即是分离出不同的变化点，让变化自治，即每个变化只影响自身，不会影响到其它的变化点。平时我们写代码中有两种场景影响正交：代码重复和关系依赖，对于重复的代码可以抽取出来，对于依赖的部分，可以抽象一层防腐层出来。

举一个正交的例子，假如有一个需求是：查找员工名为John的员工，这个代码可以很快写出来，但细细想想的它的变化点，至少可以想到下面3个变化点：
查找的内容会变，不一定按照名字来查，比如按照员工工号来查；查找的对象会变，不一定查员工，还有可能查学生；查找的规则会变，不一定是待值查找，还有可能是范围查找，比如查找年龄在20至30的员工。当想到了这些变化，重新设计后的效果就会不一样了，当面临业务场景变化的时候，可以做到最少的改动，这也即是设计能够降本增效的原因。

四分析与设计的思考 1 衡量标准
衡量分析与设计的标准是比较难的，一般是从一些大的原则去看，比如复杂性、开放性等，但又很难有一个量化的指标去衡量，到底复杂度有多高、开放性有多底。真正衡量好坏只有通过比较才比较好判断，比如多个方案之间的比较，这个是比较容易衡量谁好。因此我们需要多去看别人是怎么设计的，有哪些好的设计思想值得借鉴，多吸收好的设计思想、设计案例。
做设计最怕是闭门造车，结果设计出来的东西不能够很好地解决实际问题。个人的经验是去看业界的方案，看看它们是怎么设计的，各自的特点，比如数据不一致性的问题，有很多种设计方案来解决，有的方案对业务入侵比较大，需要改造很大，能不能无入侵业务呢？阿里提出了TXC解决方案，这个设计就非常好，使用者只有打上一个注解就ok ，对业务改造没有什么成本，这也即是前面提到的简易设计原则。
2 虚实结合
提到分析与设计，很多人觉得很虚，的确，在我刚工作前3年，也觉得这个非常虚，这个不就是画画图嘛，后面发现还真不是这么一回事。印象最深的一件事，当时在滴滴，我的主管给我们展示了营销系统未来我们要做的事，用了一张系统架构图非常体系地讲出来，知道未来我们要做成什么样子，当前我们处在什么位置上，那段时间我们过得非常充实，知道我们在做什么、要做什么， 1年半以后我们把当时那张系统架构图上的事情都完成了，回过来头来看，如果没有当时的指引，每天还是做着需求，来一个需求做一个需求，这也即是最开始做事没啥动力，没看到目标。