优美的系统与架构师的艺术气质

“系统是一个个有机的生命。跟企业一样，系统也需要施肥浇水，需要健康的成长。与企业一样，一个系统可能会在短期内被滥用（比如在需要短期内快速盈利的驱使下），不过如果滥用的时间过长，系统最终将会无法支持。与CEO一样，一个架构师对系统的这个特性了如指掌。他们能够识别什么是滥用，系统能够承受的限度，并将系统引回到健康的道路上。”

上面是一段架构师对于构建优美系统的描述。这段话的主人说，“架构师是使用代码作画的大师。”——在他看来，架构师最大的价值在于艺术。这并非是Fred George自家的看法，高级架构师王翔先生也表示“好的A（编者注：A即Architect，架构师的简称）需要有些艺术气质”。

什么是优美的系统？

商业软件项目的首要目标是实现来自客户或公司的商业需求。然而，在架构过程中仅仅考虑到实现商业需求而建立的系统往往缺乏伸缩性、安全性、可维护性、可靠性、可移植性等等，导致其在短短数年内便因无法与时俱进而被抛弃。这一点几乎每一位维护过项目的程序员应该都能够体会到：面对着缺乏文档、不知所云的代码，想要修改或添加一个功能却无从下手。

而一个优美的系统则是可以像有机的生命一样成长的，这是因为从系统开始架构的那一刻起，架构师就考虑到这个系统以后将会面临的挑战，为系统的成长预留好空间。项目经理经常会对这位架构师提出的看似理想化的要求不置可否——项目经理只想着能够尽快以比较低的成本实现客户的需求，然而这些充满艺术美感的想法其实是打造健康——因而优美——的系统的根本因素。

架构师的艺术气质使其站在了与项目经理不同的立场上：项目经理从商业需求的方向考虑，而架构师则从系统本身的方向考虑。在商业气息很浓的项目中这会引发一些冲突，这也是为什么最出色的系统往往出自学院，而商业项目中的架构师必须具备权衡取舍及妥协能力的原因（参考架构师十大技能之权衡取舍篇）。

艺术气质的另一体现就是对简约的追求，这在Google或Apple的大部分产品上有很好的体现。看起来是两回事，不过系统的简约与系统的健康往往是相辅相成的。

架构师的艺术气质

在软件开发产业发展的过程中逐渐建立起了一些行业准则和参考标准，这些将有助于架构师在面对复杂需求时仍然能够保持清晰地头脑来思考问题。学习前人总结的软件与架构方面的知识，遵循既定的指导标准——比如，按照模版编写软件架构文档——看似死板，却是必要的修炼。这些架构师的基本功是全面的、抽象的、深层次的。没有这些基础，那么架构师连实现商业需求都会感到吃力，更不要说去顾及需求之外的东西。另外我们提到过架构师需要有前瞻性：超前的眼光是架构师实现其艺术追求的弹药。

阅读公开的软件架构文档（Software Architecture Document）是一个很好的学习途径（在Google上能够找到很多）。软件架构文档是架构师在项目早期阶段对于系统的一个描述性概览，这份文档提供了这个系统预计实现功能的概述，这个系统将会使用什么技术以及可能存在的技术局限，以及最重要的部分：视图模型。

视图模型是业内在20世纪90年代开始逐步建立起来的一套规范（IEEE 1471），不同的视图从不同的角度对系统的不同方面进行关注。之前所提到的项目经理注重商业需求而架构师注重系统健康的矛盾，其实在这个视图模型中都有相应的描述，为架构师开展思路提供了很好的指引。过去的十多年间出现了很多指引性的视图以及框架，一些常见的包括：

用例视图（Use-Case View）：这是业务需求的角度。

逻辑视图（Logical View）：这是功能实现的角度，用例执行的流程图。

上面两个视图是必需的，也往往是项目经理最关注的部分。如果只考虑这两个角度，系统可以被建立，但正如之前所描述的那样，是不可能优美的。架构师还需要视情况考虑下面这些视图：

进程视图（Process View）：如果系统是多线程的，高并发的，则需要考虑线程的角度。

部署视图（Deployment View）：如果系统分布在多节点，则需要考虑服务器端和客户端节点等硬件映射的角度。

数据视图（Data View）：如果持久层在系统中很重要，则需要考虑数据的角度。

不过正如之前所提到的，如果没有扎实的技术基础，如果架构师缺乏全局观、抽象思维能力以及透过问题看本质的能力，那么他仅仅为了实现客户需求都会感到力不从心，更不用说发挥自己的艺术气质云云了。

从另一个角度来讲，做艺术的架构师们也都是行业里大师级别的人物了，这也是架构师们的终极目标吧！

本文为《架构师害怕程序员知道的十项技能》中的艺术气质篇。