软件架构师应该知道的97件事之归纳

架构师是一种神秘的职位，听说每一个架构师都有密不可传的方法，固然咱们不信，更多的是只可意会不可言传。就是说了咱们也不会懂，由于还每到“火候”。所能作的就是，当咱们到这种火候的时候咱们能想起来曾经有过架构师这么说过，而后咱们就能够更自信的向前大步走....

一、客户需求重于我的简历

要想拥有漂亮的我的简历：咱们经常向客户推荐技术、手段，甚至方法论来解决问题，使用时髦的编程技巧和流行的范式，有时候根本不是寻求解决问题的最佳方案。

积累一批满意的客户，选择切合实际的技术解决他们的难题，让他们乐于推荐你才是最好的履历。

二、简化根本复杂性，消除偶发复杂性

根本复杂性指的是与生俱来的、没法避免的困难。好比，协调全国的空中交通就是一个“天生的”复杂问题，必须实时跟踪每架飞机的位置。

偶发复杂性：是人们解决根本复杂性的过程当中衍生的。

架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。

怎么作？尽可能选择源自实际项目的框架，警戒那些象牙塔里面的产品。

三、关键问题可能不是出在技术上

简单的项目也会翻船，并且这不是个别状况。大多数项目是人完成的，人才是项目成败与否的基础。

若是团队里有人工做方式不正确，拖项目后腿怎么办？有一种很是古老但很完善的技术能够帮助你解决问题。它多是人类历史上最重要的技术创新，这就是对话。

有几个简单的对话技巧能够显著改善对话效果：

不要把对话当成对抗。

不要带着情绪与人沟通。

尝试经过沟通设置共同的目标。

四、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格

沟通必须简明清晰，没有人愿意阅读冗长的架构决策文档，架构师言简意赅的表达观点是项目成功的必要条件。

架构师每每忽略了本身也是领导者。做为领导者咱们必须得到同伴的尊敬才能顺利开展工做。全部的成员都但愿有明确的沟通和开明的领导。只能这样才能改善沟通效果，创建团结健康的工做环境。

五、架构决定性能

你们彷佛理解，事实并未如此，有些架构师认为简单的更换底层架构就足以解决应用的性能问题，他们极可能轻信了“经测试产品性能超出竞争对手25%”，好比从4ms到3ms，这1ms放在一个性能极低的架构里几乎能够忽略不计。

归根结底，全部产品和架构必须遵循分布式计算和物理学的基本原理：运行应用和产品的计算机性能有限，经过物理链接和逻辑协议实现的通讯必然有延时。所以，应该认可架构才是影响应用性能和可伸缩性的决定因素。性能参数是没法简单的经过更换软件，或者“调优”底层软件架构来改善的，咱们必须在架构的设计和从新设计上投入更多的精力。

六、分析客户需求背后的意义

顾客和最终用户一般提出的所谓需求，只是他们心目中可行的解决方案，并非问题惟一的解决途径，当了解顾客的需求背后的意义，咱们能够为顾客解决真正的问题并可能下降难度。

七、起立发言

许多架构师都是从技术岗位上成长起来的，他们擅长和机器打交道，然而架构师更须要与人打交道，不管劝说开发人员接受具体的设计模式，仍是向管理层解释购买中间件的利弊，沟通都是达成目标的核心技能。

有经验的架构师会很重视推销本身的想法也明白有效沟通的重要性，其中一个简单又实用的技巧是在2人以上的场合发表意见时请“站起来”，起立发言很是重要尤为是当其余人坐着的时候。

当你站起来的时候无形中添加一种权威和自信，天然就控制住了场面，听众不会随意打断你的发言，这些都会让你的发言效果大为改观，你会发现站立能够更好的用双手和肢体语言。在10人以上的场合，起立发言方便你与每位听众保持视线接触。眼神交流、肢体语言等表达方式在沟通中的做用不可小觑。起立发言还可让你更好的控制语气、语调、语速和嗓门，让你的声音传的更远。当你讲到重点内容时，注意放慢语速。发声技巧也能显著改善沟通效果。

比沟通事半功倍，起立发言是最简单、有效的方法。

八、故障终究会发生

硬件会出错，因而咱们增长冗余资源来提高系统的可靠性，同时也增长了至少有一台设备出错的几率。

软件会出错，增长额外的监控程序也会出错。因而咱们又为自动化增长监控，结果是更多的软件，致使更高的故障率。相似的如：三里岛核电站泄漏事故

既然必然会出错就须要事先设计好防范故障的模型，以应对威胁系统安全的意外状况。

九、咱们经常忽略本身在谈判

咱们都面临过削减预算的要求，若是资金运转促襟见肘，技术方案只能委屈求全。

好比以下情景：

“咱们真的须要这东西吗？”项目投资人发难道。

尽管真的须要，咱们一般也不能这么回答，由于此时咱们是在谈判，此时咱们须要认清本身的角色，不能把本身当成工程师，并且投资人明白他在和你谈判，咱们应该这样回答"真的须要吗"这类问题：

“单台服务器天天至少崩溃3次，没有第二台咱们甚至没法跟董事会演示，事实上咱们须要4台服务器，构成2组，这样在须要时断开一组而没必要被迫关闭系统。即便有一台出现意外，也不影响系统正常运行”

十、量化需求

速度快不能算做需求，响应灵敏和可扩展也不能算需求，由于咱们没法客观地判断是否知足了这样的条件。

