软件架构师应该知道的97件事之概括31-45

31、程序设计师一种设计

程序设计属于设计范畴而不是生产范畴。

软件的生产则是自动化的，由编译器、构建工具和测试代码共同完成。

如果把编写代码看成设计行为，而不是生产行为，我们就能采用一些已经被证明有效的管理方式。这些方法过去用于管理不可预测性的创新工作，比如研发新车、新药、新的电脑游戏。我们指的是敏捷的产品管理方法和精益生产方法，比如SCRUM。

32、让开发人员自己做主

多数架构师都是从开发人员干起的。以前作为开发人员你很少有机会仔细观察整个系统是怎样组合在一起的，而作为架构师这是你工作的重点。

如果想出色的完成工作，是不可能有空闲去干预开发人员的。

33、时间改变一切

选择值得投入精力的工作

简单原则，回顾以前或者更早的项目时，几乎都会惊诧自己当初的做法，如果有机会再做一次，我们一定会以更简单点的方法来完成。这就是时间的作用。

别跟以前的工作过不去，你现在看重的设计思路，可能2-3年后就会被自己否定。

34、设立软件架构专业为时尚早

设计软件架构师一门手艺，从业者无意要通过实践和训练才能在这个领域获得成功。

35、控制项目规模

估算与准确的科学计算相差甚远，所以产品特性实现起来常常比预期要困难。

缩小和控制项目规模策略：

抓住真正需求。分而治之，设置优先级，尽快交付。

敏捷方法的倡导者提倡开发”最简单有用的东西“，越复杂的架构越难以实现。缩小项目规模通常会降低架构的复杂性，这是架构师提高成功几率最有效的途径。

36、架构师不是演员，是管家

架构师接受新项目，都渴望证明自己的价值，这是人之常情。

炫耀和作秀与指挥开发项目背道而驰。

架构师的职责和管家类似，承担着管理他人资产的责任。

架构师要满足不同领域的客户需求，而这些领域的专业知识通常是架构师所不具备的。

37、软件架构的道德责任

软件世界的道德范畴边界并不清晰，尽管有些行为无疑是不道德的，比如侵犯他人的公民权利等，但还有些行为的道德意义不被察觉，比如浪费别人的时间。

架构师的每项决策（例如设置必填项和规定流程），都限制了用户可以做什么不能做什么。这比法律容易的多，并且还找不到法院受理他们的诉讼。

我们可以从倍增效应的角度来看待软件的影响。软件问题所造成的损失将以成不可估量的倍数出现，尤其是给人心理上的。

假设架构师要实现一个新功能，简单的设计要1天完成复杂的设计要1周的时间，但简单的设计要强迫用户输入大量的数据，这个过程常常会丢失数据，耽搁工作，让人非常沮丧。从长远看浪费别人的时间将远远超过你省下的时间。

损人利己是不道德的行为哪怕程度很轻。

38、摩天大厦不可伸缩

土木工程不只是设计建筑这么简单，真正的难题在于规划整个施工过程，确保建筑物拔地而起，包括从奠基到竣工的所有工作。其中有很多经验值得我们借鉴，尤其是对于部署大型集成化软件系统（包括所有企业应用和web应用）。如果把软件比喻成土木工程，那么传统的大爆炸式软件部署方式就好比把备齐的建筑材料一股脑仍上天，指望他们瞬间拼成一座大厦一样那么可笑。

相反，无论是开发新项目，还是替换已有的系统，都应该逐个部署系统组件。2个优点：首先，隐藏在代码中的技术风险是部署软件时无法回避的问题，其次这种方法迫使我们设计清晰的组件间接口。

有些是不能借鉴的，尤其是在建筑工程中屡试不爽的”瀑布式“施工方法。毕竟摩天大厦不需要可伸缩性。

应用软件只要具备了用户要求的功能便可发布，不用等到十全十美。事实上，产品越早发布公司的净收益就越高。这样既可增加商业利润又可以改变架构品质，这样实用的技巧实在不多。

39、混合开发的时代已经来临

混合编程：在一套软件系统中同时采用多种核心编程语言

现在可以采用基于文本协议（text-based protocols）了。这些新技术以特定格式的文本作为载体，便于所有人编写和理解，为混合开发提供了前所未有的可能性。

架构师把若干个强大的开发工具组合起来使用，以往的标准是挑选合适的编程语言，现在则演变成挑选合适的编程范式。

选择多了并不总是好事，但至少好过以往软件架构非此即彼的窘境。

40、性能至上

性能指标和其他指标一样重要。

有些设计师把性能放到最后考虑。

我们通常把系统响应用户输入的时间作为衡量性能的标准。

生产率通常用来描述构架系统的效率，也属于性能范畴，其重要性在于直接影响项目的成本和进度。

系统的人机交互性能直接关系到用户是否愿意掏钱。包括：响应时间，是否直观，操作步骤是否简单。

合格的说明书除了注明系统每秒钟的响应次数，还要测量典型的任务时间。

非交互性组件的性能同样影响着系统的表现。

在考虑系统的实现方法和运维策略时，架构师和设计师应该密切的关注系统的性能表现。

41、留意架构图里面的空白区域

软件系统由相互依赖的程序组成，我们把装配这些程序的方法及程序之间的关系成为架构。

假设某个箭头表示”使用HTTP协议，发送SOAP-XML格式的同步请求/响应消息“，由于架构图里面的空间有限，写不了这么多内容，所以通常用简单的注释表示。从技术角度出发可以简写成”XML over HTTP",如果从业务角度出发，有可能写成“查询库存单元”。不同的程序看似通过箭头直接联系，其实不然，矩形之间的空白区域充满 着各种软件和硬件。

应该理解每个箭头包含的静态信息和动态信息。

42、学习软件专业的行话

每个专业都有行话，同行之间讲行话方便交流，清晰、简洁、高效的方式与同行进行沟通，是软件架构师应具备的能力。架构师必须掌握基本的架构模式和设计模式，学会辨别不同模式，并借助他们和同行及开发人员进行交流。

架构和设计模式可以分为四大类：企业架构模式、应用架构模式、集成模式、设计模式。

企业架构模式定义架构的全局框架结构。

应用架构模式指出了全局架构下的子系统及局部应用的设计方法。

设计模式研究架构中各个组件的构造方法。

除以上4种外，架构师还应该了解和提防各种反模式。

反模式：影响软件开发中的常见错误：需求分析麻痹症、委员会设计、蘑菇管理、死亡征途。

43、具体情境决定一切

”分享设计架构的理念让我觉得很滑稽，因为我认为压根就不存在设计理念“

“毕竟，没有理念本身也是一种理念”

最重要的设计经验是具体情境决定一切，根据它设计尽量简单的解决方案。换句话说，架构决策只有在情境需要时，才能牺牲尽量简单的原则。

脱离了具体的应用场景，孤立地比较技术的优劣是毫无意义的事。

44、侏儒、精灵、巫师和国王

架构师好比国王，应该熟悉各种人的性格特点，招聘不同性格的人加入自己的团队。

安排任务时应该时刻考虑所有开发人员的性格特点。为不同性格的团队成员安排合适的任务，如果大家有机会磨合、相互适应，就能轻松化解决各种难题。

45、向建筑师学习

建筑师名言

建筑师社会性的表演，是上演人类历史的剧院。

要想成为伟大的建筑师，优雅丰富的心灵远比聪明才智重要。

.....

建筑师自诩上帝的助手，甚至觊觎上帝的宝座。（上帝：客户）

天底下没有完美的建筑。

建筑师首先应该是伟大的雕塑家，或者伟大的画家，否则他不过是个建筑工人。