阿里巴巴 孤尽 软件工程危机与重构之道

2020-03-01 215浏览

  • 1.软件工程危机与重构之道 孤尽 阿里巴巴 高级技术专家
  • 2.
  • 3.个人简介 • 孤尽：独孤九剑，破尽天下武功 • Java开发手册、码出高效作者 • 企业智能事业部 - 全球服务创新 - IT研发负责人 • 历经淘宝大学、国际事业部、代码中心架构师 • 83行代码公益倡导者 • P3C开源项目发起人
  • 4.软件工程危机 重构的合理性 提纲 CONTENTS PAGE 重构之道 决定是否重构 重构之业务道 重构之数据道 重构之代码道 重构之设计道 阿里巴巴重构之路
  • 5.最浪费时间的事就是给年轻人讲经验，该走的弯路其实一米也少不了。 ——李嘉诚 今天的分享并非希望你们不走弯路，而是意识到在走弯路。 ——孤尽
  • 6.生活中的架构笑话
  • 7.什么是软件工程？ 程序（静态）= （算法 + 数据结构）的字符集 程序（动态）= （时间 + 空间）的计算流 软件：是计算机系统中与硬件相互储存的另一部分，在某种法律协议框架 下，包括程序、数据、文档及服务的完整集合。 工程：是与基础科学、数学、基础理论相关的某类实践应用，使自然界的 物质和能源的特性能够通过各种结构、机器、产品、系统和过程，是以最 短的时间、最少的人力、物力做出高效、可靠且对人类有用的东西。 软件工程：以尽可能少的时间和人力成本编写出以程序为核心服务人类某 种特定生产、生活、工作需求的工程化过程。
  • 8.软件工程有哪几大类，特点是什么？ 根据交付节奏上的区别，可以分成如下三种： 第一、原型式 特点：快速交付可用最小版本，认可后快速迭代继续优化。 第二、敏捷开发 特点：以分阶段，分批次，短迭代式地实现需求。强调信任，面对面，测试驱动。 第三、瀑布式 特点：非常完善的MRD / FRD / PRD，形成概要设计、详细设计、设计评审、编码等环节。
  • 9.软件工程危机的表现 1） 软件需求基本上很难满足 或软件生产进度严重失控 或软件交付的质量很差 2）软件的故障率很高 或软件的可维护性极差 3）文档缺失或严重滞后于软件功能 4）用户对软件定位越来越模糊
  • 10.软件工程危机的根源 需求 没有买卖，就没有杀害。同理，没有需求，就没有重构。需求是软件 发展的动力，也是重构的根源所在。如果未来不再有任何新增需求，那么 重构就没有任何必要。
  • 11.软件工程危机的主要因素 天不时，地不利，人不和 一、需求纵向的穿插（时间） 从需求、评审、编码、测试、构建、发布的链路上，需求随意的变更， 发布没有规范，在软件时间轴上的行为随意地穿插，甚至是践踏。 二、组件横向的耦合（空间） 组件之间不符合迪米特原则，放波逐流，导致牵一发动全身。 三、人员的能力缺陷（落地） 架构师是虚的职位，一个差劲的架构师，可以创造出烂系统，也短时 间可以毁掉一个好系统。软件是团队合作的作品，木桶装水取短板。
  • 12.如何治理软件工程危机 第一、合理的组织管理 组织 第二、清晰的软件发展战略 第三、规范的流程与代码规范 第四、优良的系统架构设计 设计 战略 第五、适时地重构 规范
  • 13.重构是合理存在的 一个作家，不是看他发表了多少文字，而要看他的废纸篓里扔掉了多少。 ——巴金 从代码的角度来说，好代码不是写出来的，而是改出来的。 一个稳定而庞大的系统不是架构出来的，而是重构出来的。 ——知忧 ——孤尽
  • 14.重构是合理的 重新架构既要解决过去的问题，也要解决现在的问题，还能适度解决 未来的问题，但是一味地解决未来的问题，会使系统的风险、成本剧烈上 升，所以系统架构是一种妥协。重构是合理的，因为： 第一、用户规模的扩大。 第二、固有用户的自我进化。 第三、商业竞争的残酷性。 第四、技术栈的更新迭代。 第五、研发团队的自身因素。
  • 15.用户规模的扩大 在系统功能完全不变的情况下，万级用户 与 百万级、千万级、十亿 级，架构复杂度也会指数级上升，带来的是分布式、高并发上的诉求。
  • 16.固有用户的自我进化 用户在系统使用过程中，会不断地得到硬件升级、外界输入、系统引 导下，会对系统有进一步超越当前系统当前能力的要求。
  • 17.商业竞争的残酷性 商业竞争需要进行软件系统符合市场需求和营利目标，部分核心功能 可能被动下线，被动迁移，核心模块可能需要重构。
  • 18.技术栈的更新迭代 技术栈是大江大河一样往前发展，逝者如斯夫，不舍昼夜，30年来的 软件发展潮流，多少技术框架已经消失，或者处于停更状态。技术栈的不 断更新，会带来重构的可能性。
  • 19.研发团队的自身因素 第一、人人都是产品经理，即人人都不是产品经理。 第二、开发工程师的代码能力。 第三、测试的失位。 第四、技术管理人员的行政指令。 第五、信息不对称。
  • 20.“虚”的架构师 架构是一种能力，并非是一个岗位。架构的东西没有绝对的对与错， 只有是否适合。架构师是在开发团队中，有系统把控力的大师。但是，近 年来，“架构师”被玩坏了： 第一、有些架构师只会画框，缺乏实际编程的能力。 第二、有些架构师只会分任务，缺乏系统解耦的能力。 第三、有些架构师只会催任务，缺乏风险判断的能力。 第四、有些架构师只会PPT，缺乏业务洞察的能力。
  • 21.重构什么时候是必要的？ 第一、投入产出比低 1）需求估时中，熟悉系统的时间比例超过30%。 2）业务模型剧烈的变化使原有的系统适配难度极大。 3）组织架构的变化已经不适合软件的继续开发。 第二、日常维护时间超过开发时间的50%。 第三、系统极不稳定，故障率高。 第四、可扩展性差，增加小功能就是伤筋动骨的回归测试。
  • 22.重构什么时候是必要的？ 所以，重构有四个维度的考量：需求实现率、稳定性、可维护性、可 扩展性。如果3个及以上，受到严重挑战，那么才需要进行重大重构。 稳定性 需求实现率 可扩展性 可维护性
  • 23.重构的时机选择 从时间成本、人力成本、机会成本三个角度来判断重构时机 重构时机 时间成本 人力成本 机会成本
  • 24.重构的深度思考 从艾森豪威尔矩阵分析（SWOT）重构时机 1. 2. 3. 当前系统的竞争力所在 当前系统的市场占有率 当前系统以当前状态还能工作多久 1. 2. 3. 当前系统的缺陷在哪里 当前系统的故障率 当前系统的用户反面声音 1. 2. 3. 4. 重构是否获得上级支持 重构的成本是否能够承受 市场是否有积极的信息 大环境政策是否有利 1. 2. 3. 重构的外部约束有哪些 竞品的挤压空间 关联系统是否同意一起重构
  • 25.重构就是软件作用力重新平衡的过程 运 营 PM 架 构 运 维 软件 （A) 客 户 重构 主 管 软件 （B) 财 务 法 务
  • 26.重构的分级 第一、小型重构【数周】。迭代式重构，穿插在新需求之中，小步快跑。 注意：重构节奏很重要，关注新老需求与重构的协调关系。 第二、中型重构【数月】。大部分模块会进行全新设计，新需求有所抑制。 注意：业务方的抱怨程度与系统稳定性 第三、大型重构【半年】。进行全新的系统架构设计和数据梳理、数据迁 移，必须进行完整的项目管理、风险控制 。 注意：必须明确独立目标，以及ROI。 第四、颠覆性重构【数年】。历史系统只是参考，大刀阔斧地来。 注意：必须有明确的战略支撑和ROI、数据的存留、系统的未来。
  • 27.重构时，分清楚需求类别
  • 28.如何进行重构？ 重构到什么程度，这是一个战略问题，必然有战有略。 1）重构到底解决什么问题，需要正确地定位问题。 2）区别对等历史债。 3）有取舍地来对待重构中新增加的业务需求。 4）审慎地对待重构过程中的业务、数据、代码、设计。 第一、业务道：取得业务相关方支持，重新梳理业务模型。 第二、数据道：历史数据慎重对待，新数据结构需要认真评审。 第三、代码道：处理原有面条代码，遵守规范，梳理好逻辑。 第四、设计道：全面复盘设计文档，重新设计。
  • 29.重构：业务道 第一、重新进行用户调研 1）用户对老系统的抱怨 2）用户对新系统的期待 3）用户的时间容忍度 4）用户的交互接受度 第二、业务方的共同参与。重构不是技术方的事情。 第三、对齐上级战略。 第四、重构一定是KPI，靠技术情怀肯定是不够的。
  • 30.重构：业务道 区分系统原有的业务模型和新系统的业务模型，分清楚既有的是哪些， 改进的有哪些，新增的有哪些。 通常改进的业务模型带来的系统杀伤力会比较大一些，因为软件有默 认有一个向前兼容法则。 流程中穿插着状态的变更，那么容易产生幂级上升的复杂度。
  • 31.重构：数据道 第一、数据表与业务模块的映射关系 第二、数据结构与数据约束 第三、数据的规模及存储方式 第四、数据的敏感性 第五、是否存在大数据场景应用 第六、数据的上游与下游
  • 32.重构：数据道 重构必然有数据。存在的数据就像一个雷场，广义地划分为： 第一、业务数据 第二、统计数据 第三、监控数据 第四、元数据
  • 33.重构：代码道之大局观 第一、谨慎换语言进行重构 第二、重新技术框架选型 第三、合理评估分布式的可行性 第四、代码符合设计七大原则 第五、代码符合新业务的设计要求 第六、引入严肃的CodeReview机制 第七、遵守代码规范。推荐《阿里巴巴Java开发手册》华山版
  • 34.重构：代码道之代码规范 第一、优雅地处理好各种异常 第二、重新处理分支判断处的逻辑 第三、尽量使用新的语法 第四、控制类与方法的行数 第五、DRY原则，消除重复代码 第六、删除过旧注释，重新注释
  • 35.代码道：异常处理 • • • • Where：哪里发生异常 What：异常是什么 Who：谁来处理异常 How：怎么处理异常
  • 36.代码道：if-else改写
  • 37.代码道：if-else改写卫语句
  • 38.重构为什么更需要设计？ 系统架构涉及三个域：技术域、业务域、涉众域的重新平衡。 业务域 功能域 技术域 问题域 涉众域
  • 39.重构：设计道 如果重构还不注意系统设计，那么就如同咸鱼。设计包括两个工作： 1）识别重构系统的难点。 2）表达重构系统的难点。
  • 40.如何识别系统难点？ 第一、系统的结合面上。 第二、性能瓶颈点上。 第三、高危安全点上。 第四、既有系统的痼疾上。 第五、系统的预留扩展点上。
  • 41.识别出来，一定能够表达出来吗？ 表达不出来系统难点的原因： 第一、基础知识体系的完备性。 第二、表达工具的生涩性。 第三、抽象能力的局限性。 第四、架构的前瞻性。 第五、业务的深度理解力。
  • 42.重构中的设计工具：UML 什么是UML？原来没有的图为什么要画？UML:Unified Model Language。核心关键词是Language，它是一种语言， 大家都能够懂的语言来表达计算机系统设计中的难点。 而Model指的是需要高度抽象软件系统，并且对软件设计按既定的某种模 式进行表达。
  • 43.重构中的设计工具：UML UML分为静态图和动态图。 静态图是从静止的视角看待系统，没有时间属性。比如、类图、部署图， 用例图等。 动态图是从系统运动的视角来看待，有时间属性。比如，活动图、时序图、 状态图等。
  • 44.为什么需要那么多图？ 横看成岭侧成峰，远近高低各不同。比如：中国是什么？谁能够描述中国？ 如果我是地质专家？ 如果我是气候专家？ 如果我是水利专家？
  • 45.类图 描述现实世界抽象模型对象的主要属性与行为，使系统的解耦与内聚性 有一个清晰的方向。
  • 46.用例图 从用户的角度描述系统的功能，表达用户与系统之间的交互。它从用 户的角度而不是开发者的角度来描述软件产品的需求，分析软件产品所需 的功能和行为。用例图主要的作用有三个： • 明确用户需求。 • 指导功能测试。 • 指导后续设计与演化
  • 47.状态图 表达系统在运行期内可能出现的任何状态，以及触发状态变化的任何 事件。注意状态之间的转换可能性，以及促使状态转换的条件是否具备。 状态图避免两种情况： • 黑洞状态。黑洞状态是只进不出的状态，除非是“最终状态”。 • 奇迹状态。奇迹状态是只出不进的状态，除非是“起始状态”。
  • 48.时序图 时序图是说明对象在纵深调用链路上的耦合关系，以及随着时间轴产 生的调用和返回操作。纵轴是时间轴。横轴代表在协作中各个独立的对象。
  • 49.活动图 流程图的加强版本。在原来流程处理的基础上，加入对象泳道、并发 操作，使对象之间的协作关系更加清晰。
  • 50.类的六大设计原则 重构系统是浴火重生过来的，所以需要更加重视设计质量，杜绝原有 的痼疾问题，准确识别和表达系统难点，在模块与类的设计中，需要更加 遵守设计七大原则： 第一、单一职责 第二、开闭原则 第三、里氏代换 第四、接口隔离原则 第五、依赖倒置原则 第六、组合复用原则 第七、迪米特原则
  • 51.重构时的迪米特法则 知道得多，死得越快。迪米特法则就是说一个模块应当对其他模块有 尽可能少的了解,不和陌生人说话。talk only to your immediate friends： 一个软件实体应当尽可能少的与其他实体发生相互作用。 模块之间符合迪米特法则，使模块之间独立性变强，利于模块的迁移 和模块的重构。
  • 52.重构与老系统之间如何同时工作？ 第一、开着飞机换着引擎。难度最大，需要兼容历史数据、各类链接、核 心功能等。这类系统需要处理好中间的灰度阶段，那是一个高危期。毕竟 系统的上线，无论切换速度再快，都要防止脏数据的产生。 第二、新人新办法，老人老办法。数据互相隔离，原有用户在原系统继续 使用，新注册用户在新平台上使用。常见于多个App版本共存阶段。 第三、休眠疗法。一刀切的做法，在某个时间点，老系统直接嘎然而止， 暴力地通知用户进行系统升级或者切换。国有型、甲方型、垄断型的App 在重大重构升级时会做这个选择。
  • 53.如何衡量重构是成功的？ 经过过渡期之后： 1）用户满意度 2）财务成本 3）开发成本 4）可理解成本 5）可维护成本
  • 54.重构之踵 第一、为了KPI而重构。 第二、为了个人英雄主义而重构。 1）个人技术信仰 2）个人架构理念 3）个人技术经历 第三、为了超前需求而重构。 第四、为了重构而重构。
  • 55.阿里巴巴重构之路：单体应用
  • 56.阿里巴巴重构之路：大型分布式应用 CDN Web 应用 集群 交易 评价 用户 交易 评价 用户 评价 用户 运行 状况 监测 和报 警系 统 商品 ... 数据层 数据缓存集群 交易 ... 服务 消息 页面片段缓存集群 业务 逻辑 集群 商品 商品 ... 搜索 TFS
  • 57.阿里巴巴重构之路：单元化 cdn1 cdn2 。。。 cdnN Route By UserId Center Unit1 Unit2 UnitN web RPC web web web center service Message service service service cache cache cache cache storage storage storage storage Data Sync
  • 58.阿里巴巴重构之路：云化
  • 59.欢迎关注msup微信公众账号 关注大会微信公共账号，及时了解大会动态、 日程及每日更新的案例！ 关注公众号获得 更多案例实践