正确的描述需求应该像这样：“必须在1500ms内响应用户的输入。在正常负载下，平均响应时间控制在750ms-1250ms之间。因为用户没法识别500ms之内的响应，因此咱们不必将响应时间降到这个范围一下。”

十一、一行代码比500行架构说明更有价值

架构说明书（specifications）很重要，由于它描述了构建系统的模式，可是静下心来全面完全地理解架构——即从宏观上把握组件之间的交互，又着眼于组件内部的代码细节——也很重要。

架构师每每容易被抽象的架构所吸引，沉迷于设计过程。事实上仅有架构说明书是远远不够的。软件项目的最终目标是创建生产体系，架构师必须时刻关注这个目标，牢记设计只是达到目标的手段，而不是目标。

若是亲自开发，应该珍视本身花在写代码上的时间，千万别听信这会分散架构师精力的说法。这样既能拓展你的宏观视野，也能丰富你的微观世界。

十二、放之四海皆准的解决方案

架构师应该坚持培养和训练“情景意识”——由于咱们遇到的问题千差万别，不存在放之四海皆准的解决方案。

“情景模式”：调查有经验的架构师处理复杂问题的方式。有经验的架构师和设计师的答案一模一样：只须使用常识....【一个】比“常识”更贴切的说法是“情景意识”——在给定情景下对合理性的把握。架构师经过学习和实践，不断积累的案例和经验，创建足够的情景意识。他们一般须要十年的磨练，才能解决系统层次的问题。

1三、提早关注性能问题

商业用户的需求主要表现卫队功能的要求。系统的非功能特性则由架构师负责，包括：性能表现、灵活性、持续正常工做时间、技术支持资源等。可是对非功能特性的初始测试每每被拖到开发周期的最后阶段，有时还由开发团队来操刀，这样的错误家常便饭。

在项目周期的最后阶段才关注性能问题，会致使咱们错失大量历史信息，这些信息包含性能变化的细节。若是性能是架构设计的重要指标，就应该尽早展开性能测试。在采用敏捷方法开发的项目中，若是有2周为一个迭代周期，我认为性能测试的开始时间最迟不能晚于第三次迭代。

坚持技术测试是须要耐心和毅力的，不管是搭建合适的测试环境，采集适当的数据集，仍是编写必要的测试用例，都须要投入大量的时间。

1四、架构设计要平衡兼顾多方需求

平衡兼顾各方的要求和项目的技术需求

CEO须要控制成本

运营部门要求软件易于管理

二次开发人员要求软件代码容易学习方便维护

业务部门：旅行合同义务、创造收益、树立客户口碑、控制成本，创造有价值的技术资产

技术部门：确保软件的功能

1五、草率提交任务是不负责任的行为

傍晚时候，团队正在完成本次迭代的收尾工做，一切循序渐进、有条不紊。只有约翰赶着赴约有些急躁，他仓促写完本身的代码，编译、检入，而后匆匆离开。几分钟后红灯亮起（许多采用敏捷开发方法的软件公司（例如ThouthtWorks）在每一个团队成员的桌上放置一盏3色灯，用来表示当前的集成状态，黄色正在集成，绿色集成成功，红色集成失败），构建失败。约翰没来得及执行自动测试就草率地提交了任务，连累你们没法继续工做。正常的工做秩序全被打乱了。

这个时候架构师就该发挥做用了，营造一种团队文化，以维护流程通畅为重，以浪费他人时间为耻。要作到这一点，务必在系统内实现完善的自动测试功能，纠正开发人员的行为。

沉下心来改变系统的生产效率，缩短流程避免各行其是，才能缩短开发时间。总之必定要杜绝一切草率提交任务的念头。
---------------------

1六、不要在一棵树上吊死

负责构建系统的人彷佛没法接受这样的事实：没有哪一种数据类型、消息格式、消息传送机制，甚至主流的架构组件、策略、观点用来可以用来解决全部的业务问题，毕竟当你们都但愿摆脱业务需求不断滋生的意外和烦恼。

才用多钟表现方式、多钟传输方式不是为了消遣。应当认识到，经过分解系统的非功能参数，能够为客户提供多样化的解决方案。

1七、业务目标至上

在商业化的背景下开发企业应用，架构师必须成为业务部门和技术部门沟通的桥梁，周旋调解，兼顾双方利益，同时业务目标来驱动项目 开发。业务目标和实际的开发条件应该成为架构师主持制定决策的参照系统。

在启动一个软件项目以前，应当制定计划，明确投资回报的预期。架构师必须把握这个预期，并预估该项目的商业价值，避免作出错误的技术决策，形成经费超支。

用业务目标驱动项目开发，才能保证软件开发团队的长远利益。

1八、先确保解决方案简单可用，再考虑通用性和复用性

许多用来实现基础设施的代码，包括组建、框架、类库、基础服务，广泛存在一个问题，它们设计一贯强调通用性而不考虑具体应用。

若是存在多个可实施方案难以取舍，“先简单后通用”原则能够成为最终的评判标准。

虽然不少架构师重视通用性，但这样作是有前提条件的。并不是全部人都须要通用性，愿意为它掏钱。

1九、架构师应该亲力亲为

