《架构师修炼之道》读书笔记之一：如何成为架构师

1-001 软件架构师在团队中的角色描述        

        架构师在团队中的角色很独特，虽然做的更多的是软件架构的设计，但既要有研发经理的编码、部署等技术能力，也要有产品经理的业务能力，项目经理的交付能力，其在团队中的核心地位如下图所示：

 1-002 软件架构师的定义和工作职责

    【笔者补充：软件架构师的定义】：软件架构师实际上就是软件项目的总体设计师，是软件组织新产品的开发与集成、新技术体系的构建者    —— 百度百科

六个方面的工作职责：

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）. 管理技术债务：所有软件都有技术债务，它是当前软件系统设计和你想要的设计之间的一条鸿沟。技术债务的多少是通过填平鸿沟所需的代价来衡量的。

       架构师需要进行模块划分和协调工作，并将业务需求和技术决策通盘考虑，只有这样，才能游刃有余地管理技术债务。

       出色的软件团队会有意引入技术债务来实现更快的交付，后续再逐步进行偿还，从而持续的创造价值。

   【笔者补充：技术债务定义】：我们有意或无意地做了错误的或不理想的技术决策所累计的债务，常见的债务源有代码债务、设计和架构债务、测试债务和文档债务等，常见的技术债务类型：

1. 战略债务：在知情情况下，为了战略利益（如：如首次市场发行）而产生、并长期存在
2. 战术债务：在知情情况下，为了快速收益而产生，通常适用于短期
3. 疏忽债务：通常是在不知情的情况下缺乏知识或意识而产生
4. 增量债务：定期不慎产生的债务导致增量债务

6）. 提升团队的架构能力：架构师是团队的导师和顾问，有责任向团队分享知识，让他们成功地开发出软件。把架构设计当做一项社交活动，让团队成员都参与到设计中来，从而有效提升团队技能。

  【笔者补充：敏捷的味道】这里已经开始强调个体和互动的作用了，与敏捷宣言的第一条：“ 个体和互动高于流程和工具 ” 相契合。作者全书虽然没有提及敏捷，但是敏捷思想却贯穿始终。

 1-003 什么是软件架构

 【笔者补充：软件架构的定义】：是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件体系结构是构建计算机软件实践的基础。—— 百度百科

    软件架构是关于如何组织软件的一系列重大设计决策的集合，旨在实现期望的质量属性和其它软件特性。可使用《Software Architecture in Practise，软件架构实践》中定义的模块（Module）、组件连接器（Component & Connector，C&C）、分配（Allocation）三种元素来构建软件架构，将相同类型的元素和关系连接在一起，就形成了架构。三种类型的元素关系如下：

        其中：模块存在于设计阶段、组件连接器（C&C）存在于软件运行阶段、分配展示了模块和组件连接器两元素之间，以及这些元素和现实的物理元素之间的协同与响应关系。

        软件架构的设计需要推演质量属性（非功能需求）和其它系统特性，选择架构的结构就是选择你想在软件系统中提升的质量属性。质量属性让软件独一无二。

 1-004 成为团队的架构师

         团队中架构师的角色并非总是明确的，有的团队有，有的团队则是由成员分担架构师的职责。

        程序员向架构师转变，至少要参与过三到五个系统的开发，且承担的技术职责应不断增加。【笔者补充：技术职责增长的必要性】：只有不断承担更多的技术职责，才能避免技术职责的重复性和单一性，才能有助于提升程序员的全方位的技术能力和大局观，为成长为架构师奠定基础。

        程序员向架构师转变，要有耐心，时刻做好准备，把握一切设计架构的机会，尤其是设计复杂系统的机会。同时，与同事合作，让每个人都有机会提高水平。

 1-005 软件架构是开发出色的软件的基础

从以下六个方面指引打造出色的软件：

1）软件架构将复杂的大问题分解为容易处理的小问题：解决现代软件系统庞大且复杂，有许多活动的部件问题。

2）软件架构告诉大家如何协同工作：软件开发既是技术，也是人际沟通的艺术。软件架构描述了整个系统如何组成有机的整体，掌握了软件架构就清楚了人们该如何合作开发软件。

3）软件架构为讨论复杂设计提供了基本词汇：软件架构为软件开发的沟通提供了基本概念和词汇，这样开发人员就可以把时间花在解决用户的实际问题上，而不必发明新的概念和词汇。

4）软件架构关注的不仅仅是功能：软件架构除了考虑功能需求，还要考虑成本、约束、进度、风险、团队的交付能力，以及最重要的质量属性（如可伸缩性、可用性、性能、可维护性等）。

5）软件架构让你避免犯重大错误：软件架构可以帮助发现那些今后可能会带来麻烦的问题和地方。

6）软件架构让软件更灵活：软件如水，架构如器。器可以是铁桶、塑料袋等各种形态，但都能盛水。没有架构，软件就像流淌的水一样无法控制。架构为软件提供了灵活多变的结构。