架构师劝退指南！

这是很多小伙伴问我的一个问题，最近看到Kai Niklas讲架构师的一篇文章，其中的真知灼见引起了我的强烈共鸣，尤其是后面的非技术部分。翻译过来（略有删减），分享给大家。

我事先给一位同学看了一下，他说：当个架构师太难了吧，又要精通技术，还得会沟通，平衡，营销..... 我还是争取做个技术专家吧！

扪心自问，我这个架构师在很多方面也做得远远不够，继续学习吧！如果你的未来职业目标是架构师，强烈建议仔细阅读并收藏。

在我们一头扎入细节之前，我们先得知道软件架构和架构师到底是什么：

软件架构师是一个软件专家，他可以做出高层的设计决定，规定技术标准，包括编码标准，工具和平台 -- Wikipedia

软件架构是一个系统最基本的组织方式，由其组件，组件之间的关系，组件和环境的关系表达出来。也包括决定设计和系统演化的原则。--Handbook of Software Architecture

架构可以在不同的抽象级别上完成， 不同的级别要求不同技能，有很多分类标准，我最喜欢的是这三个级别：

Application Level （应用级别）：架构的最低级别，专注于单个应用，有非常具体的设计，沟通通常局限在开发团队

Solution Level （解决方案级别） ：架构的中间层，需要关注几个应用来实现一个商业的需求，有部分高层的设计，但大多数还是具体的设计，沟通需要跨越多个开发团队。

Enterprise Level (企业级别)：架构的最高级， 关注多个解决方案，这一层的设计比较抽象，需要解决方案架构师和应用架构师去细化。沟通跨越整个企业组织。

有时候，架构师被看作不同利益相关者之间的粘合剂，比如：

水平方向：在业务人员和开发人员建立沟通的桥梁

垂直方向：在开发人员和经理之间建立沟通桥梁

技术领域：集成不同的技术和应用。

为了理解软件架构师需要哪些技能，我们得先来看看架构师的日常活动

• 确定开发的平台和技术

  
  

• 确定开发标准和规范：编码标准，工具，评审流程，测试方法等

  
  

• 根据需求，设计系统并且做出架构设计决定

• 把架构设计和决定文档化，和团队沟通

  
  

• 把高层的设计变成底层设计

  
  

• 检查、评审架构设计和代码，比如看看确定的模式和代码标准是否正确施行

  
  

• 和其他架构师、利益相关者协作

• 指导开发人员

注: 架构设计是一个持续的活动，所以这些活动会一遍一遍地完成。

软件架构师所需的重要技能

根据我的经验，阅读的书籍，以及参与的讨论，我可以列出这10个技能，每个架构师都必须具备：

设计, 决策，简化, 编码, 文档, 沟通, 估算, 平衡, 咨询, 营销

我们一个个来说，对每个技能我都会列出一些我的见解，你应该采取的行动，以便在这个技能领域持续提高。

是什么造就了好的设计？这可能是最重要，并且最具挑战性的问题，让我们先从理论开始。

架构师需要能够做出架构决定，引导项目和组织走在正确的方向。

确定优先级：有些决策非常关键，如果没有在早期确定下来，就会出现一些变通的临时措施，导致后续难以移除，变成维护的噩梦。更差的情况是，程序员需要停止工作，等你做出决策。

为了避免这种情况，必须要把这些决策按优先级排序，我建议看一看敏捷软件开发中非常流行的Weighted Shortest Job First (WSJF) 模型。

了解你的能力：不要在你的能力之外做决定，这非常关键，如果你不遵循的话可能会毁掉你架构师的岗位。

所以一定要和你的同伴明确你承担的职责和你的角色。作为低级别的架构师，你可以提出对高层架构的建议，但是不要擅自做主。我建议要经常和同伴审视那些关键的架构决定。

评估多个选项：涉及到决策时，要列出多个选项。在我参与的大多数决策中，都有不止一个可能（好的）选择。仅仅提供一个选项说明你没有完成自己的工作，没法完成决策。各种选项要通过可以度量的事实（如许可证费用，成熟度）而不是个人感情来比较，这样才能真正完成决策。

要谨记解决问题的奥卡姆剃刀原则：如无必要，勿增实体。

对于一个问题，如果你有太多的假设，很可能会走向一个错误的方向，导致不必要的、复杂的解决方案。一定要精简假设来生成好的解决方案。（可见架构工作也是一门艺术）

“摇动”你的架构设计：为了让架构设计更加简单，可以从多个角度去审视解决方案，不但要以自顶向下的方式思考，还要自底向上的方式再来一遍， 如果你有数据流或者业务流程，先从左向右看，然后再从右往左看。

经常问自己：“在一个理想的环境中，架构设计会是怎么样呢？”   “如果是那些大公司，它们会怎么做呢？” 这些问题会促使你减少假设。