称职的架构师应该经过示范领导团队，架构师一般都取得过不错的业绩，有份出彩的简历，容易得到业务人员和技术人员的青睐。但除非他能展现本身的实践能力，不然很难赢得团队的尊重，团队成员将没法从他身上学到东西，你们甚至难以在他的领导下作好本职工做。

20、持续集成

架构师（不管是应用架构师仍是企业架构师）都应该在项目中鼓励推广持续集成的方法和工具。

如今持续集成已经取代了“尽早构建，常常构建”（build early and often）的提法，它确保当前的开发不会出现意外，是一种下降风险的技巧。

构建应用程序是持续集成最主要的内容，它一般是自动执行的，能够设置在夜里执行，或者当源代码改变时自动触发。固然你也能够选择手动构建。

2一、避免进度调整失误

致使项目失败的缘由不少，最多见的是中途临时调整进度。

改变计划回答带来如下问题：

仓促的进度会致使拙略的设计、蹩脚的文档，可能引起质量问题，致使用户拒绝签收

仓促完成代码致使bug增多，测试不充分增长测试中可能出现的问题

以上问题均能引起产品质量问题，而解决产品质量的问题代价更高。最后的结果是成本不降反升，一般项目就是这样失败的。

2二、取舍的艺术

架构师应该明白鱼和熊掌不可兼得的道理。若是2个性能自己就是冲突的，知足一项就会致使另外一项失败或者总体失败。

2三、打造数据库堡垒

建立牢固的数据模型要从第一天开始

牢固的数据模型既能够保障当前的数据的安全，又为从此提供可扩展性。要保障数据安全就必须隔离来自应用层的bug（在不断变化的应用层中这些bug无处不在，不会由于你的勤奋而消失），必须严格遵照引用完整性规则，尽可能使用域约束规则，还要选择恰当的键，即保证数据的完整性，又遵照约束规则。要实现可扩展性，就必须正确地将数据标准化。以便从此在数据模型上添加架构层：千万不要偷懒走捷径。

为了妥善保护数据库必须拒绝无效数据，阻止无心义的关系。在定义键、外键、域约束时，应该采起简洁的容易被理解和验证的名称，使他们含义不言自明。数据模型中的域规则也要作到物理化和持久化，避免他们在应用逻辑发生改变时被删除。

为了充分发挥关系型数据库的做用——让它真正的成为应用的一部分，而不只仅是存放数据的库房——必须从开始构建数据库时，就深入理解业务需求。随着产品的演变，数据层也会发生变化。

2四、重视不肯定性

当你面临2中选择的时候应该仔细考虑设计中的不肯定性。

迫于压力，人们经常为了决策而决策。这时能够借鉴期权思想（指在期货交易中，权利的受让能够在未来的某个约定的时间，根据当时的状况决定是否行使权利，即推迟作决定时间），当你在不一样的系统开发路线之间犹豫不定时，不要急于作出决策。推迟决策，直到掌握更详实的信息，以便作出更可靠的决策。但也别太迟，要赶在这些信息失效前利用他们。

2五、不要轻易放过不起眼的问题

问题出现时，虽然个别团队成员会发现一些端倪，但每每因为大多数人认识不到其严重性，这些问题不是被忽略就是被搁置，知道变得难以解决。

注意形成的缘由和哪些方法克服这些消极因素。

2六、让你们学会复用

有这样一种观点，认为设计优良的框架、细致考虑并精巧实现的架构天然会被人们重复利用。

但也是在知足下列条件下擦可能被复用：

你们都知道它的存在

你们知道如何使用它们

你们认识到利用已有资源好过本身动手

2七、架构里面没有大写“I"

