我们说的软件架构究竟是什么？

什么是架构？

当我们开始一个新的软件项目时，开发负责人会说，我们先来设计架构；当我们接手其他人的项目时会说，把架构图给我看看，一切都离不开架构图。

那么，架构到底是什么呢？

架构=设计，这两者之间没有任何区别。大到系统与系统之间的交互，小到一个确定按钮的样式，都是设计，都是架构的一部分。

在我们的开发中，架构一般用于“高层级”的讨论，而设计往往用来指代具体的“系统底层”的组织结构和实现细节，即架构偏宏观，设计偏微观，但它们实际上是相同的，只是描述粒度不一样而已。

那架构设计的目的是什么呢，为什么要进行架构设计？一句话来描述就是：

用最小的人力成本来满足构建和维护该系统的需求

我们可以简单的用一个简单的指标来量化一个软件的架构设计好坏：

单行代码改动成本

我们来看一张图，好的架构，其每行代码的变更成本随着版本迭代基本是不动的；而差的架构，其变更成本随着版本的迭代将会呈指数或线性增长：

每行代码变更成本趋势图

如果系统的单行代码改动成本在不断增加，那么我们就要好好反思一下，架构设计是否存在不足的地方。

麻乱的系统是如何产生的？

在我们的开发过程中，不知道有没有遇到这样的情况：下周就要上线，时间来不及了，不考虑代码性能、结构分层、复用，直接狂写一通，产出几个上千行代码的函数，然后心里想着未来空闲的时候再进行重构优化。

如此经历多几次迭代之后，我们会忽然发现，想要改动这里的一行代码太难了：花半天才看懂这上千行代码的函数，之后又花半天时间回归测试这个函数。

一天时间就这样没了，但其实我们只改了其中一行代码。

经过持续、多次以下这样一个迭代，一个麻乱系统就产生了：

麻乱系统的一次迭代

这种现象在软件开发中不是个例，而是普遍存在的。在我们开发系统的过程中，会产生两个价值：行为价值、架构价值。

只要我们的代码可以正常运行，功能可以正常使用，那么它就具有行为价值；而架构价值顾名思义，就是我们开发的系统，经过精心设计，架构合理，后续扩展维护简单，这个系统就具有很好的架构价值。也即：

软件系统的价值 = 行为价值 + 架构价值

上面描述的那种未经过任何设计的代码，它的架构价值为0。也最是符合大部分业务人员的思维：快速上线、能正常使用就行。

但作为开发人员，应该时刻为自己的系统的架构价值考虑。

开发人员的错觉

大部分开发人员是具有很强的技术追求，但面临业务人员“快速上线”的要求时，他们往往会把自己的技术追求搁置一边，开发出一个难以维护的系统，这是为什么呢？

因为开发人员往往存在错觉：

• 容忍糟糕的代码可以在短期内加快上线速度，未来这些代码只会造成一点额外的工作量；
• 产品上线最重要，我们未来可以重构优化；

然而，糟糕的代码上线之后，大家就把重构优化的事情抛在脑后，继续投入到下一个忙碌的迭代中去了。直到有一天接到一个需求，要改动旧的代码，这时候开发人员会说，这垃圾代码是谁写的，让我怎么改，一看commit，哦，原来是我自己，重构太耗时间了，我先继续往上堆代码吧。

如此经历几次迭代，业务人员想要增加一个功能时，原本只需要一天的时间，现在可能要一个星期了。长此以往，不管是老员工，还是新加入的成员，都不得不通过加班去满足开发进度，进而产生深深地挫败感。

最为可悲的是，开发人员自始至终都没有意识到，他的想法都是错的。

容忍糟糕的代码并没有加快上线速度，无论是短期还是长期来看，经过认真设计的代码，都具有更快的上线速度；未来也没有机会重构优化，而且重构优化的效果不一定比现在的好。

切身感悟：

一、编写糟糕的代码不能加快上线速度；
二、未来没有时间重构；
三、好的程序员必然不能容忍不好的架构设计，缺少时间都是开发人员自己想出来的接口，而不是决策层的想法；
四、复利的理论可以应用在代码质量上。