最近一直在读《Clean Architecture》这本书，书中对与软件设计与架构的阐述是非常深刻的。因此开了一篇专栏，来记录《Clean Architecture》书中一些优秀的架构设计理念，以及我对这些内容的思考。
一、设计与架构是什么?
设计（Design）与架构（Architecture）这两个概念让大多数人十分迷惑——什么是设计？什么是架构？二者究竟有什么区别？
实际上，两者说的是相同的东西，“架构”这个词往往使用于“高层级”的讨论中，这类讨论一般都把“底层”的实现细节排除在外。而“设计”一词，往往用来指代具体的系统底层组织结构和实现的细节。
但实际上，在软件设计的过程中底层设计细节和高层架构是不可分割的。它们组合在一起，共同定义了整个软件系统，缺一不可。所谓的底层和高层本身就是一系列决策组成的连续体，并没有清晰的分界线。
而我们追求好的设计和架构的目的是什么呢——
我们希望能够用最小的人力成本来满足构建和维护该系统的需求。
二、设计与架构的存在意义
为什么我们需要设计与架构呢？下面这个例子或许能解答这一问题：
下面这几张图显示了随着开发人员的增长，软件包体积和开发成本的关系。
是的，随着开发人员的变多，我们的开发成本会有一个指数级的上升，但是产出（这里使用生成的软件包体积来计算）却没有对应的增长——甚至到后面已经有所停滞了。
这样就会面临一个问题，随着软件的不断迭代，ROI 会变得越来越低。
那么是什么原因导致的这个问题呢——
“代码质量可以往后放放，项目按时上线最重要”的思维方式。
但实际上我们也知道，项目上线后就不会有人提“重构”了。行业竞争压力这么大，工程师忙着开发新功能，哪有时间重构代码呢？久而久之就成了“代码屎山”。
然而事实上，不论从短期还是从长期来看，这种粗糙的开发方式其实比循规蹈矩的开发速度更慢。上面这张图展示了使用一些业界优质代码方法论（比如 TDD）来指导开发，对开发效率的提升。可以看到随着迭代次数的增加，完成工作所需要的时间也就越少。这也揭示了软件开发的一个核心特点：
要想跑得快，先要跑得稳。
三、软件的价值维度
每个软件系统都有“行为”、“架构”两个维度的价值。
行为价值很好理解，就是这个软件所具有的功能所带来的价值，就像聊天软件的价值就在于“聊天”，仿真模拟软件的价值就在于“仿真模拟”等等。
架构价值指的是软件的灵活性，也就是这个软件是否是易于扩展或变更的，这其实很好理解，如果这个软件很粗糙，那么我们会付出极大的变更成本，这样肯定是会影响它的价值的。
那么哪个维度更重要呢？
如果这个问题问业务部门，那肯定会得到“行为价值更重要”的回答，但这种回答是否正确呢？我们可以来看一个简单的推论：
如果某程序可以正常工作，但是无法修改，那么当需求变更的时候它就不再能够正常工作了，我们也无法通过修改让它能继续正常工作。因此，这个程序的价值将成为 0。
如果某程序目前无法正常工作，但是我们可以很容易地修改它，那么将它改好，并且随着需求变化不停地修改它，都应该是很容易的事。因此，这个程序会持续产生价值。
所以软件的行为价值和架构价值实际上是一个乘算关系，任意一者归零了，那么软件的整体价值就归零了。也正是因为如此，两者都是十分重要的，而在一些需要长期维护软件的场景中，架构价值是要优于行为价值的。
当然，的确有一些系统是不能更改的，比如那些已经跑了几十年的老设备的驱动程序，对它们实施变更的成本要远大于变更所带来的价值。相信大家在开发中已经见到不少这样的例子了。