英文单词架构（architecture）里面有字母”i"但不是大写的“I”。它表明的不是那个喜欢唤起别人关注，喜欢凌驾于众人之上的“I"(自我）。

自我多是咱们这最大的敌人。

如何避免犯错误？

需求不会撒谎。

重视团队合做。

检查你的工做。

自我检讨。

2八、使用”一千英尺高“的视图

用来了解正在开发的软件质量如何

在架构图中，系统是由若干个小方框组成的，方框之间的连线表明着各类含义：

依赖关系、数据流、共享资源等。

这种图比如从飞机上俯瞰地面上的风景，咱们称之为“三万英尺高”的视图。另外一种典型的视图是源代码，比如占在地面上看大地。两种视图都没法冲分钟展示软件的质量：前者太抽象，然后者细节太多，以致于咱们看不清整个架构。很显然咱们须要一个介于2着之间的视图——“一千英尺高”的视图。

"一千英尺高“的视图提供的信息来自恰当的层次，囊括大量数据和多钟度量标准，例如方法数，类扇出数和圈复杂度。具体的视图与特定的质量属性密切相关。

一旦咱们绘制出合适的视图，判断软件质量就更客观了。

2九、先尝试后决策

建立一个应用须要做出不少决策。有些决策设计挑选框架和函数，而另外一些则须要选定特定的设计模式。

架构师应该持续关注那些立刻要制定的决策，架构师能够在决策以前，要求几个开发人员商量解决方案，比较不一样解决方案的优势和弊端。

对同一个问题尝试2种或者2种以上的解决方案，多是代价最低的选择。过后发现方案不合适或者是没人发现方案不合适都是糟糕的状况。

30、掌握业务领域知识

高水平的软件架构师不只要懂技术，还要掌握问题空间对应的业务领域的知识。缺少业务领域知识的架构师不能顺利地解决问题，没法把握业务目标和业务需求，也就难以设计有效的架构来知足需求。
3一、程序设计师一种设计

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

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

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

3二、让开发人员本身作主

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

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

3三、时间改变一切

选择值得投入精力的工做

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

别跟之前的工做过不去，你如今看重的设计思路，可能2-3年后就会被本身否认。

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

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

3五、控制项目规模

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

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

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

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

3六、架构师不是演员，是管家

架构师接受新项目，都渴望证实本身的价值，这是人之常情。

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

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

架构师要知足不一样领域的客户需求，而这些领域的专业知识一般是架构师所不具有的。

3七、软件架构的道德责任

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

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

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

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

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

3八、摩天大厦不可伸缩

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

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

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

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

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

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

如今能够采用基于文本协议（text-based protocols）了。这些新技术以特定格式的文本做为载体，便于全部人编写和理解，为混合开发提供了史无前例的可能性。

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

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

40、性能至上

性能指标和其余指标同样重要。

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

咱们一般把系统响应用户输入的时间做为衡量性能的标准。

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

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

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

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

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

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

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

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

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

4二、学习软件专业的行话

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

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

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

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

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

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

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

4三、具体情境决定一切

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

“毕竟，没有理念自己也是一种理念”

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

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

4四、侏儒、精灵、巫师和国王

架构师比如国王，应该熟悉各类人的性格特色，招聘不一样性格的人加入本身的团队。

安排任务时应该时刻考虑全部开发人员的性格特色。为不一样性格的团队成员安排合适的任务，若是你们有机会磨合、相互适应，就能轻松化解决各类难题。

4五、向建筑师学习

建筑师名言

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

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

.....

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

天底下没有完美的建筑。

建筑师首先应该是伟大的雕塑家，或者伟大的画家，不然他不过是个建筑工人。
---------------------
4六、避免重复

你的开发人员在重复无需思考的工做吗？代码里面反复出现某些类似的片断？某些代码是复制粘贴后稍加修改而成的，若是出现这些状况，说明团队工做效率不高。

软件开发的真理：复制时魔鬼

                              重复性的工做拖累开发的进度。

消灭重复的内容是你的责任，为此，应该从新研究框架，创造更完善的抽象机制，请专门制做工具的程序员（toolsmith）帮你完成切面框架（aspect framework），使用代码生成器。要想消灭重复内容必须有人采起行动。

4七、欢迎来到现实世界

工程师偏心精确，成天和0和1打交道的工程师更是如此。

现实世界不是二进制的。顾客有可能撤销确认过的订单，支票有可能跳票，信件可能丢失，付款时间可能延迟，许下承诺还可能失信。

这些已经够糟了，可分布式系统又带来了新的不一致性。服务有可能失效，状态有可能在毫无征兆的状况下改变，事务处理可能得不到保证。

分布式系统不可是松耦合、异步、并发的，并且不遵照传统的事物语义。

4八、仔细观察别试图控制一切

妄想掌控一切的架构师只能设计出紧耦合的、脆弱的解决方案，这一套已经行不通了。咱们必须启动必要的辅助机制。

咱们已经进入分布式、松耦合系统的时代。构建松耦合的系统多少有些麻烦，咱们但愿系统足够灵活，别由于一点点小的改动就支离破碎。

随着系统的配置愈来愈灵活，当前的系统配置包含了更多的信息，为了便于理解，必须从中提取模型。好比，搞清楚哪一个组件负责向逻辑信道发送消息，哪一个组件负责接收消息，就应该把组件间的通讯关系用图标模型记录下来。

与模型驱动架构不一样，你先构建出灵活的架构，而后从实际的系统状态中提取模型。

4九、架构师比如两面神

罗马神话里面，两面神是司守门户和万物始末之神。他有两张面孔，凝视2个不一样的方向。

两面神兼顾先后，过去与将来。架构师在不一样的对象之间架起桥梁，好比梦想和现实、过去的成功和将来的方向、业务目标与开发i限制。

咱们应该以两面神为榜样，工做上严格把关，综合考虑新状况与老经验，在成熟技术上不断创新，既知足当前的业务需求，又兼顾将来的额发展规划。

50、架构师当聚焦于边界和接口

“哪些应该在一块儿，哪些应该分开”

5一、助力开发团队

架构师能够施加约束，也有机会成为推进者。

要确保开发人员拥有他们所需的工具。

要确保开发人员拥有所需的技能，确保他们可以得到必须的培训。

同时，也要尽量的参与到开发人员的选拔中。

只要不违背软件设计的整体目标就让开发人员本身作决策。

最后，保护开发人员，不要让他们卷入到不那么重要的工做中。

5二、记录决策理由

在软件开发社区，对于文档尤为是关于软件自身设计的文档的价值，争论颇多。分歧通常集中于两处，一处是“详细的前期设计”的有效价值，另外一处则是使设计文档化和不断变化的代码库保持同步的难易程度。

记录软件架构决策理由的文档，长期有用，无需为之付出过多维护精力，具备很高的投资回报价值。

根据项目的不一样灵活选择合适的文档格式来记录架构决策的方方面面，格式能够是文本、维基、或博客形式的速记备忘录，也能够使用较正式的模板。

好比这些文档：

能够做为和开发人员沟通的工具，说明应遵循的重要架构原则

当开发人员对架构背后的逻辑提出质疑时，使团队可以就事论事

向经理和利益相关者说明这样构建软件的确切缘由

把项目移交给下任架构师

好处是：

它逼着你说出理由时，有助于确保基础是扎实稳固的、

若是相关条件发生变化，须要对决策从新评估，它能够做为一个起点

5三、挑战假设，尤为是你本身的

延迟判决法则：“臆断是事情搞砸的根源”

软件架构师的最佳实践代表，应该记录下每一个决策背后的理由，当这一决策包含权衡（性能vs.可维护性，成本vs.上市时间等）时尤须如此。

有些小道消息：

开源软件不可靠

位图索引带来的麻烦比好处多....

确保这些假设清楚明确，对后继者和将来的从新评估来讲很是重要。更重要的是拿出证据。

不要忽略相关这个词语。

事实和假设是构建软件的两大支柱。务必确保软件的基石坚实可靠。

5四、分享知识经验

从全部的失败的经验中，咱们能够学到不少东西。在像软件开发这般年轻的行业中。为了持续发展传播经验和知识相当重要。每一个团队在本身的小世界小角落里所学到的东西，可能会在全球产生影响力。

5五、模式病

人们记录和发现模式，避免后来人从新发明车轮。

对于软件架构师而言，设计模式是极有价值的可用工具之一。使用模式，可以创造更易沟通更易理解的通用解决方案。模式与良好设计息息相关，若是发现本身试图把最喜欢的模式硬套在不适用的问题空间上，那么你也许是”模式病“患者。

不要让一展模式功底的欲望遮掩了务实真知。

5六、不要滥用架构隐喻

架构师喜欢使用隐喻（metaphor）。对那些一般比较抽象、复杂和变化的移动的目标，隐喻提供了良好的具体媒介。找到实物做为正要构建的东西的隐喻，会更容易沟通和讨论架构全局。

滥用架构隐喻常常会出现问题，让架构师不知所措，好比：

业务领域的客户开始愈来愈喜欢系统隐喻，这时，系统还在构想中，在这种状况下全部各方共享的是最乐观的可能解读，但其中并无包括任何须要的约束。

开发团队认为隐喻比实际业务更重要。因为团队耽溺于隐喻，你不得不开始修正那些古怪的决策。

所交付的系统包含了许多遗留名称，从早已老旧过期，有待从新鉴定隐喻，到屡次重构和重复挖掘的概念。

5七、关注应用程序的支持和维护

应用程序的支持和维护永远不是过后才考虑的事情。因为应用程序80%的声明周期都在维护上。

开发人员和支持人员拥有的技能不一样，就像开发/测试环境和生产环境有大相径庭的目的同样。

系统管理员会遇到的问题：

*系统管理员不能从新提交请求消息来重现问题。

*一旦投入使用，就没有调试器能够用了。

....

就会出现如下症状：

*大多数问题都须要开发人员参与。

*支持团队讨厌新的应用程序。

....

为了确保应用程序脱离开发人员之手后能成功运行，应该作到：

*理解开发人员和支持人员确实具备不一样的技能

*在项目中尽早的引入支持负责人。

...

当系统管理员很开心的时候你们都会很开的。

5八、有舍才有得

有时，接受某种约束或放弃某个特性，可带来更好的架构，这种架构在构建和运维上都会更加简单，并且成本更低，每每能产生富有创造性和创新性的结果。

5九、先考虑原则、公理和类比，再考虑我的意见和口味

若是是单凭我的经验、意见和口味建立的架构是没有考虑原则、公理、和类比所带来的好处的。

这样作，架构文档化会更容易，从描述架构所遵循的原则开始便可。

原则清晰的架构可以把架构师解放出来，使其免于全面复审而忙得不可开交。

原则和公理确保了架构的一致性。

60、从“可行走骨架”开始开发应用

为了实现、验证和不断发展应用架构，一个很是有用的策略，即是从Alistair Cockburn所谓的“可行走骨架”开始。“可行走骨架”是对系统的最简单实现（a minimal implementation),它贯穿头尾，将全部的主要构件组件链接起来。从可工做的最小系统开始训练所有的通讯路径，能够带来“正朝着正确的方向前进”的信心。

