架构师修炼之道--读书笔记
【笔者补充：软件架构师的定义】：软件架构师实际上就是软件项目的总体设计师，是软件组织新产品的开发与集成、新技术体系的构建者 —— 百度百科
六个方面的工作职责：
1）. 从工程角度定义问题：架构设计是一门以人为本的学科，架构师要与产品经理、项目经理一起共同定义满足所有利益相关方预期的项目的需求和目标。其中，产品经理关注功能需求、架构师关注质量属性（非功能需求，后续统一称为质量属性）和影响架构设计的约束和特性。
2）. 分解系统，分配职责：架构师根据功能需求、质量属性、设计约束及其他需求策略，对软件系统进行分解。分解后的系统以承担不同功能或服务的组件、模块的形式出现，分配给不同的人或团队开发，使得软件具备更高的可靠性、可用性、可伸缩性。
除了前面的意义外，分解后的小模块更容易进行架构设计推演、测试、设计。
【笔者补充：任务分解意义】：可以根据软件的不同特性，如跟硬件强相关的、跟用户应用场景强相关的软件等，进行合理的模块划分和对应的组织划分，进行软硬分离、软硬协同、接口抽象等设计，尽可能做到软件的并行开发和测试，缩短研发周期。
3）. 关注大局：影响软件系统的因素有人员、过程、业务需求及其它技术和非技术因素 ，因此，架构师要想保证软件架构设计的合理性，就要从全局角度出发考虑整体系统，而不能只着眼于局部细节的设计。
软件设计是一个不断 ” 挣扎 “ 的过程，在预期目标和可接受的目标之间寻找平衡，这就要架构师从全局出发，深思熟虑的做出取舍。
【笔者补充：架构师也要分段位】：主导和参与软件架构设计的所有架构人员原则上都应该能够从整体上理解和把握软件系统架构的设计思路。但是对不同经验和能力的架构师的要求应该有区分：首席/系统架构师，需要满足上述要求；模块/子系统的架构师只要关注本模块/子系统的背景环境，熟悉自身在整体架构中的位置、作用即可；初窥门径的架构师，主要是参与、学习、消化架构设计的思想、方法论、工具和技巧为主。
4）. 在质量属性之间做出取舍：软件架构的设计需要不断进行取舍，架构师经常要找出方案与各利益相关方协商如何进行合理的取舍。如为了实现99.99%的可用性，需要引入冗余，通过双倍硬件的配置来实现，这就是典型的用高成本换取高可用性。
【笔者补充：常见取舍场景】：1）用空间换时间，如Android从Dalvik虚拟机变更为ART虚拟机，前者是APP运行时才使用JIT（Just In Time）技术将代码转译为机器语言执行，影响APP的运行速度；后者采用AOT（Ahead Of Time）技术，在APP安装的时候就转译成机器语言，运行时直接加载运行，明显提升APP的运行速度。但后者因为提前转译，所以安装时，需要消耗更大的ROM来存储代码。其它的如：内存数据库、程序的预加载技术、各类池化（线程池、对象池、资源池等）技术、芯片中的多级Cache以及内置SRAM等。2）以时间换空间，如操作系统中的虚拟存储技术。3）以高成本换高可用性：一般都是引入了额外的硬件冗余，如自动驾驶功能安全技术中涉及的Lock-step（锁步核）技术、电源备份技术、车身控制信号冗余技术；云平台的双机热备技术和zookper的去中心化技术等。
5）. 管理技术债务：所有软件都有技术债务，它是当前软件系统设计和你想要的设计之间的一条鸿沟。技术债务的多少是通过填平鸿沟所需的代价来衡量的。
架构师需要进行模块划分和协调工作，并将业务需求和技术决策通盘考虑，只有这样，才能游刃有余地管理技术债务。
出色的软件团队会有意引入技术债务来实现更快的交付，后续再逐步进行偿还，从而持续的创造价值。
【笔者补充：技术债务定义】：我们有意或无意地做了错误的或不理想的技术决策所累计的债务，常见的债务源有代码债务、设计和架构债务、测试债务和文档债务等，常见的技术债务类型：
战略债务：在知情情况下，为了战略利益（如：如首次市场发行）而产生、并长期存在
战术债务：在知情情况下，为了快速收益而产生，通常适用于短期
疏忽债务：通常是在不知情的情况下缺乏知识或意识而产生
增量债务：定期不慎产生的债务导致增量债务
6）. 提升团队的架构能力：架构师是团队的导师和顾问，有责任向团队分享知识，让他们成功地开发出软件。把架构设计当做一项社交活动，让团队成员都参与到设计中来，从而有效提升团队技能。
【笔者补充：敏捷的味道】这里已经开始强调个体和互动的作用了，与敏捷宣言的第一条：“ 个体和互动高于流程和工具 ” 相契合。作者全书虽然没有提及敏捷，但是敏捷思想却贯穿始终。
————————————————
版权声明：本文为CSDN博主「金陵猿客」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/harry_helei/article/details/119780656
