架构师劝退指南
“我怎么才能成为一个软件架构师？”
这是很多小伙伴问我的一个问题，最近看到Kai Niklas讲架构师的一篇文章，其中的真知灼见引起了我的强烈共鸣，尤其是后面的非技术部分。翻译过来（略有删减），分享给大家。英文文章请点击”阅读原文“。
我事先给一位同学看了一下，他说：当个架构师太难了吧，又要精通技术，还得会沟通，平衡，营销..... 我还是争取做个技术专家吧！
扪心自问，我这个架构师在很多方面也做得远远不够，继续学习吧！如果你的未来职业目标是架构师，强烈建议仔细阅读并收藏。
在我们一头扎入细节之前，我们先得知道软件架构和架构师到底是什么：
软件架构师是一个软件专家，他可以做出高层的设计决定，规定技术标准，包括编码标准，工具和平台 -- Wikipedia
软件架构是一个系统最基本的组织方式，由其组件，组件之间的关系，组件和环境的关系表达出来。也包括决定设计和系统演化的原则。--Handbook of Software Architecture
架构可以在不同的抽象级别上完成， 不同的级别要求不同技能，有很多分类标准，我最喜欢的是这三个级别：
Application Level （应用级别）：架构的最低级别，专注于单个应用，有非常具体的设计，沟通通常局限在开发团队
Solution Level （解决方案级别） ：架构的中间层，需要关注几个应用来实现一个商业的需求，有部分高层的设计，但大多数还是具体的设计，沟通需要跨越多个开发团队。
Enterprise Level (企业级别)：架构的最高级， 关注多个解决方案，这一层的设计比较抽象，需要解决方案架构师和应用架构师去细化。沟通跨越整个企业组织。
有时候，架构师被看作不同利益相关者之间的粘合剂，比如：
水平方向：在业务人员和开发人员建立沟通的桥梁
垂直方向：在开发人员和经理之间建立沟通桥梁
技术领域：集成不同的技术和应用。
为了理解软件架构师需要哪些技能，我们得先来看看架构师的日常活动
确定开发的平台和技术
确定开发标准和规范：编码标准，工具，评审流程，测试方法等
根据需求，设计系统并且做出架构设计决定
把架构设计和决定文档化，和团队沟通
把高层的设计变成底层设计
检查、评审架构设计和代码，比如看看确定的模式和代码标准是否正确施行
和其他架构师、利益相关者协作
指导开发人员
注: 架构设计是一个持续的活动，所以这些活动会一遍一遍地完成。
软件架构师所需的重要技能
根据我的经验，阅读的书籍，以及参与的讨论，我可以列出这10个技能，每个架构师都必须具备：
设计, 决策，简化, 编码, 文档, 沟通, 估算, 平衡, 咨询, 营销
我们一个个来说，对每个技能我都会列出一些我的见解，你应该采取的行动，以便在这个技能领域持续提高。
是什么造就了好的设计？这可能是最重要，并且最具挑战性的问题，让我们先从理论开始。
理解基本的设计模式：为了开发一个可维护的系统，模式绝对是架构师最重要的工具之一，使用模式，你可以复用设计来决定那些通用的问题。“四人帮”的《设计模式：可复用的面向对象软件基础》是每个开发人员的必读书籍。尽管过去20多年了，模式依然是软件架构的基本单元。
比如书中描述的MVC模式被应用在很多领域，也是很多新模式如MVVM的基础。
深入挖掘模式和反模式：理解了基本的“四人帮”模式以后，你需要把你知识扩展到更多的软件设计模式中，或者根据自己的兴趣，深入研究，例如Java并发模式。
在应用程序的集成领域， 我最喜欢的是《企业集成模式》，这本书适用于各种领域，只要两个应用需要交换数据，不管是很古老的基于文件的交换还是现代的微服务架构，都可以参考本书。
了解软件质量的度量方式：我们希望我们的系统是可以维护的、可靠的、安全的、可以测试的、可以扩展的、可用的...... 为了达成这些目标，必须要把系统架构设计好。你可以参考这个：
理论很重要，实践更加重要，否则你就会变成一个象牙塔架构师。
不断尝试和理解不同的技术栈 ： 我认为这是成为架构师非常重要的事情， 你很难从抽象的PPT中学到真东西，你得尝试不同的、新的技术栈，亲自感受一下它带来的好处和引发的“疼痛”。另外也可以尝试不属于你所在领域的技术，例如你对SAP R/3 非常擅长，那你应该也试试JavaScript。
分析、理解那些应用良好的模式：看看你当前使用的框架，例如Angular， 你可以研究很多以及付诸实践的模式，如观察者。看看它是怎么在框架中使用的，为什么要这么使用。如果你愿意投入更多的精力，那就深入源代码看看它是如何实现的。
保持好奇心，参加一些公司之外的社团活动：比如Java User Group会讨论很多主题，从最底层的编码到高层的架构，我很喜欢这样的活动，因为它会让我跳出工作来思考，并且加强个人社交网络。
架构师需要能够做出架构决定，引导项目和组织走在正确的方向。
确定优先级：有些决策非常关键，如果没有在早期确定下来，就会出现一些变通的临时措施，导致后续难以移除，变成维护的噩梦。更差的情况是，程序员需要停止工作，等你做出决策。
为了避免这种情况，必须要把这些决策按优先级排序，我建议看一看敏捷软件开发中非常流行的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的想法很有趣。 如果他们不喜欢你的想法，问问为什么，你是不是漏掉了什么东西？你的故事不够吸引人？
下一步就是找到具备决策权力的盟友，请求他进行一个开放的讨论，如果你害怕这种讨论，你需要反思一下，是不是应该离开舒适区了。
重复它，相信它：研究显示重复的展示一个观点会使人们相信这是一个普遍的观点，即使该观点仅仅来自一个人。如果你经常发过某个消息，更容易说服别人。但是要当心：应该明智地使用这种策略，因为它可能适得其反。
Java每次遇难，总会有大神拯救看到JavaScript的原型，小王子晕倒了
你们这些偷代码的程序员！程序员的宿命芯片战争70年，真正的王者即将现身！干掉软件开发的最大怪兽：狼人！宇宙第一IDE到底是谁？HTTP Server ：一个差生的逆袭如何降低程序员的工资？程序员，你得选准跑路的时间！两年，我学会了所有的编程语言！Javascript: 一个屌丝的逆袭我是一个线程TCP/IP之大明邮差一个故事讲完HttpsCPU 阿甘