如何让架构发挥作用
最近看了Matin fowler的演讲： make architecture matters. 深刻的谈了如何让架构起作用。
他讲的思路如下：
什么是架构（核心技术人员的技术共识，）
技术共识
首先我们对架构师提到了几个疑问，什么是架构师？尴尬的答案是：指的是很多年没写代码的高级大拿制定的一套如何写代码的规范和标准的那帮人，然而这些人经常会使项目引发很多不接地气的问题。所以这里描述的架构师的概念散发出一个不好的味道，因为在项目中技术大拿必须真的去写代码，代码是重要的，在开源社区大家也有相同的认识。好， 如果说上面所说的架构师不是真的架构师，那么什么才是架构师呢？
换句话说，在软件界架构到底是啥意思呢？我们百度一下，发现定义如下：
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的关系则明确和相对细致地描述组件之间的通讯。
但是百度的定义的问题是，这些抽象组件是什么？组建之间的关系又是指的什么？有人说抽象组建是高阶的关注点，那么这个最高阶的关注点到底是什么？你如何选择高阶组件的，哪些关系是你的关注点？你是根据什么原则来选择这些组件和关系的，什么样的组件就是高阶的，什么样的组件就不是高阶的呢？
当你到一个健康的软件项目中，找到一个核心开发人员，找到一个能力最强，最代码最了解的人员，他们都会对这个项目代码如何工作有一个技术共识，这个技术共识实际上就是架构。这个核心技术人员之间的模糊的技术共识就是架构。当然你的项目可能有很多图示，文档，甚至有真的架构图，但是它们都只是一个表达而已，通常都是对这个技术共识的不完美的表达。在项目不停演进过程中，在核心技术人员之间的技术共识就是架构。
很难变更的事情
除了刚才讲的技术共识外，还有一个说法：架构就是一系列必须在早期进行选择的设计决策。立马就有人会反问，应该是一系列你自己感觉必须在早期进行选择的设计决策，因为你只有到了完工才能准确知道什么设计决策是必须在早期进行决策。所以综合起来，架构就应该是那些很难变更的设计决策。比如：
- 编程语言，改变起来就是很难的。
- 数据库就是很难变更的。
- 微服务的划分归属就是很难改变的。
总结起来：架构就是任何重要的东西。
这个听起来像是一个挺傻逼的描述，架构就是任何重要的东西。但实际上我认为这是实际上是一个很准确的描述。当你尝试去描述你的项目的架构的时候，第一件事你必须弄明白的是，在你的项目中什么是重要的？技术专家小组认为这个项目中最重要的事情是什么? 当你回忆起这个代码库，在你脑海中第一个浮现的重要的事情是什么？
架构为什么重要
在很多项目中经常发生的事情是：下个版本我们需要交付更多的特性，所以软件质量就会有所下降。这时候很多架构师都会站出来开始反对这个做法，于是讲了很多道理，但是通常都会输掉这个争辩，因为最终都是因为工作量花费 的问题.
我们来谈谈花费，在你买车的时候，你通常考虑的是性价比，有高质量，必须高花费。但是软件的质量有很多变量，例如靓丽的用户界面，很少缺陷，很好的模块设计。其中前两个是用户可感知的，最后一个是用户不可感知的。而架构指的就是内部质量。问题是，有人卖给我一个软件，我应该选择内部质量高的，还是内部质量低的，跟我有什么关系呢？其实内部质量是从长期质量来看的，请看下图：
横轴是时间，纵轴是软件系功能的可叠加性。斜率越来越小的曲线，就是设计不好的系统的表现，随着时间的增长，叠加新功能的能力越来越弱。而设计好的系统，随着时间的推移，反而是越来越容易叠加新的功能。
而这就是架构的重要性，如果架构腐化，我们的软件将会越来越以叠加新的能力，耗费的成本就会很高。