对于大型系统一般是由多名开发人员共同构成，对于大型系统而言更多的协调工做是必不可少的。

从“可行走骨架“开始，保持系统一直运行可用，递增式地进行培育，使其逐步增加。
---------------------
6一、数据是核心

软件开发人员最初将软件理解为命令、函数和算法构成的系统。

若是稍稍后退站远一点，计算机只不过是能访问与操做一堆数据的时髦工具。

代码在计算机中运行时，底层数据的状态不断发生变化。

举例而言，若是想了解Unix操做系统，经过源码逐行挖掘是不大可能奏效的，可是若是你读过一本unix内部数据结构的书，即可更好的了解unix底层是如何运行的。从概念上开看，数据比代码更加精炼，也更好理解。

即便对于最复杂的系统，经过这种面向数据的视角，即经过底层信息的结构总体开看待系统，也能够将之缩减为细节的有形集合。而后下降其复杂性。

数据在大多数问题中处于核心地位，业务领域问题由数据蔓延到代码中。

诚然，软件架构中的许多问题确实和数据相关。

从设计角度来看，大多数系统的关键问题，就是要在正确的时间从系统获取正确的数据。

6二、确保简单的问题有简单的解

 软件架构师解决了许多很是困难的问题，但也会解决一些相对容易的问题，对于简单的问题，不要使用复杂的解决方案。

