1软件架构的角色
软件架构的角色范围：架构驱动力，设计软件，技术风险，架构演化，编码代码，质量保证。
这里展开讲一下：
架构驱动力：首先要理解业务目标然后就是架构驱动力，包括需求，环境限制等，有点像顶层选型
软件设计：创造软件的整体结构，根据实际情况限制进行技术选型
技术风险：如何证明技术是按照预期的方式工作？这是风险管理的范围了，新的东西复杂度高功能多风险高，旧的东西复杂度低功能少风险低。这一步要主动发现，减轻和承担高优先级的技术风险。
架构演化：随着时间的推移和需求的变化，架构是需要调整的，演化的。没有万年不变的架构
编写代码：随着架构的落地，从抽象到实体的理解架构
质量保证：保证一条基线，维护基本原则。如：编码标准，设计原则，通用工具等。
这里说了这么多职责实际上看起来好像一个普通开发者也参与了很多，感觉自己也是架构师。实际上只是执行/参与了很多，注意执行和制定/设计还是差很多的，有得人很多年都跨越不了，需要一些经验，一些思考，一些沉淀。比如质量保证，为了维护团队的代码质量需要代码评审还有编码规范设计原则等，实际大多数人都是执行者。还比如架构演化，当我们遇到框架上的问题的时候很多时候都只是去使用架构给你的勾子解决问题，那实际上是架构设计的很强，而不是使用者/执行者很强。
架构师因该是一个角色而非一个职级，应该你所处的工作内容越来越占据架构师角色应该做的事情，那你就是架构师，而非先提升你到架构师的职级，你却并不知道什么是架构师。
这是很重要的，想清楚这个你就不会问架构师应该做什么了。
2软件架构师应该编码吗
需要编码，应该做一些核心的编码工作，构建原型，框架，基础等。但是也要跳出编码履行自己作为架构师对团队承担的角色职责。适度
从这一点上看高级/核心应用程序开发者和架构师的角色范围有很多都是重叠的。只是架构师更多的需要对团队负责，所站的角度要稍微高一点
3软件架构师应该是建造大师
架构师需要和团队一起工作，从学徒到大师，是一个逐渐积累的过程，每个软件开发团队都需要他们自己的建造大师
4从开发者到架构师
开发者到架构师之间是模糊的界限，很多软件开发者已经承担了部分架构师的责任，不论他们的头衔是什么。
给一个软件架构出力和为之负责是有很大的差异，那就是构成软件架构角色所需的，跨越不同领域融会贯通的技能，知识，经验。跨越界限是我们的责任，作为个人我们要清楚自己的经验水平，以及为了提升它我们需要关注什么
5拓展T
T指的是技术，作为优秀的架构师需要去深入技术细节。
知识面宽，深入细节还要拓展水平知识面。才能有所选择
6软技能
领导力（创造共同愿景），沟通（受众），影响力，信心（信心不代表傲慢），合作，指导，辅导，动力（保持愉悦），润滑剂，政治（远离），责任感（任何问题都是架构师的锅），授权（授权是授予任务，授予的可不是责任）
7软件架构不是接力运动
除了真正的自组织团队（开源软件那样的，大部分都做不到，商业软件的愿景变化可比非功能需求的开源框架变化快的多），大多数团队还是需要人负责大局，负责整个项目的生命周期，而不是设计完了跑了，持续的调整，完善才是应有的状态
8软件架构要引入控制吗
需要根据团队水平平衡，完全不控制就是放任，过度控制可能会适得其反。（控制的意思是引入一定的约束，比如编码规范，统一orm框架，包/变量命名等）。
实际上工作中的所引入的控制还是很多的，比如阿里巴巴Java开发手册。。。我觉得语法的支持都是有它的价值的，没有绝对的正确，我们引入规范只是为了更好的适应团队开发。
9小心鸿沟
开发者与架构师是紧密相关的
10未来的软件架构师在哪里
就是普通的开发者，架构师指导开发者提升，开发者帮助架构师完成细节实现。
11每个人都是架构师
能够在架构层次和代码细节之间切换的架构师才是真正的架构师。
这里强调了自组织团队，我觉得开源软件都是自组织团队，他们每个人都了解整体架构，也了解要实现的细节，否则很难去理解开源软件代码。这么看有精力更应该为开源社区贡献力量。
12软件架构咨询师
领域知识是需要巨大的工作时间来了解的，大部分人咨询师都会面对不同的领域，需要敏锐的分析能力来理解业务领域的关键部分！而不陷入分析瘫痪的恶性循环。架构的角色意味着技术领导力，如果只有责任没有权利那就需要软技能帮助了。。
总结：本章介绍了软件架构角色所需的基本能力，包含技术能力，软技能等，同时也对架构角色做了一些实际的约束，比如编码，指导/培养架构师等。也阐述了架构师和开发者的关系，给架构师做了一些具象的定义角色范围，也让我们不再对架构师感觉神秘。
网友评论