退后一步：经常长时间的密集讨论，通常会得到一个高度复杂的设计，你绝对不能把它们当作最终结果，退后一步，从抽象的级别看看全局的图景，这设计还是有意义的吗？  

有时候停止讨论，第二天再继续会有帮助，至少我的大脑需要时间来处理这些信息，然后提出更好的，更优雅的，更简单的方案。

分而治之：将大问题分成小块儿，逐个解决，然后看看小块儿解决方案能不能匹配起来。

重构并不邪恶：如果找不到更好的设计，从一个复杂的解决方案开始也是可以的。如果后面遇到了问题，你需要回过头来再想一想，重构并不是邪恶的，但是再开始重构之前要确保 ：

(1）足够的自动化的测试用例，保证系统的功能不被破坏

(2)  获取利益相关者的认可。

即使是贵为企业级架构师，也就是抽象级别最高的架构师，你也得知道程序员日常工作在做些什么。否则你会遇到两个问题：

(1)  开发人员不会接受你的想法、说辞

(2)  你不会理解开发人员面临的真正挑战和真正的需要。

做一个副业项目：目的是尝试新的技术和工具，以了解当前和将来的开发方式。阅读一些教程确实不错，但仅仅是“书本”知识。只有自己亲自尝试一遍，体验一遍，你才能获得真正的经验：它为什么好？为什么差？你和一门技术呆的时间越长，你的体验就会越多，就越能帮助你做出好的决策。

找到正确的技术来尝试：你不可能尝试所有的东西，我最近发现了ThoughtWorks的技术雷达，它们把技术，工具，平台，语言和框架分为四类：采用，尝试、评估和保留。

采用的意思是“适合企业采用”。

实验指的是“企业可以在一个风险可控的项目中尝试”

评估的意思是“研究下如果对企业产生影响”

暂缓意思是“谨慎推行”

通过这种分类，你就可以找到你想尝试的新技术了。

Clean Code ：简洁优雅的代码是最好的文档，架构师一定得能区分开什么是好代码，什么是坏代码。有一本很好的书来介绍好代码和坏代码：

在可能的时候尽量自动生成文档：对于一些较为详细的文档，由于系统变化迅速，很难及时更新，所以尽可能自动生成文档：如果你是Model Driven的话可以从定义文件中自动生成文档，SWagger 和RAML都是很好的起点。

该多就多，该少就少：无论是什么文档，在同一时刻只应该把注意力放在一件事情上，只包含这件事情的必要信息，额外的信息应该保留在附录中，因为大量的文字是很难阅读和理解的。 仔细看看你的文档，问问自己：“为了理解整个东西，是不是所有的信息都在其中了？” ,“哪些信息是必须的，哪些是可以忽略的？”

根据我的观察，这是最被低估技能，如果你在设计方面特别出色，但是却无法和别人沟通，你的想法就没啥影响力，很可能失败。

演讲：向一个小组或大组做演讲是一个架构师常见的工作，如果你刚开始觉得不舒服，可以从你的最好的朋友开始，慢慢扩大的更多的人，这件事只能通过不断地实践来学习， 是个需要花费时间的过程，还需要离开舒适区，所以要保持耐心。

找到正确的沟通级别：不同的人看待事物的角度是不同的，所以你需要在他们的级别和他们交流。比如开发人员对技术细节感兴趣，经理更倾向于知道哪个选项更加省钱。

所以在沟通之前，你要看看你想交流的东西是不是在合适的级别，包括抽象度，内容，目标，动机等

经常沟通： 如果无人知晓，一个出色的架构毫无意义，要经常沟通你的架构设计以及背后的想法，定期在每个组织级别（小组，部门，公司）进行沟通，安排和开发人员，架构师，管理人员的会议，展示你的架构思路。

保持透明：定期沟通只能部分缓解缺少的透明度，你还得确保决策背后的原因透明化，特别是对那些不参加决策的过程的人，他们很难理解为什么要这么做，有什么理由。

随时准备好做一个演讲：总会有人问架构师问题，你也想快速地给出正确答案，这该怎么办呢？你可以把最重要的PPT挑出来，放在一起，随时展示并且给他们做展示，避免在一堆资料中找来找去，那样会浪费太多时间。

理解基本的项目管理原则：作为架构师或者首席开发，你经常会被要求对你的设计进行估算：多长时间能完成？需要多少人？需要什么技能？

刚开始，你可以提供粗略的估算：几天，几个月。请记住估算的时间可不仅仅是编码实现，要有需求分析，测试，改正Bug。因此你需要知道软件开发过程中的各个步骤。获得更好估算的一个方法是基于历史数据给出预测。如果你没有历史数据，可以试试COCOMO方法，如果你在做一个敏捷项目，这本书非常有帮助：

评估架构：作为一个架构师，你应该能够架构设计在当前和未来上下文中的适应性，这件事不容易，你可以准备一组问题来对架构设计进行“质询”，例如：

(1) 设计实践: 架构遵循了哪些模式？是否正确地被使用了?是否有清晰的设计和关注点分离?

(2) 开发实践: 制定代码规范了吗？被遵循了吗？代码有版本控制吗

(3) 质量保证: 自动化测试的覆盖率如何? 有静态代码分析到位了吗? Peer review做到位了吗?

(4) 安全: 架构设计中有哪些安全概念? 内置安全性如何? 渗透测试和自动化安全分析是否做到位？是否定期使用？

质量是有代价的：前面聊过系统质量和非功能性需求，如果你在架构设计上做得过度，就会增加开销，降低开发的速度。你需要平衡架构设计和功能需求，过度设计应该被避免。

解决相互矛盾的目标：一个经典的例子就是短期目标 vs 长期目标。项目通常倾向于构建最简单的方案，而架构师脑海中有长期的愿景。通常，简单的方案不适合长期的目标，并且有可能被丢弃（沉没成本）。为了避免走向错误的方向，应该注意两件事情：

(1) 开发人员和业务人员都需要理解长期的愿景及其收益。

(2) 负责预算的经理也需要参与其中，了解财务影响。

冲突管理：由于团队有着不同背景，冲突难免发生，为了找到一个相互能接受的、平衡的解决方案，架构师需要充当粘合剂，来解决这些冲突。关于沟通的理论，我是从Schulze von Thun的Four-Ears Model开始的：

拥有愿景 ：不管你是在一个什么样的项目中，不管是传统的瀑布模型还是敏捷模型，你必须需要有一个愿景，也就是你想获得的短期和长期目标，并且清晰地传递给团队成员。

由于不可能一下子达成所有的目标，我通常倾向于建立成熟度模型，让团队清楚地得知我们当前处于哪一级别。开发有很多方面，得使用不同的成熟度模型，例如开发实践成熟度模型，持续交付成熟度模型。这些模型的每个级别都有清晰的定义，团队可以轻松地度量自己在什么级别。

对于持续交付，我个人倾向于这个模型

建立社区：例如，把JavaScript程序员和架构师组织起来，每个月讨论一次，主题可以是如何解决过去和现在的技术挑战，新的技术和方法。架构师可以分享、讨论他们的愿景，程序员可以分享他们的经验，这样的会议能帮助建立一个更强大的团伙，对企业和个人都极具价值。

进行开诚布公的讨论：误解和模棱两可的根源是缺乏沟通，所以你可以安排一个固定的时间段，如每周30分钟，和同伴交换一些热门的话题，什么都可以讨论，不用刻意安排讨论的议程。可以当场解决一些小事，对于复杂的主题，安排后续的跟进。

你的想法很棒，并且和大家做了很好的沟通，但是没人愿意去做，那可能是缺乏了营销的技巧。

激励并说服：公司是怎么说服你购买他们产品的？他们肯定展示了价值和好处，但不仅如此，他们还做了漂亮的包装，使其尽可能地容易消化

(1) 原型：带界面的原型非常直观，会很吸引人。有很多创建软件原型的工具，如果你喜欢SAP的话可以事实build.me ，使用它可以轻松快速地创建漂亮的UI5应用。

(2) 视频:  除了无聊的PPT之外，用一个视频可以更好地展示你的想法。但是请不要过度营销，从长期看，内容为王，如果你满嘴跑火车，损伤的是你的声誉。

捍卫你的想法并且坚持不懈：如果你真的对自己的想法深信不疑，你应该捍卫它，为之战斗，这是非常必要的，因为具备长期目标的架构决策是不容易被人接受的：开发人员不喜欢它因为开发起来太难， 经理不喜欢它因为短期来看代价太高。所以坚持不懈地去说服是你的本职工作。

找到同盟军：独自去建立并且执行你的想法几乎是不可能的，你需要盟友的支持来说服别人。这时候需要使用你的社交网络，如果你还没有的话，马上去建吧！

你可以先去和那些具备开放心态的同事去谈你的想法， 如果他们喜欢（或者部分喜欢），当别人问起的时候，他们很有可能会支持你：X的想法很有趣。  如果他们不喜欢你的想法，问问为什么，你是不是漏掉了什么东西？你的故事不够吸引人？

下一步就是找到具备决策权力的盟友，请求他进行一个开放的讨论，如果你害怕这种讨论，你需要反思一下，是不是应该离开舒适区了。

重复它，相信它：研究显示重复的展示一个观点会使人们相信这是一个普遍的观点，即使该观点仅仅来自一个人。如果你经常发过某个消息，更容易说服别人。但是要当心：应该明智地使用这种策略，因为它可能适得其反。

据统计，99%的数据大咖都关注了这个公众号

👇

更多精彩文章：

1、

2、

3、

！

5、