架构师心目中的关键词

前些日子，在闲聊中，一位媒体朋友问我：软件架构师（Software Architect）究竟与普通程序员有什么区别，软件架构师平时都在想些什么？这一问，倒提醒了我。想来自己从事软件架构设计这个行当也有十多年了，现在确实有必要以文字的形式，把自己这些年来对于软件架构设计这项充满魅力、极其有趣的工作的所思所想、经验所得，好好整理一下。 

软件架构设计是一门建立在科学、工程基础之上的艺术。根据我本人的体会，以下术语和词汇大概就是那些让一位软件架构师在其职业生涯中时刻萦绕于心、挥之不去的核心关键词： 

权衡与平衡（Balancing the Tradeoffs）

软件架构师必须学会的第一件事情是：懂得如何进行权衡，在各个相互矛盾的设计要素、限制和约束条件之间巧妙地取得平衡。 

与人类所从事的其他工程活动一样，软件开发、软件工程本质上也是一种平衡的艺术。如何才能把握软件开发艺术的平衡之道？在现实的软件开发中，一名架构师必须首先掌握科学的、工程的思维方式和方法，也就是客观的、系统的、符合逻辑的思维。错乱的逻辑必然导致错误的结论，基于错乱逻辑设计出来的软件也必然会破坏软件架构内在的和谐之美，因而是丑陋的。 

抽象、建模与设计（Design with Abstraction and Modeling）

一位软件架构师必须 主动地 选择工作在合适的抽象层次上。在必要的情况下，他/她必须能够脱离具象的编程语言（如 Java、C++、VB.Net、JavaScript、Ruby 等等）进行思考，能够透过现象看本质，准确抓住事物的本质。 

如果一位“架构师” 只会 工作在代码实现（Implementation）层，遇到任何问题就忍不住要写上几行代码、砌上几块砖头，摆摆看，否则就无法顺利思考，却不知道、不会利用图形、符号、公式等 抽象的、敏捷的手段 来描述自己的思考和设计，那么这位“架构师”的能力是有严重缺陷的。 

预见性和前瞻性（Prediction and Anticipation）

一位软件架构师必须比团队中的普通程序员、初级程序员看的更远。 

如果一位开发“能手”和“高手”，经验丰富却目光短浅， 只知道 解决眼前的现实问题，不知道在有限的可用时间内往前多看几步，考虑一下面向未来问题和潜在风险的应对之道，他是不足以享有“架构师”头衔的。 

简化之美（The Beauty of Simplification）

简化是这个世界上任何科学、工程技术 —— 逻辑艺术 —— 的本质要求。 

E=mc^2 告诉我们，我们人类身处的这个宇宙存在着永恒的简单真理。作为被科学家和工程师利用电子技术构造出来的虚拟世界 —— 软件，这个空间、小宇宙自然也不例外。在软件工程界，我们笃信：只有简单而有效，才是真正的软件之美。 

为什么我们要白白耗费资源，开发出冗余的、重复的、七绕八拐的低效程序？软件架构师必须带领他/她的程序员团队，始终坚持对软件架构艺术之美 —— 简化的追求。 

模式与重用（Patterns and Reuse）

软件架构师必然首先是一名聪明的程序员，他/她知道何时、何处省力，如何省力：运用巧力来轻松完成原本繁重的开发工作。 

节省工作量的最好一个办法就是重用。如果软件开发的 10 倍率银弹存在的话（张恂一直认为 谈论布氏银弹的存在与否并无多大的实际意义 ）， 软件重用无疑是一颗最有效的银弹 。重用自己的或别人的代码、程序、构件、模块、子系统乃至整个系统，可以让过去需要 10 天完成的工作在 1 天之内完成，让过去需要 1 年完成的工作在 1 个月之内完成，这样的例子遍地都是，有什么办不到的呢？ 

软件模式的应用 本质上是对软件设计思想、设计知识的重用。毋庸置疑，世界上任何一位软件架构师，都知道而且应当知道软件设计模式存在的宝贵价值和重要意义。 

质量、效率与资源（Quality, Efficiency and Resources）

如何在有限的，甚至往往是“窘迫”的时间进度、经费和人力资源等重重压力之下，带领团队开发出真正符合客户需要的、高质量的，同时又具有长久生命力的软件产品或系统，能够不断为企业和客户创造价值，这是所有软件架构师必须担当的一项首要职责、艰巨任务。当然，这又是一个相当复杂的、涉及到科学、工程、艺术、社会人际关系和公司政治等多方面因素的权衡问题。 

敏捷、迭代与演进（Agile Iterative Evolution）

高质量的、好的软件架构从来都不是一蹴而就的。把一个项目切分成 5 个连续阶段，通过 需求阶段 完成需求分析， 设计阶段 完成概要设计和详细设计， 实现阶段 完成程序编码， 测试阶段 完成系统测试， 部署阶段 完成安装部署，这种传统的、错误的线性开发思维违背了软件开发的复杂现实，成为导致国内外大量软件开发项目失败的主要杀手。 

我们应该避免采用这种高风险的传统瀑布式开发流程，转为采用迭代递增、演进的方式来设计和发展软件架构，这是过去 30 多年来世界软件工程界以及软件架构师们学到的最宝贵经验之一。 

开发出敏捷、灵活、柔性，易于适应变化，能够不断地满足客户需求，不断地为企业创造利润，以及便于维护、扩展和升级的软件架构，需要优良、合理、高效的软件开发工艺流程的支撑。实现这一目标并非超乎现实的幻想，过去 20 年来世界上的领导企业和软件开发机构已经为我们提供了大量系统、架构、框架和平台的成功开发案例。 

软件架构师应该与项目经理、团队成员们一道为自己的团队挑选、定制一种适用的软件开发过程。敏捷迭代开发要求软件架构师通过软件开发的迭代、演进周期，把握好前馈与反馈、前构与重构的平衡，不断地利用编码、集成、运行、测试以及与用户、客户的沟通等活动来验证软件架构的设计思路、解决方案的正确性和有效性，从而最大限度地降低架构开发风险。 

前构与重构（Prefactoring over Refactoring）