为复杂问题付出的直接成本可能看上去很小，可是其潜在成本要大得多。为问题的解决方案付出的代价不只仅只是在实现和维护上。

架构师会从主观的判断或潜在不肯定性需求出发，产生调整解决方案的强烈冲动。但记住一点：试图猜想将来的需求时，错的几率是50%，错的很是离谱的几率是49%。

6三、架构师首先是开发人员

无论解决方案多么优秀，决定实现可否成功的最重要因素之一是让开发人员愿意接下任务。

虽然不是工做的一部分，架构师仍是会常常去处理一些比较复杂的任务。这样作的目的有两个：第一，这是一种乐趣，并且还能帮咱们作到宝刀不老；第二，这有助于向开发人员代表，我不是碰到麻烦时会干吹烟卷却一筹莫展的架构师。

6四、根据投资回报率进行决策（ROI）

咱们对项目所作的每个决策——不管是技术、过程，仍是与人相关——均可以看作一种投资形式。

回报率（rate of return），也成投资回报率（Return On Investment,ROI)，是衡量投资是否成功的标准之一。

将架构决策视为投资，并将相关的回报率也一并考虑在内。在判断每一个决策选项是否务实或恰当时，这种方法颇有用。

6五、一切软件系统都是遗留系统

即便系统十分前沿，采用了最新的技术开发而成，但对接手它的下一我的而言，它也会是遗留系统（legacy）。必须面对这种状况！在今天，软件很快便会过期，这已经成为软件的自然属性。若是软件可以存活下来哪怕只有数月的时间，都必须认可一点：负责维护工做的开发人员确定要对软件进行缺陷修复，这是不可避免的。这引出以下几个问题。

*清晰性：各个组件和类的角色必定要清楚

*可测行：系统易于验证吗？

*正确性：结果和设计或指望的一致吗？

*跟踪性：可容易修复紧急缺陷

6六、起码要有2个可选的解决方案

对于某一个问题，若是只考虑了一个解决方案，那你就有麻烦了，在给定的约束条件下，寻找问题的最佳方案，指望第一个解决方案即知足所有的需求和约束，几乎是不可能的。

这种问题即便有——也绝少是真地因为缺少可选方案而形成的，它更多是架构师缺少特定问题域的经验所致。

6七、理解变化的影响

好的架构师可以将复杂性降到最低程度，他在解决方案中给出的抽象，应该可以为更高的层次提供坚实基础，同时，还应该能足够务实地应付将来的变化。

优秀的架构师可以深入理解变化带来的影响，这种影响不只限于彼此隔离的软件模块之间，并且包括人与人之间，以及系统与系统之间。

变化有多种不一样的表现形式：

*功能需求的变化

*可扩展性需求的变化

*系统接口被修改

。。。。

幸运的是许多工具和技术能够用以减轻变化的影响：

*进行小规模的增量渐变

*构建可重复运行的测试用例

*跟踪好依赖关系

*下降复杂性

*自动化重复任务

6八、你不能不了解硬件

对于许多软件架构师，硬件容量规划问题是一个超出其温馨区的主题，但它的确是架构师工做的重要组成部分。

若是没有硬件方面的专业知识，预估待开发系统的硬件配置是很是容易出错的。比起采购超出实际所需的硬件，为容量规划留出预算是更为经济的。

6九、如今走捷径，未来付利息

长远看来，系统维护将比项目初期的开发消耗更多的资源。

测试：使用测试先行的设计，进行单元测试

碰到架构问题或设计缺陷，做为架构师，必定要坚持成本还很低廉时就动手。搁置越久，为之付出的利息也就越高。

70、不要追求完美，足够好就行

软件设计师，尤为是架构师，在评估针对某个问题的解决方案时，会倾向于考虑它是否优雅完美。有些瑕疵只须经由一些调整或迭代重构即可消除。

建议：不要屈服于企图使设计或实现达到完美的诱惑！把目的设定在“足够好”就行，当已经达成目标时就停下来。

7一、当心“好主意”

“好主意”会杀死项目。有时候杀伤力会很快见效，但更常见的症状是：因屡屡错过的里程碑和不断攀升的缺陷数量，项目苟延残喘，最终不治身亡。

“好主意”：那种诱人2的、不用想都知道的、外表无辜、觉得不可能会产生伤害的那种“好”注意。

“好主意”真正的邪恶之处在于它的“好”。

若是出现下列关键词，要当心了：

*若是....会更酷。

*“嘿，他们刚刚发布了YYY框架的XXX版本。咱们应该立刻升级”。

7二、内容为王

我见过无数这样的设计，它们大都永无止境地强调需求、设计、开发、安全及可维护性，但从未关注系统的真正要点——数据。

7三、对商业方，架构师要避免愤世嫉俗

雇主但愿偶们可以解决问题，倾听和了解雇主的业务，是咱们必须掌握的最为关键的技能。

成为优秀架构师的秘诀之中有一个关键要素，那即是:要对工做满怀激情，但不要是那种带着愤怒和火气的“激情”。

7四、拉伸关键维度，发现设计中的不足

应用程序的设计轮廓，最初是基于特定的业务需求、所选择的技术或现有的技术、性能要求、预期的数据量，以及构建、部署和运营上可用的财务资源。不管采用什么样的解决方案，都要求能知足或超越当前环境下的要求，成功运行起来，不然这就不称其为解决方案了。

