概要设计的艺术

前言

由码代码到软件设计，所需要的思维方法发生了变化，某些在码代码时占比比较小的思维方法在软件设计中变得至关重要。

软件概要设计刚开始学习不久，本文仅仅基于本人当前的认识。

大原则

软件设计最本质的原则（在我看来）是经济学十大原理中的第一条：人们面临权衡取舍（trade-off）。

码代码不会有这个意识，在这个阶段接受到的是具体的任务，框架已经选好并搭建完毕了，数据库选定了，相关的技术也都已经定好，要做的只剩下完成某个需求，不复杂的情况 CRUD 就可以搞定，业务复杂的情况下加点设计模式也就搞定了。

软件设计时工程师面临更加复杂的情况。

软件设计定义

根据维基百科对软件设计Software Design 的定义：

Software design is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.

关键词 specification，software artifact， components，constraints

概要设计定义

1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation
2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

概要设计关注的是组件结构，相互的关系以及设计中的原则和指导方针。

概要设计的艺术

在进行概要设计时需要从抽象、图表、文档三方面进行思考。

抽象

抽象是寻找事务最本质的特征的过程。以前写过一篇抽象的文章，就抽象这个概念进行了一些讨论，此次关注的是抽象在概要设计时所起到的启发作用。

譬如设计一个用户服务，最终设计图如下：

这是经常看到的架构图/设计图，但是设计图里已经将所有的可能都确定了，就像数学题直接给出了答案，无助于了解设计的过程。

真正有助于启发的是在更高一层的抽象上思考服务设计。

在这个设计图上来再进一步思考就到了技术选型的思考于分析，数据存储是选用 RDBMS 还是 NoSQL？Config Server 选用 Spring Cloud Config 还是 携程开源的 Apollo？Request Handling Service 选用 Java 还是 Go？这就需要在当前的环境下来对所有的情况进行考虑，也就是前面所说的大原则：trade-off.

所以设计不是给一个解决方案，而是给出几个选择，再选择中选择最优解。

图表

码代码只需要在头脑中就可以思考所有的情况，然后具现为代码，因为这是单人完成的任务。概要设计则不然，设计完成之后还需要由其他人将其实现。因此设计的沟通属性更强一些。 图表就是利于沟通的强大工具。

在抽象中给出了两个设计图，在作图时也需要时刻记住抽象原则。 判断图表做的好与不好，可分析图表所表现的架构是否是在同一个抽象层次上。

文档

If you can’t explain it simply, you don’t understand it well enough. - Albert Einstein

文档是将所思所想表达出来的载体。如果不能简洁的写出来，那说明你没有完全的了解它。

文档也是梳理的自身的一种手段，就像写博客一样，需要将思考有条理的表达出来，仅仅停留在脑海中是不够的。

总结

不同系统需要不同的设计方案，此文更偏于方法层面，具体系统还需要具体分析。