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

1、客户需求重于个人简历

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

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

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

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

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

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

怎么做？尽量选择源自实际项目的框架，警惕那些象牙塔里面的产品。

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

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

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

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

不要把对话当成对抗。

不要带着情绪与人沟通。

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

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

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

架构师往往忽略了自己也是领导者。作为领导者我们必须获得同伴的尊敬才能顺利开展工作。所有的成员都希望有明确的沟通和开明的领导。只能这样才能改善沟通效果，建立团结健康的工作环境。

5、架构决定性能

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

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

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

顾客和最终用户通常提出的所谓需求，只是他们心目中可行的解决方案，并不是问题唯一的解决途径，当了解顾客的需求背后的意义，我们可以为顾客解决真正的问题并可能降低难度。

7、起立发言

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

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

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

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

8、故障终究会发生

硬件会出错，于是我们增加冗余资源来提升系统的可靠性，同时也增加了至少有一台设备出错的概率。

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

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

9、我们常常忽略自己在谈判

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

比如如下情景：

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

尽管真的需要，我们通常也不能这么回答，因为此时我们是在谈判，此时我们需要认清自己的角色，不能把自己当成工程师，而且投资人明白他在和你谈判，我们应该这样回答"真的需要吗"这类问题：

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

10、量化需求

速度快不能算作需求，响应灵敏和可扩展也不能算需求，因为我们无法客观地判断是否满足了这样的条件。

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

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

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

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

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

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

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

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

13、提前关注性能问题

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

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

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

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

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

CEO需要控制成本

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

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

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

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

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

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

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

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