拉伸解决方案的关键维度，看看哪些方面会遭到破坏。

7五、架构师要以本身的编程能力为依托

在架构上，架构师都指望可以建立出精巧的设计和完美的抽象，来优雅的解决手头的问题。若是能再项目中多安插些技术那就更让人有成就感了。可是最终要实现设计的不是架构师。若是开发人员须要去实现那些架构上的“杂技”，那将会对整个项目形成巨大影响

为项目设计架构时，对实现的每一个设计元素所须要的工做量，要作到心中有数；若是之前曾开发过其中某种设计元素，那么估算所需的工做量将会容易得多。

不要在设计里面使用本身没有亲自实现过的模式，不要使用本身没有用之写过代码的框架，不要使用本身没有亲自配置过的服务器。
---------------------
7六、命名要恰如其分

若是都不知道一个东西应该叫什么，那你确定不知道它到底是什么。若是你不知道它到底是什么，那么你确定不能坐下来为它编写代码。

7七、稳定的问题才能产生高质量的解决方案

最好的架构师不是要去解决难题，而是围绕难题开展工做。架构师要可以将四处弥漫的软件问题圈起来，并画出其中的各类边界，确保对问题由稳定的、完整的认识。

这些问题应该具备如下特性：

*内聚性：问题块在概念上市统一的，其中全部的任务、数据和特征都是相关的。

*可以很好地和其余块分隔开：这些块在概念上进行了规范化处理；他们不多重叠或者根本不重叠。

7八、天道酬勤

架构师经常被描述为一种注重创造力与问题解决能力的职业。除了创造力外架构师还应当具有另外一项一样重要的特质——勤奋，勤奋指不少方面，但归根结底是指具有坚强的毅力，而且对系统的每项任务和每一个架构的目标都能投入足够精力。

勤奋常常和平凡携手同行。

勤奋还意味着要求架构师必须真正作好那些看似简单的任务，坚守承诺。

7九、对决策负责

因为软件架构师比组织中的其余人更有影响力，因此他们必须对本身作出的决策负责。

研究代表有超过三分之二的软件项目要么完全失败了，要么未能成功交付（项目延期、预算超支、客户不满意）。究其根本缘由，有许多事因为架构师作出了不当的决策，或者没法最终执行正确的架构决策。

如何作出有效的架构决策：

首先,对决策的过程有充分认识

第二，按期对架构决策进行复审

第三，要贯彻架构决策

最后，能够将一些决策委托给响应问题域的专家，没必要出自其自身。

80、弃聪明，求质朴

智力超群、神机妙算对任何人来讲都是值得称道的品质。对架构师来讲，这些素质尤为被看重。

然而，聪明也包含某些额外的隐含意义。它也暗指能快速想出脱身之计的能力，但这种本领最终要依靠一些小伎俩，骗局或掉包计。

聪明的设计僵硬难改，其细节会对全局产生太多牵扯，每每会一触即毁。

8一、精心选择有效的技术，毫不轻易放弃

做为软件设计开发的老手，每一个架构师一般都有一些让本身屡屡取胜的武器用来武装本身。这些技术因为种种缘由深受架构师青睐，排在其首选解决方案的前几位。这并非说某种技术一旦入围就能够永久罔替。

选择新技术虽然有风险，但其价值能为你带来质的飞跃。

考虑技术将来的前景。

软件架构师工做很大一部分，是要选择用以攻克难题的合适技术。

8二、客户的客户才是你的客户

在软件会议需求会议上，要这样想象：你的客户并非你的客户。实际上真的不难作到，由于，事实即是如此。若是你的客户的客户赢了，那么你也赢了。

若是你在编写一个电子商务应用程序，那么应该考虑的应当是那些会在那个网站上购物的人的需求。若是你的客户有意无心的忽视他们的客户所看重的重要事项——那么请放弃这个项目。

需求收集会议不是项目实现讨论会议。

8三、事物发展总会出人意料

事物的发展总会出人意料。在设计时，人们很容易陷入误区，投入太多的时间在设计上。

设计中的这些微小变化累积起来，很快就须要对设计进行一次较大的变动。

设计是一个不断发现的过程。

8四、选择彼此间可协调工做的框架

软件框架是系统的基础，在选择时，不只要考虑每一个框架自身的质量和特性，也要关注共同构成系统的各个框架之间是否能和谐相处。

若是框架间有重叠，则要确保了解候选框架在逻辑域或关注层面上的重叠程度。

为了尽可能减小框架间互有重叠的几率，要根据系统需求的应用场合，选择精专强大的框架。

系统应该由多个相互独立的框架构成，其中每一个框架都精专于各自的领域，但同时又很是简洁、包容、灵活。

8五、着重强调项目的商业价值

对于非软件业从业人员，软件架构显得虚无缥缈，架构项目在争取资金时会遭遇到困难。

大众心理学代表，大部分人会相信亲眼所见的东西。而拥有预算决定权的人，几乎都是受商业价值驱使的。

下列五部，会成功将架构提案打形成经典的商业项目：

一、造成价值描述（提升 生产力，改进效率的能力）

二、创建量化度量标准

三、回过头来关联传统商业的衡量方式

四、知道该在哪里中止

五、寻找恰当的时机

8六、不只仅只控制代码，也要控制数据

