这是很多朋友问我的问题。我最近看到了KaiNiklas写的一篇关于建筑师的文章。其中的见解引起了我强烈的共鸣，尤其是后面的非技术部分。翻译一下（略删）分享给大家。提前拿给一个同学看，他说：做架构师太难了，必须精通技术、沟通、平衡、营销……我还是努力做个技术达人吧！扪心自问，我的架构师在很多方面还远远不够，继续学习！如果你未来的职业目标是成为一名架构师，强烈建议仔细阅读并收藏。01什么是软件架构师在深入细节之前，我们需要知道什么是软件架构和架构师：软件架构师是软件专家，可以做出高层设计决策并指定技术标准，包括编码标准，工具和平台-维基百科软件架构是组织系统的基本方式，由其组件、组件之间的关系以及组件与其环境之间的关系表示。还包括管理系统设计和演化的原则。--HandbookofSoftwareArchitecture02架构的层次架构可以做不同的抽象层次，不同的层次需要不同的技能，分类标准有很多，我最喜欢的是这三个层次：ApplicationLevel（应用层）：架构的最低层次，专注于单个应用，有非常具体的设计，沟通通常仅限于开发团队级设计，但大多数是需要在多个开发团队之间进行交流的特定设计。企业级（EnterpriseLevel）：最高级别的架构，专注于多种解决方案。这个层次的设计比较抽象，需要解决方案架构师和应用架构师去细化。沟通跨越整个企业组织。有时，架构师被视为不同利益相关者之间的粘合剂，例如：水平方向：在业务人员和开发人员之间架起一座桥梁垂直方向：在开发人员和管理者之间架起一座桥梁技术领域：集成不同的技术和应用程序。03软件架构师的日常活动为了了解软件架构师需要哪些技能，我们不得不看一下架构师的日常活动，确定开发平台和技术，确定开发标准和规范：编码标准、工具、审查流程、测试方法等。根据需求，设计系统并做出架构设计决策Documentthearchitecturaldesignanddecisions,与teamcommunication,turnthehigh-leveldesignintolow-leveldesigninspection,reviewthearchitecturaldesignandcode,例如检查确定的模式和代码标准是否正确实施与其他架构师协作，利益相关者引导开发人员注意：架构设计是一个持续的活动，因此这些活动将被反复进行。软件架构师需要的重要技能根据我的经验、阅读的书籍和参与的讨论，我可以列出每个架构师必须具备的10项技能：设计、决策制定、简化、编码、文档、沟通、估算、平衡,咨询,市场营销让我们逐一进行，对于每项技能，我将列出我的一些见解和您应该采取的行动，以在该技能领域继续提高。04设计什么才是好的设计？这可能是最重要和最具挑战性的问题，所以让我们从理论开始。理解基本的设计模式：为了开发一个可维护的系统，模式绝对是架构师最重要的工具之一。使用模式，您可以重用设计来解决常见问题。GangofFour的《设计模式：可复用的面向对象软件基础》是每个开发人员的必读书籍。尽管已经过去了20年，模式仍然是软件架构的基本单元。比如书中描述的MVC模式在很多领域都有应用，也是MVVM等很多新模式的基础。深入挖掘模式和反模式：了解基本的“四人帮”模式后，需要将知识扩展到更多的软件设计模式，或者根据自己的兴趣深入研究，比如Java并发模式。在应用集成领域，我最喜欢的是《企业集成模式》，这本书适用于各种领域，只要两个应用需要交换数据，无论是非常古老的基于文件的交换还是现代的微服务架构你可以参考这本书。了解软件质量是如何衡量的：我们希望我们的系统是可维护的、可靠的、安全的、可测试的、可扩展的、可用的……为了实现这些目标，必须将系统架构设计好。大家可以参考一下：理论很重要，实践更重要，否则你就会成为象牙塔的建筑师。不断尝试和理解不同的技术栈：我认为这是成为一名架构师非常重要的事情。你很难从抽象的PPT中学到真实的东西。您必须尝试不同的新技术堆栈并亲自体验。它带来的好处和“痛苦”。另外，你也可以尝试不属于你领域的技术。例如，如果你非常擅长SAPR/3，那么你也应该尝试JavaScript。分析理解适用好的模式：看你现在使用的框架，比如Angular，有很多模式你可以研究并付诸实践，比如observers。查看它在框架中的使用方式和原因。如果您愿意付出更多努力，请深入研究源代码以了解其实现方式。保持好奇心，参与一些公司外的社区活动：比如Java用户组会讨论很多话题，从最底层的编码到最高层的架构。我喜欢这种活动，因为它让我在工作之外思考，并加强你的个人社交网络。05决策架构师需要能够做出架构决策，引导项目和组织朝着正确的方向发展。确定优先级：有些决策非常重要，如果不及早识别它们，就会有一些变通办法，以后很难消除，成为维护的噩梦。更糟糕的是，程序员需要停止工作，等待你做出决定。为避免这种情况，必须确定这些决策的优先级，我建议看一下敏捷软件开发中非常流行的加权最短作业优先(WSJF)模型。了解你的能力：不要在你的能力之外做出决定，这是非常关键的，如果你不坚持到底，可能会毁了你的架构师工作。因此，请务必向同事阐明您的职责和角色。作为底层架构师，可以对高层架构提出建议，但不要自己做决定。我建议定期与您的同行一起审查那些关键的架构决策。评估多个选项：在做出决定时，列出多个选项。在我参与的大多数决策中，有不止一种可能的（好的）选择。只是提供一个选项表明你还没有完成你的工作，无法做出决定。根据可衡量的事实（例如，许可费、成熟度）而不是个人感受来比较选项，以便做出决定。06简明扼要，牢记奥卡姆剃刀解决问题的原则：非必要勿增实体。如果你对一个问题有太多的假设，你很可能会走错方向，导致不必要的复杂解决方案。请务必完善您的假设以生成良好的解决方案。（可见架构工作也是一门艺术）“摇”你的架构设计：为了让架构设计更简单，你可以从多个角度审视解决方案，不仅要自上而下，还要自下而上up的方式再说一遍，如果有数据流或者业务流程，先从左往右看，再从右往左看。经常问自己：“建筑在理想环境中会是什么样子？”“大公司会做什么？”这些问题促使您减少假设。退一步说：往往冗长而密集的讨论往往会导致一个高度复杂的设计，你一定不能把它当作最终结果，退一步从抽象的层面看大局，这个设计还有意义吗？有时停止讨论并在第二天继续讨论会有所帮助，至少我的大脑需要时间来处理信息并提出更好、更优雅、更简单的解决方案。分而治之：把一个大问题分成小块，一个一个解决，看小块的解是否匹配。重构并不邪恶：如果找不到更好的设计，可以从复杂的解决方案开始。如果后面遇到问题，需要回头再想想，重构不是邪恶的，但是在你开始重构之前，确保：（1）足够的自动化测试用例，保证系统的功能不被破坏（2）获得利益相关者的支持。07代码即使你是企业级架构师，也就是抽象层次最高的架构师，你还是要知道程序员在日常工作中是干什么的。否则你会遇到两个问题：(1)开发人员不会接受你的想法、花言巧语(2)你不会理解开发人员面临的真正挑战和真正需求。做一个sideproject：目的是尝试新技术和工具，了解当前和未来的发展情况。看一些教程确实不错，但只是“书本”知识。只有自己去尝试和体验，才能真正体会到：为什么好？为什么不好？你使用一项技术的时间越长，你的经验就越多，它就越能帮助你做出正确的决定。找到合适的技术去尝试：你不能什么都尝试，我最近发现了ThoughtWorksTechnologyRadar，他们把技术、工具、平台、语言和框架分为四类：采用、尝试、评估和保留。Adoption是指“适合企业采用”。Experiment是指“企业可以在风险可控的项目中尝试”Evaluation是指“正在研究是否对企业有影响”Suspense是指“谨慎实施”有了这个分类，你就可以找到你想尝试的新技术。08DocumentCleanCode：简洁大方的代码是最好的文档，架构师必须能够区分什么是好代码，什么是坏代码。好代码和坏代码有一本好书：尽可能自动生成文档：对于一些比较详细的文档，由于系统变化快，很难及时更新，所以尽量自动生成文档：如果你是ModelDriven可以从定义文件自动生成文档，SWagger和RAML是很好的起点。多即是多，少即是少：无论什么样的文件，一次只关注一件事，只包含这件事情必要的信息。额外的信息应该保留在附录中，因为很多文本很难阅读和理解。好好看看你的文档，问问自己：“为了理解整个事情，里面的所有信息都是吗？”，“哪些信息是必要的，哪些可以忽略？”09Communication根据我的观察，这是最被低估的技能，如果你擅长设计，但不会与他人沟通，你的想法影响不大，很可能会失败。演讲：向小型或大型团体发表演讲是架构师的常见工作。如果一开始你觉得不舒服，可以从你最好的朋友开始，逐渐扩大到更多人。这个东西只能边做边学是一个需要时间的过程，需要走出你的舒适区，所以要有耐心。找到合适的沟通层次：不同的人看待事物的方式不同，所以你需要在他们的层次上与他们沟通。例如，开发人员对技术细节感兴趣，而管理人员则更倾向于了解哪种方案更具成本效益。所以在沟通之前，你要看你要沟通的是不是在正确的层次上，包括抽象、内容、目标、动机等。经常沟通：如果没人知道，再好的架构也没有意义，经常沟通你的架构设计及其背后的想法，定期在每个组织级别（小组、部门、公司）进行沟通，安排与开发人员、架构师、经理的会议，并展示您的架构想法。透明：定期沟通只能部分缓解缺乏透明度的问题，你还必须确保决策背后的原因是透明的，特别是对于那些没有参与决策过程的人来说，他们很难理解为什么和为什么。时刻准备好发表演讲：总会有人向架构师提问，而你想快速给出正确答案，那么你应该怎么做呢？可以把最重要的PPT挑出来，放在一起，随时展示，避免在一堆资料中东找西找，浪费太多时间。10估算和估算了解基本的项目管理原则：作为架构师或首席开发人员，您经常会被要求估算您的设计：需要多长时间才能完成？需要多少人？需要什么技能？首先，您可以提供粗略的估计：天数、月数。请记住，预估时间不仅仅是编码和实现，还需要分析、测试和错误修正。所以你需要知道软件开发过程中的各个步骤。获得更好估计的一种方法是根据历史数据进行预测。如果没有历史数据，可以试试COCOMO方法。如果你在做敏捷项目，这本书很有帮助：Assessingthearchitecture：作为架构师，你应该能够架构设计在当前和未来上下文中的适应性，这并不容易，你可以准备一套“质疑”架构设计的问题，例如：（1）设计实践：架构遵循什么模式？它是否被正确使用？是否有明确的设计和关注点分离？(2)开发实践：是否制定了代码规范？被跟踪了吗？代码有版本控制吗？(3)质量保证：自动化测试的覆盖范围是多少？静态代码分析是否到位？同行评审到位了吗？(4)安全性：架构设计中有哪些安全概念？内置安全性如何？？测试和自动化安全分析是否到位？是否经常使用？11平衡质量是有代价的：我之前谈到了系统质量和非功能需求。如果架构设计过度，会增加开销，降低开发速度。您需要平衡架构设计和功能需求，应避免过度设计。解决相互冲突的目标：一个典型的例子是短期目标与长期目标。项目往往建立在最简单的解决方案之上，而架构师则有长远的眼光。通常，简单的解决方案不适合长期目标并且有被丢弃的风险（沉没成本）。为避免走错方向，应注意两点：(1)开发人员和业务人员都需要了解长期愿景及其好处。(2)负责预算的经理也需要参与并了解财务影响。冲突管理：由于团队背景不同，难免会发生冲突。为了找到一个双方都能接受和平衡的解决方案，架构师需要充当胶水来解决这些冲突。关于沟通的理论，我是从SchulzevonThun的四耳模型开始的：12咨询指导有一个愿景：无论你在什么样的项目中，无论是传统的瀑布模型还是敏捷模型，你都必须需要有一个愿景，你想要实现的短期和长期目标，并将其清楚地传达给团队成员。由于不可能一下子解决所有问题，我通常倾向于构建成熟度模型，让团队清楚地了解我们所处的位置。开发有很多方面，必须使用不同的成熟度模型，比如开发实践成熟度模型和持续交付成熟度模型。这些模型的每个级别都有明确的定义，团队可以轻松衡量他们所处的位置。对于持续交付，我个人更喜欢这种建立社区的模式：比如JavaScript程序员和架构师每月组织讨论一次。主题可以是如何解决过去和现在的技术挑战、新技术和方法。架构师可以分享和讨论他们的愿景，程序员可以分享他们的经验，这样的会议可以帮助建立一个更强大的团队，这对企业和个人都非常有价值。开诚布公地讨论：误解和歧义的根源是缺乏沟通，所以可以安排一个固定的时间段，比如每周30分钟，与同行交流一些热点话题，什么都讨论，不用刻意安排议程供讨论。小事当场解决，复杂事后安排跟进。13营销你的想法很好，也跟大家沟通的很好，但是没人愿意去做，可能是营销技巧欠缺。激励和说服：公司如何说服您购买他们的产品？他们肯定展示了价值和好处，但除此之外，他们还做了一个漂亮的包装，使其尽可能易于消化(1)原型：带有界面的原型非常直观，并且会很有吸引力。创建软件原型的工具有很多，如果你喜欢SAP，可以查看build.me，使用它可以轻松快速地创建漂亮的UI5应用程序。(2)视频：除了枯燥的PPT，视频更能展现你的想法。但请不要过度营销，从长远来看，内容为王，如果你满嘴跑火车，会损害你的声誉。捍卫你的想法并坚持不懈：如果你真的相信你的想法，你应该捍卫它并为之奋斗。这是非常必要的，因为具有长期目标的架构决策不容易被接受：开发人员不喜欢它是因为它太难开发，管理者不喜欢它是因为它在短期内太昂贵。所以坚持说服是你的工作。寻找盟友：??单独建立和执行您的想法几乎是不可能的，您需要盟友的支持才能说服他人。现在是使用您的社交网络的时候了，如果您没有，现在就开始吧！你可以先和思想开放的同事谈谈你的想法。如果他们喜欢（或部分喜欢），当别人问起时，他们很可能会支持你：X的想法很有趣。如果他们不喜欢你的想法，问问为什么，你错过了什么吗？你的故事不够吸引人？下一步就是找一个有决策权的盟友，请他开诚布公地讨论。如果你害怕这种讨论，你需要反思一下是否应该离开你的舒适区。重复它，相信它：研究表明，反复展示一个想法会让人们相信这是一个普遍的观点，即使它来自一个人。如果您经常发送特定信息，就更容易说服人们。但要注意：这种策略应该谨慎使用，因为它可能适得其反。
