AS深圳2018 超大规模软件架构度量与演进的思考和实践 吴文胜

ArchSummit

2018/09/14 发布于 技术 分类

文字内容
1. 超⼤大规模软件架构⾃自动化度量量与演进 思考与实践 吴⽂胜 华为公司架构⾃动化度量、看护与演进能⼒提升⼯作组 华为公司·2012实验室·公司架构部 邮箱:wuwensheng@huawei.com 微信:wws117689
4. • 缘起 • 定位 • 实践 • 经验 • 展望
5. 华为 正进⾏行行着 已知业界最⼤大规模 扐⇗㪗㩥哋▉◷ㆇ撰⃯䇵押 テ⃻⹿惖
6. 为什什么 启动架构⾃自动化度量量与演进
7. 架构腐化、耦合⽇日益严重 接纳新需求难 交付周期⻓长 加班严重 协调⼯工作投⼊入⼤大 问题定位难 ……
8. 商业模式 + 超⼤大代码规模 = 问题基本⽆无解! • 产品依照合同,交付给客户(运营商),并运⾏行行在客户侧!!! • 对于多数华为软件产品,互联⽹网架构实践不不能照搬
9. 坠⼊入深渊——软件开发者的宿命
10. 必须找到⼀种能在产品交付界⾯内 开展超⼤规模软件 架构防腐与演进的⼯程⽅法
11. 管理理层的期望 告诉我: ↈ➢㪗㩥怉撰涹∯獑 ⟋播⸹⨉棏歹獑 Ᵽ∶䨡㔬㠚押獑
12. 领导要求 开展“架构⾃自动化评估与看护”
13. 架构⾃自动化评估靠谱不不靠谱? ႵીႵ‫ކ‬ൡ֥ࡏ‫ܒ‬ ‫۽‬ऎᆦӻĤෘ‫࠯م‬ඌ ି۞‫ק‬ગĤ ᄸဢ‫ק‬ԛӁ௖ಪ֥ ႵႨ֥ࡏ‫ܒ‬௟‫ܙ‬ѓሙĤ ‫۽‬ऎ௟‫ܙ‬ሙ҂ሙĤି‫ڎ‬ ಞӁ௖๶ؒྐ‫ڛ‬Ĥ ି҂ିูߐགྷႵ௟‫ܙ‬ѓ ሙ4".aJO'VTJPOĤ ࢲ‫߶ݔ‬ФႨႿ ིࠛॉ‫ނ‬ગĤ ……
14. 领导决定 要有“架构⾃自动化评估与看护能⼒力力”
15. 于是有了了……“华为公司架构⾃自动化评估与看护” 架构评估看护⼯工具 UADP Guarding • 度量模型参考ISO 25010 ,McCall模型,Boehm模型等, 指标参考SAM, inFusion • 由跨产品线架构标准工作组共同拟制
16. 困扰持续——直到某天看到这张图......
17. 悟道:本质 縬 ࡼࡏ‫֥߄ڪܒ‬༯ሖ৯đሇэູࡏ‫ܒ‬Ⴊ߄֥ఠႄ৯ 縬 ሔሶࡏ‫ܒ‬ဆ߄֥౴൝‫مބ‬ᄵđᆷ֝ު࿃ࡏ‫ܒ‬ഡ࠹
18. 悟道:可⾏行行性 縬 ᄝႿğି‫ڎ‬Ϻष‫ؿ‬๶ؒ۷‫ֹݺ‬৘ࢳ‫ބ‬ဆࣉࡏ‫ܒ‬Ĥ 縬 ҂ᄝႿğ؇ਈ൞‫ڎ‬ປСaࣚሙĤ
19. 悟道:使命 ᆩ֡‫ڿ‬эଁᄎ ؇ਈ‫ڿ‬೿ࡏ‫ܒ‬ ollૄ่ଁᄎ֥‫ފ‬ੀ‫׻‬൞ॺখ໭б֥đ၂่჈đଧஃ൞ᄜն֥჈đམ‫ڿ‬э၂۱‫ފ‬ੀః ൌ‫׻‬൞঒଴໭б֥൙bॖ൞đ‫؟ޓ‬ൈީࣼෘૼૼᆩ֡ીႵ༐ຬႳཟਸ਼၂่‫ފ‬ੀđ္ሹ ൞ေ࣐৯൫൫֥llp癐癐癐癐癐癐癐 癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐癐ᅋሱ࿵჏ࡾଲcuገᛠv
20. 华为公司架构⾃自动化度量量与演进极简史 ☯ℛ⑍⛙㪗㩥哋▉◷ 庥∑⃯䧬㖅 2014 5#+Z ☯ℛ⑍⛙㪗㩥哋▉◷ ㆇ撰⃯䧬㖅 2015 5#+Z ☯ℛ⑍⛙㪗㩥哋▉◷ ㆇ撰ֻ䧬㖅⃯䇵押 2017 5#+
21. 华为公司架构⾃自动化度量量、看护与演进 Architecture Measurement, Guarding & Evolution ⓧ㩱ֻ䦲䀬㪗㩥ֻ㪗㩥怉撰⚫⑗䇵押恬■猾ㅗ▁⇆撰◷ֻ⛐岧◷猾≼㪗㩥ラ⚫㇡⚲⧃椀⚣勤猾⇆ ⊠䛧峄㪗㩥猾㠐㝲⑗㇡⼶撮㩥猾≠㪗㩥⃮㢎恬⛲⛩䛧猾⻰㹆ֻㅔ䆲䇵押ּ 变“登山”为“下海”: • 将架构腐化转化为架构优化的动力,让软件摆脱坠入混沌的宿命 • 帮助架构师和开发团队从架构问题中学习、掌控架构 • 培养全体工程师的代码及架构“洁癖”,架构意识 架构 设计Vn 看护:实现对设计的偏离 目标 架构Vn 产品 版本Vn 产品 版本Vn+1 度量:与目标架构的偏差 演进:架构目标/设计/实现的迁移 㪗㩥ㆇ撰ֻ䧬㖅⃯䇵押䥥⑔俜
22. 华为公司架构⾃自动化度量量、看护与演进解决⽅方案 5.0 • 报告与可视化 ⛐⹻┗䥥㪗㩥怉撰⚫恬■㖆✫猾㪗㩥创楘⚫⋏⯮㖆✫猾㪗㩥㤀冈庥∑猾⫛Ⅿ+&'䥥㪗㩥怉撰㖆✫猾ⓧ⼣䥥挜扲岧 ⧟猾㩥㇛岧⧟猾㪗㩥䏎䎚岧⧟猾㕡㨐岧⧟猾抱嬭岧⧟猾揉剓岧⧟ • 架构度量量 冥⇗◷㪗㩥ㆇ撰猾㧮▂◷㪗㩥ㆇ撰猾㩥㇛㪗㩥ㆇ撰猾㪗㩥⌛▂ㆇ撰猾㪗㩥䏎䎚ㆇ撰猾㨍⨑◷㪗㩥ㆇ撰 • 架构看护 ↅⅳㇰ岥⓺⹻┗猾⫛Ⅿ岥⓺䥥㪗㩥䧬㖅猾㚆⛄⚹㧕㉒➮ⓧ㩱⃯亂䛧猾㨍⨑◷㪗㩥䧬㖅 • 重构与演进 ⇠䨀撮㩥猾冥⇗◷㪗㩥扦▊撮㩥
23. 架构重构 vs 治病 ⅀僿⁍╛ ⽣生病 or 不不舒服 望闻问切 治疗⽅方案 治疗 病状消除 培本固元 䗐℃╛ⶆ ⽣生病 问诊&检查 治疗⽅方案 治疗 指标改善& 病状消除 ⨚₮⃚々巤⅐䢤 㧖㦤揭㦤 架构腐化 专家分析 权衡设计 重构⽅方案 重构 腐化消除 ⨚₮㧖㦤吊Ⓢテ揯䢤 㧖㦤䄴懻 指标变差 架构坏味 专家分析 权衡设计 重构⽅方案 架构演进 指标改善 坏味消除
24. 正如医疗仪器器不不会替代医⽣生的诊断 架构度量量也不不能代替 架构师和开发团队的权衡与判断
25. 实践⼀一:统⼀一的架构度量量标准SAI Standard Architecture Index 獑 /E%CNN㴂⩬ $QGJO㴂⩬ +51 KP(WUKQP 5#/ SAI 1.0 ` ⇄䫢冈㪗㩥ㆇ撰㫨⒧ ō ℋ⇄䫢⨰❔挴⚫㗨㫨 ō 㠐㗢%ֻ% 猾,CXC SAI 2.0 ` 㴂⨸冈㪗㩥ㆇ撰㫨⒧ ō ⒰⻲⇄䫢❔挴猾医䐇㪗㩥冈ㆇ 撰㗨㫨⃯㪗㩥⨰❔挴 ō ⹭⡥ㆇ撰㴂⩬猾ㇶ⑆㪗㩥ⓧ⼣ ō 㮡㫆䲮㪗㩥⨰❔挴 ō 㠐㗢%ֻ% 猾,CXC SAI 3.0 ` 橃⛲⑉橃峄匇⃯㥛叞䫵⚲䥥俜净冈㪗㩥ㆇ撰㫨⒧ ō 5#+㪗㩥⼿㌈㪗㩥屢倁㪗㩥⨰❔挴 ō 㗪㪗㩥殯㬝ⓧ作ㆇ撰 ō 㗪㪗㩥⼣冈ⓧ⼣ㆇ撰 ō 㗪凷䳬廎峡ⓧ┌ㆇ撰 ō 㢑⭿ 俜净冈㗨㫨 ō 㠐㗢%ֻ% 猾,CXC猾,CXC5ETKRV猾2[VJQP猾4WD[猾)Q
26. 实践⼀一:统⼀一的架构度量量标准SAI(续⼀一) SAI 1.0度量量模型 标准架构指数 SAI 架构属性 设计属性 度量项 代码SAI 结构复杂度 … 设计遵从度 … 代码复杂度 … … … 模块扇⼊入数 模块扇出数 … 模块级设计违规数 ⽂文件级设计违规数 … 演进接⼝口稳定性 … 全局变量量数 代码⾏行行 …
27. 实践⼀一:统⼀一的架构度量量标准SAI(续⼆二) SAI 1.x 部分指标及早期计算模型 SAI的计算早期采用缺陷累计加权: SAI = ∑(权重i*架构坏味道i个数) / KLOC • 尊重惯例,分配初始阈值及权重,以延续产品团队的经验和感受 • C、C++和Java指标不同,相同的指标阈值和权重大致相同 • 由架构专家及度量专家,依据指标对应问题的严重性,调整/分配阈值及权重 • 管理团队重视的,适当加大权重 • 发放问卷,调查架构师、设计师对各架构坏味道影响高低的主观判断,根据 结果排序,适当调整各指标及坏味道权重,使与大家“印象”尽量一致 • 为避免争议,不公开权重 • 随时访谈产品团队,优化指标及计算模型 设定 Benchmark⽅方案:对常⽤用的C、C++和Java,分别选取⼀一组优秀开源软件,测算得到SAI,作为各⾃自的标杆
28. 实践⼀一:统⼀一的架构度量量标准SAI(续三) SAI 2.x ⾯面临的问题和挑战 • 服务化、组件化架构深入应用,如何度量各种不同的架构风格? • 市场压力,迫使产品呼唤架构全面解耦,如何提供更完善的解耦度量,如,自研产品-开源解耦性? • 更精准地度量架构 • 更精确地识别架构问题所在位置、层级及其影响,聚焦架构级问题 • 新型语言的产品越来越多,技术栈日益丰富,要求纳入度量 • 现有SAI度量和坏味道识别能力有限,部分产品SAI改进接近极限,如何牵引产品继续改进架构? • ……
29. 实践⼀一:统⼀一的架构度量量标准SAI(续四) SAI 3.0 改进部分思路路 • (解决多种架构风格的准确度量)为服务化、组件化、单体架构,分别设置不同的度量指标集 • (为更多新兴编程语言提供度量支持)支持Ruby、JavaScript、Python、GO,不同语言,指标不同 • (更精准、更多角度地架构度量指标及问题的影响范围)将架构分为多个层次,设置相应的指标,关注点分离 系统 子系统 组件 模块 文件 函数/类
30. 实践⼀一:统⼀一的架构度量量标准SAI(续五) SAI 3.0部分指标示意 架构度量指标 指标名称 所属SAI版本 需求来源 指标版本号 上一版本号 标准更新时间 指标启用时间 更新人 指标定义&说明 指标图示 度量方案&算法 重构建议 实际案例 社区讨论 已知标准缺陷
31. 实践⼀一:统⼀一的架构度量量标准SAI(续六) 基于问题的SAI 指标引⼊入⽅方法: 举例例 1. 根据团队反馈或架构审视,发现实际架构问题或标准缺陷(如,实际产品中 某些服务、组件职责过于分散) 2. 思考,讨论,结合架构原理与实践经验,确定牵引方向(如,应牵引服务或 组件尽可能执行单一职责,权重较高) 3. 绘制坏味道的架构图示(如右图) 4. 设计架构度量方案、算法及阈值等(略) 5. 设计指标 6. 试点,根据反馈和实际情况,调整指标定义、算法或阈值等 7. 将指标纳入SAI指标体系 指标名称:服务/组件功能不不单⼀一 定义:外部调⽤用服务/组件时,被调⽤用的接⼝口可以分为两个以上互 补相关的功能簇。 版本:V1.0 所属标准:SAI 3.0 注:不不同颜⾊色表明服 务/组件内部实现(⽂文件 粒度)间不不存在耦合 (调⽤用或数据访问等) 基于架构原理理的SAI 指标定义⽅方法: 略略 重构建议:将组件中互不不耦合的部分切分为(或划归)多个组件
32. 实践⼆二:架构质量量报告 SAIReport: 产品架构质量量仪表盘(星级、SAI、坏味道)及趋势⼀一⽬目了了然 SAI趋势、基线、各均值等 SAI及质量量星级 架构属性得分 架构要素得分 架构坏味道加权得分,点击 可进⼊入具体的坏味道列列表, 含问题代码
33. ʼn㪗㩥⛐岧◷㧪㉩Ⰸ䥥ⱞ⯥猳▁⃡ℋ⃽屠浍⃫⼒叞䧬ⓛ獍㧪↡℩⃮⛩拣 䥥猾浍⃫⼒⛐⇆㚱ⓛ㩆猾㡕㠚猳䠉恘㩆㉩㢚⊠猾⛐⇆⻚䢨⃬噐ּⱣ㩽㺰 实践三:可定制的集成架构视图 ℋ㪗㩥ラ揞㙭㛂Ⅷ抺ℋ㕡叞猾厐⹻⇻⨉㠩䙨⃫㧪㉩Ⰸ䥥ⱞ⯥ּ ロ㧼叞Ⰰ㠐㗢㴂⨸冈匇⛩䥥⛐岧◷ּ拻抨㡑㙏⼶䰛猾浒▉㇡⚲↛✹㕫⹤ 㡕㠚ֻ⇹◷ּň ŃŃ㪱䫵⚲⧃椀NGCFGT SAIVisualizer: 产品架构划分及其依赖、违约等,分层,可视,可定制,可导出 • 可凸显、展开选中组件的部件和依赖 • 可直接定位到接口、文件、包、代码...... • 可按需要自由组合 • 可在界面直接创建/编辑/取消架构规则 • ……
34. 实践四:模型驱动的构建 MDBEngine:颠覆⼤大规模软件开发的构建⼯工程活动模式 现状:手工编写编译构建脚本;专人或各自维护;发现问题,人工调优 愿景一:构建工程模型化、可视化,让开发团队彻底摆脱手工维护编译构建工程的低效和困扰。 (再)设计 构建模型 逆向⽣生成 构建模型 ⽣生成构建脚 本(框架) ⼿手⼯工完善 构建脚本 构建 度量量&看护 执⾏行行 编译构建 ⾃自动/⼈人⼯工 构建调优 理理想的架构设计,可 由诸多架构视图的相 似的循环迭代构成 关键技术:构建视图、构建模型定义,构建模型可视化,构建脚本自动生成,构建模型的逆向生成,构建工程度量模型及标准……
35. 实践四:模型驱动的构建(续) MDBEngine:颠覆⼤大规模软件开发的构建⼯工程活动模式 现状:大规模、长周期的软件的编译构建工程,往往存在大量缺陷,导致构建效率低下,且难以维护 愿景二:高效的编译构建;构建工程易维护 某产品试点扫描并消除 构建坏味道,⼀一个多⽉月 后,编译服务器器减少 50%!编译构建耗时减 少25%! 构建(反)模式,包括:弹匣模式,模板模式,策略模式、构建器模式、 标志外置模式等,可用于指导构建模型的设计与脚本开发/维护 举例例:模板构建模式,⼤大多数模块的构建脚本都很相似,脚本代码重复 Client GenBuilder +CopyAndFill 构建坏味道,包括重复构建,废弃构建脚本,冗余文件,过深构建 链,单一构建规模过大,多用途,散弹式构建,循环构建链,等,是 构建视图的度量与重构的基础 举例例:散弹式构建,⼀一个组件的编译链接,⽤用到⼤大量量其他组件⽬目录下的⽂文件 GenBuilderA
 GenBuilderB
36. 实践五:组件化架构辅助重构 Componentizer:获得/恢复破坏的组件化架构 现状:大多数的组件的初始设计无迹可寻,实现则面目前非。如何恢复或理顺已被“破坏”的组件化架构? 方法之一:以组件聚类算法的结果为目标,开展重构 1. 设定组件化架构重构目标 2. 针对现有代码,开展架构度量,得到组件化架构度量指标 3. 组件化架构目标是否达成? 4. 扫描代码,进行组件聚类分析 5. 以组件聚类分析结果为目标,策划并实施重构 6. 反复上述2~5,直至团队对重构效果和指标感到满意 开发团队逆向思维的 ⾃自主创新
37. 架构⾃自动化度量量与演进在研发流程中的定位 眢 ࡏ‫ܒ‬ଆ྘აܿᄵ 软件架构⾃自动化度量量、看护与演进 眢 4"* 眢 ॖ൪߄ 眢 ࡏ‫ߊܒ‬໅֡ 眢 આࠠ൪๭ 眢 ष‫ؿ‬൪๭ 眢 ࠯ඌ൪๭ ll 眢 ‫ࡹܒ‬൪๭ 眢 ቆࡱ൪๭ ll 眢 ҩ൫൪๭ 眢 หྟ൪๭ ll 眢 ҆ඇ൪๭ 眢 ᄎྛ൪๭ 眢 ࠯ඌ൪๭ ll 需求分析与设计 编码实现 编译构建 测试&验证 部署&运⾏行行 Codebase Commits Bug reports Logs ඪૼğഈඍ۲൪๭ࠣః؇ਈഉໃିປಆᆦӻ
38. 已在华为所有主⼒力力产品全⾯面应⽤用 130+ 产品 400+ 版本 17年年公司SAI平均提升 14.5%
39. 为研发效率提升提供了了⽀支持 4"*Y‫ࣉڿ‬აളӁੱࠣщၲ‫ิੱིࡹܒ‬ശ֥ཌྷܱྟ‫ٳ‬љູ‫ބ‬
40. 产品的认可 • 当前SAI对促进产品架构改进起了了很⼤大的作⽤用。17年年针对性地做了了部分改进,架构度量量⼯工具起到了了 作⽤用……明年年重点优化…… • ……各PDU基本上都反馈对于架构解耦活动的开展有⽐比较好的牵引和指导作⽤用……已在12⽉月研发 ST上汇报,SAI在……例例⾏行行度量量可视化已获得认可……优化建议:…… • 从我的⻆角度看,不不可能⼀一把都搞定,度量量准确性还好。关键是有这个旗帜在,可以推动产品持续 改进、优化…… • 随着SAI推⾏行行三年年下来,产品都有了了很⼤大的改进。如何持续SAI的牵引性?…… • SAI指数很好,度量量很全⾯面……能否呈现得更更⽴立体⼀一点,给出具体改进⽅方向,帮助辅助决策……
41. 架构⾃自动化度量量与演进推⾏行行·关键成功要素 挖掘⽤用户需求 • ⽤用户⽀支持 • 产品⽤用户访谈 • 问卷调查 • ⽤用户社区 • 发布统⼀一的架构度量量标准 设定公司战略略 • 明确公司架构战略略 • ⾼高层汇报与沟通 • 牵引产品⾃自我改进 度量量⼯工具使能 • UADP ArchGuarding 跨领域专家组织⽀支撑 • 跨领域软件分析与度量量技术组 技术及⼯工程应⽤用组合创新 • 国际会议 • 技术研究与合作
42. ⼀一直在思考...... 为何软件开发总是“996”?
43. ⼀一直在思考...... 为何没有“银弹”?
44. 软件规模⼀一直在迅速增⻓长
45. ……加速增⻓长 MB 1000 750 Volvo Downloadable SW Size 917 500 250 0 1.5 S80/1998 4.9 XC90/2002 10.9 S80/2006 18.6 V70/2007 20.6 XC60/2008 117.5 V60/2011 97 V40/2012 SPA/2014
46. ……普遍增⻓长 美国国防部新开发及维护代码的增⻓长率为约15~25% March,2017,“Software Productivity Trends and Issues”
47. ……⽣生产率的增⻓长却⾮非常有限 4% March,2017,“Software Productivity Trends and Issues”
48. 糟糕:⽣生产率会随规模增⻓长⽽而⼤大幅下滑!
49. 架构腐化是⻓长期的、不不可逆转的趋势 • 软件规模的持续增⻓长,本质是业务复杂度的增⻓长,是软件“吞噬世界”的必然结果 • 不不断遭到侵蚀和腐化的架构,使得软件维护成为⼀一场负重⾏行行军
50. (微)服务化、组件化固然好! 代价是……运⾏行行期的复杂性和巨⼤大的不不确定性 ୍đႵུྍӱ྽ս઒֥‫ڬ‬ቔႨđ ֝ᇁ(NBJMႲདЕ‫ؿ‬ಆ౯ྟ‫ܣ‬ᅰđ‫ڛ‬ ༀᇏ؎Ӊղཬൈ ୍đ༢๤ശࠩാϧ֝ᇁ%SPQCPY ᆜ۱௜෻ᜰࠏ฿Ć ୍đ‫گ‬ᄖ۷ྍ֝ᇁ༢๤๔ᆸ‫ڛ‬ༀ ཬൈ ୍đଽ҆%/4հ༂đ֝ᇁJ5VOFT ‫"ބ‬QQ4UPSFᜰࠏཬൈ ୍đଽ҆ຩ઎հ༂֝ᇁ‫܋܄‬ᄉ‫ڛ‬ ༀᜰࠏӑ‫ཬݖ‬ൈ ୍đս઒۷ྍհ༂֝ᇁ၍‫׮‬ა 8FC؊ཬൈ҂ॖႨ ୍đնਈሧჷླ౰֝ᇁ୸ᇝႨ޼ ଴ၛ֨੣Ⴏད ୍đॖၐ֨੣‫ିۿ‬۷ྍ֝ᇁૅ ‫ݓ‬a୸ᇝႨ޼໭‫֨م‬੣ ୍đದູᄎົҠቔհ༂֝ᇁ࿰ઔ ࿠4‫ڛ‬ༀᇏ؎ཬൈđն૫ࠒᄉ‫ڛ‬ༀ ໭‫م‬൐Ⴈ 㿉獌⃫拑㡑㙏㜹哋䙬☤䱆勢ラ㨱㡺猾ㅗ⌻⭿孆 ň⓼持㌈Ⱂ䍖㤐䀜俜净䥥㫨㊸ּ⻜㹜㉩榟猾∧⻝哕㹜ↂ䥥惐♕㧪㣁㡑㩂ʼn ŃŃ--‫Ⱂ׃‬㚈ׄ
51. “午餐”收费理理由 • 匇⛩⃮䍎⹻㉬獌ň⹿∴棕匇⛩Ᵽ㩽⸹⨉猾⃮⇻⧁⇜∶⚀⧁勭䁩Ⱂʼn猾䙬㺦猾 ň匇⛩⃮㹜猾⛋㤐㙃䲮㢚ㇰ㕹呟≁ʼn猾✕㡨厽 • ⯮㨣ㆇ拳⭿䗽㏔獌ň扐⇗䥥⑦䱡⯮㨣ㆇ楰㣗棕拳⭿ʼn猾✕㡨厽猾` ⑦䱡⯮㨣ㆇ獌㔡㧪⛐峄匇䥥⚹◷揞嚘㉸峄匇䥥䛧㏔㎦⒖⃬猾扐⇗㪗㩥ℎ樺㋢挜扲惐㉥㡑ℬ❭ • ⯮㨣ㆇ⹩㌳⹻㉬獌ň峄匇猾◦㗍废庂㴂ㇰֻ㪗㩥㴂ㇰ殯㬝个㕡㨐䥥ㅵ䠉猾⛋叞ㄇ㩆扐⇗⯮㨣ㆇ䥥椮凕猺♔恬抲⑦䱡⯮㨣ㆇ猻㓷⚲䠀㣗棕 㓷㉃㋢䥥才䳜猾ㅗ⃮叞⻝哕⯮㨣ㆇ䥥椮∯ʼn猾✕㡨厽猾` • ň扐⇗⼒⎰䒖猾㉩榟㙭㛂⃵㣁㾶䳑撰猾勭⃵猾抹捖⹩䏎╼⹇不Ⅽ⹻㉬猾⅀⼒㤐廕獌⹤=䥥⯮㨣ㆇ?㌜㤐⇻⭿▁ʼn猾014/#0#7)756+0'
52. ⼈人的智⼒力力是有上限和局限的 ଊ݆ඔሳğ “…the span of absolute judgment and the span of immediate memory impose severe limitations on the amount of information that we are able to receive, process, and remember. By organizing the stimulus input simultaneously into several dimensions and successively into a sequence of chunks, we manage to break (or at least stretch) this informational bottleneck.” “The Magical Number Seven, Plus or Minus Two”, George A. Miller, 1956
53. 软件的未来有个⼤大难题 变化加快 银弹没! 有 规模增⼤大 复杂度增加 腐化趋重 效率下滑
54. 每个解决⽅方案都会带来 更更多更更复杂的问题
55. 改变是必须的…… ňↀ㠀㻵戺懧㘥㓬⸦㦼掑⚬〣‡╚␦ㄠ㦅ʼn 巽⒇Ԓ‶⬶㩣䂰ԓ #TECFKC
56. ⾛走向⾃自动化、智能化,
 是未来软件⼯工程的必然选择! “⼈类⽆法继续用⼿⼯⽅式应对未来软件开发的规模和复杂性挑战” M.L. Albort, M.T. Fisher《架构真经》
57. 脚下之路路:“架构演进+特性开发”双甬道模式 需求 分析 หྟ‫ٳ‬༅ഡ࠹ൌགྷ ࡏ‫ٳܒ‬༅ഡ࠹ൌགྷ؇ਈဆࣉ 模型驱动的构建 技术视图分析-平台选择&定制&开发 自动化 回归测试 “自然选择只是利用微细的、连续的变异⽽发⽣作用;她从来不能采取巨⼤⽽突然的飞跃,⽽⼀定是以 短的、确实的、虽然是缓慢的步骤前进。” 达尔⽂,物种起源
58. 脚下之路路:基于度量量的多视图迭代敏敏捷软件⼯工程 ୉ཟğ߫‫گ‬აဆࣉ ഡ࠹ࡹଆ ō 挜扲岧⧟ ō ⇄䫢岧⧟ ō 㩥㇛岧⧟ ō 揉剓岧⧟ ō 抱嬭岧⧟ ō 䕚㌈岧⧟ ō 䀬庶岧⧟ ō 㕡㨐岧⧟ ō ŎŎ ᆞཟğഡ࠹აൌགྷ щ઒ ‫҆ ࡹܒ‬ඇ ᄎྛ ࡏ‫ܒ‬၇ঠ‫ٳ‬༅ଆ྘߫‫گ‬ॖ൪߄ ࡹ৫඗ྍ ࡏ‫ܿܒ‬ᄵ ࡏ‫ܒ‬؇ਈु޹
59. 脚下之路路:近期技术发展路路线图 架构工具外部开源 智能 架构工程 架构 演进 架构 度量&看护 架构 模型&视图 架构 恢复 依赖 分析 架构智能演进 研究架构自动重构 研究架构演进目标 &需求 研究坏味道辅助重构 E2E构建工程自动化 完善构建脚本自动 生成技术 构建坏味道自动调优 架构工具内部开源 优化线框图展示 研究特性解耦标准 完善代码视图 完善构建视图度量标准 支持架构全面解 耦的SAI 建立运行视图度量标准 建立技术视图解耦标准 架构全视图 试点应用债务视图 研究特性视图恢复 研究运行视图恢复 研究部署视图恢复 DSM工程化呈现 完善热点视图 从研发数据挖掘架构 依赖全景图 完善构建视图恢复 研究测试视图恢复 研究技术视图恢复
60. 未来之路路:f(AI, ⼈人机交互, …)=从局部重构到软件智能化演进 智能化 生态演进 智能化 软件演进 智能辅助服 务/组件演进 智能辅助 方面演进 智能辅助 架构重构 䫢⑽ 抨⚜^㔬テ 䫢テ ㈴⃬^哋▉ ☯ℛ抹⨉抺播猳 䫢䰿 㨋㩆^㥛叞
64. 求: 同道、加盟、合作 谢谢! 㐀弃獌㊸焰猾⧞牺猾椠㫨猾㓩☻猾椠怃ㅕ㩆䥥㩑ⓛテ∽❭燯╼㠐㗢猳 㐀弃㔡㧪䥥⛩∽⇺∕猳 㓲⇍⃡恘䠉㼸㼕❭㥛㑈弒⑺Ⅷ⃡㧓∀Ⰸ䥥亨䷁猳猳猳 ✕㡨厽 YWYGPUJGPI"JWCYGKEQO ㊏⋂獌YYU