源代码的控制和持续集成，是管理应用程序构建过程和部署过程的优秀工具。数据方案和数据内容经常会根据源代码的变化而变化，他们也是这一过程的重要组成部分，所以也要对之进行相似的控制。

数据库的变化不该该影响构建活动的连续性。要把数据库也做为一个构建单元包含在内，作到一次性构建整个应用程序。数据迁移不该该做为一种补救措施。

8七、偿还技术债务

对任何已投入实用的项目（也就是说，有客户在实用产品），不管是要修复缺陷，仍是要添加新功能，总有必须修改产品的时候。在那点上，会面临2个可能选择：花合适时间“一次作对”，或者取巧走“捷径”，争取尽快推出修改过的产品。

做为架构师必须决定怎么作才有意义。

8八、不要急于求解

架构师多半是开发人员出身。开发人员的主要职责是解决编程问题。相比架构问题编程问题的范围更狭窄。不少编程问题是很小但比较棘手的算法问题。

架构师和开发人员所以学会了迅速进入问题解决模式，但有时候没有解决方案才是最好的而解决方案。许多问题根本不须要解决，看似问题是由于咱们只关注表面症状。

学会审视问题自己。

看看可否改变问题。

咱们必须戒除“问题解决迷恋症”。

8九、打造上手的系统

咱们十工具的制造者。咱们制造的系统，必定要可以帮助人们——一般是其余人——作事，不然就是去了存在的意义，咱们也将没法从中获取报酬。

用户体验应该是“上手的"。

90、找到并留住富有激情的问题解决者

组建一支汇聚优秀开发人员的团队，是确保软件项目成功很是重要的事情之一。一旦建成便竭力维护。

提放批评过分。批评过分，可能会扼杀开发人员的创造力，下降其生产力。更糟糕的是，可能会在团队内部形成纷争。

以正确的方式经营开发团队，其重要性不言而喻。
---------------------
9一、软件并不是真实存在

软件工程常常被拿去和完善的传统学科——如土木工程——进行对比。这些类比有个问题，和这些传统实践制造的有形产品不一样，软件并不是真实的存在。

业务和软件都是活生生、会变化的实体。业务需求可能会因新近收购的业务伙伴和营销战略而迅速变化。

业务需求极可能会发生变化，由于咱们构建的产品是柔韧的。

记住，需求文档不是蓝图，软件并不是真实存在。咱们创造的虚拟物比实体物更易于改变。

9二、学习新语言

架构师必须让别人能理解你。

业务人员专业用语和程序员专业用语是有差异的。架构师须要掌握各个沟通团队的语言。

9三、没有永不过期的解决方案

今天的解决方案会成为明天的问题。

今天作出的选择，在将来很大程度上是错误的。

“分析瘫痪”是今天架构师们碰到的问题之一，此问题最大的归因，是试图去猜想对将来而言最好的技术。

9四、用户接受度问题

人们并不老是满心欢喜地接受新系统或系统的重大升级。这种情势，可能会对项目的成功构成威胁。

架构师的目标，是要去了解和衡量用户的接受度问题带来的威胁，并朝着能减轻这些威胁的方向开展工做。

“项目拥戴者”能够帮助消除用户接受度问题。这个职位的最佳人选，是能表明用户或利益相关方的人。

9五、清汤的重要提示

清汤是一种很是清澈的肉汤，上品清汤很是清澈，须要不断重复的精炼浓缩才能烹出。

设计架构也应当不断精炼浓缩。

软件中许多漏洞的需求和缺陷，可最终追溯到含糊笼统的语言描述上。拒绝模凌两可的废话。概念须要在加上“老是、永远、无论任何状况下”仍然成立。

9六、对最终用户而言，界面就是系统

糟糕的用户界面埋没了太多的好产品，最终用户经过界面访问系统。

架构师应该确保，随着架构变化而变的用户界面也要可以反应用户的指望。

不只要让最经常使用的交互易用，并且要使最终用户可以从中得到回报。

9七、优秀的软件不是构建出来的，而是培育出来的

在一开始就要设计庞大的系统几乎毫无好处可言。

设计尽量小的系统，帮助成功交付，并推进它向宏伟的远景目标不断演化。
---------------------
粗略的从后面的十几个里面提取出如下几个方面：

数据：程序的核心就是数据，数据的结构表现出数据的形态，数据可能会随着架构更新，数据库也要更新。

文档：文档是为了不反复思考而存在的，相似于代码注释，文档是对工程的注释。尤为是对架构师的每个有可能产生分歧的决策，必须用文档标明决策缘由。

推迟决定（也有其余翻译）：是软件开发模型的策略，这样有助于收集更多有关决定的信息。

团队：团队须要的不是单一的一类人，但须要的一块儿能合理分配工做并完成工做的一类人。找到好的团队成员必定尽心维护。

用户：客户至上，客户体验是架构师最好的简历，标志着软件的成功与否。

沟通：和业务部门沟通，须要学习业务部门的语言，其中涉及到一些专业词汇，避免沟通障碍。和客户沟通明白需求，和程序员沟通....

选择技术：如何选择使用的技术，要考虑的事项（如：架构师本人的技术，对于软件的性能，不一样架构一块儿融合等）

性能：相对于功能而言，性能常常被忽略。

——————
---------------------
做者：H100
来源：CSDN
原文：https://blog.csdn.net/u014449046/article/details/49390571
版权声明：本文为博主原创文章，转载请附上博文连接！