超大规模软件架构度量与演进的思考和实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 超大大规模软件架构自自动化度量量与演进思考与实践吴文胜华为公司架构自动化度量、看护与演进能力提升工作组华为公司·2012实验室·公司架构部邮箱：wuwensheng@huawei.com 微信：wws117689

2. • 缘起 • 定位 • 实践 • 经验 • 展望

3. 华为正进行行行着已知业界最大大规模扐⇗㪗㩥哋▉◷ㆇ撰⃯䇵押テ⃻⹿惖

4. 为什什么启动架构自自动化度量量与演进

5. 架构腐化、耦合日日益严重接纳新需求难交付周期⻓长加班严重协调工工作投入入大大问题定位难 ……

6. 商业模式 + 超大大代码规模 = 问题基本无无解！ • 产品依照合同，交付给客户（运营商），并运行行行在客户侧产品依照合同，交付给客户（运营商），并运行行行在客户侧！！！ • 对于多数华为软件产品，互联网网架构实践不不能照搬

7. 坠入入深渊——软件开发者的宿命

8. 必须找到一种能在产品交付界面内开展超大规模软件架构防腐与演进的工程方法

9. 管理理层的期望告诉我： ↈ➢㪗㩥怉撰涹∯獑 ⟋播⸹⨉棏歹獑 Ᵽ∶䨡㔬㠚押獑

10. 领导要求开展“架构自自动化评估与看护”

11. 架构自自动化评估靠谱不不靠谱？ ……

12. 领导决定要有“架构自自动化评估与看护能力力力”

13. 于是有了了……“华为公司架构自自动化评估与看护” 架构评估看护工工具 UADP Guarding • • 度量模型参考ISO 25010 ，McCall模型，Boehm模型等, 指标参考SAM, inFusion 由跨产品线架构标准工作组共同拟制

14. 困扰持续——直到某天看到这张图......

15. 悟道：本质

16. 悟道：可行行行性

17. 悟道：使命

18. 华为公司架构自自动化度量量与演进极简史 ☯ℛ⑍⛙㪗㩥哋▉◷ 庥∑⃯䧬㖅 ☯ℛ⑍⛙㪗㩥哋▉◷ ㆇ撰⃯䧬㖅 ☯ℛ⑍⛙㪗㩥哋▉◷ ㆇ撰ֻ䧬㖅⃯䇵押 2014 2015 2017 5#+Z 5#+ 5#+Z

19. 华为公司架构自自动化度量量、看护与演进 Architecture Measurement, Guarding & Evolution ⓧ㩱ֻ䦲䀬㪗㩥ֻ㪗㩥怉撰⚫⑗䇵押恬■猾ㅗ▁⇆撰◷ֻ⛐岧◷猾≼㪗㩥ラ⚫㇡⚲⧃椀⚣勤猾⇆ ⊠䛧峄㪗㩥猾㠐㝲⑗㇡廾撮㩥猾≠㪗㩥⃮㢎恬⛲⛩䛧猾⻰㹆ֻㅔ䆲䇵押ּ 变“登山”为“下海”：架构设计Vn 看护：实现对设计的偏离目标架构Vn 产品版本Vn • 将架构腐化转化为架构优化的动力，让软件摆脱坠入混沌的宿命产品版本Vn+1 • 帮助架构师和开发团队从架构问题中学习、掌控架构度量：与目标架构的偏差 • 培养全体工程师的代码及架构“洁癖”，架构意识演进：架构目标/设计/实现的迁移㪗㩥ㆇ撰ֻ䧬㖅⃯䇵押䥥⑔俜

20. 华为公司架构自自动化度量量、看护与演进解决方方案 5.0 • 报告与可视化 ⛐⹻┗䥥㪗㩥怉撰⚫恬■㖆✫猾㪗㩥创楘⚫⋏⯮㖆✫猾㪗㩥㤀冈庥∑猾⫛Ⅿ+&'䥥㪗㩥怉撰㖆✫猾ⓧ夕䥥挜扲岧 ⧟猾㩥㇛岧⧟猾㪗㩥䏎䎚岧⧟猾㕡㨐岧⧟猾抱嬭岧⧟猾揉剓岧⧟ • 架构度量量冥⇗◷㪗㩥ㆇ撰猾㧮▂◷㪗㩥ㆇ撰猾㩥㇛㪗㩥ㆇ撰猾㪗㩥⌛▂ㆇ撰猾㪗㩥䏎䎚ㆇ撰猾㨍⨑◷㪗㩥ㆇ撰 • 架构看护 ↅⅳㇰ岥⓺⹻┗猾⫛Ⅿ岥⓺䥥㪗㩥䧬㖅猾㚆⛄⚹㧕㉒➮ⓧ㩱⃯亂䛧猾㨍⨑◷㪗㩥䧬㖅 • 重构与演进 ⇠䨀撮㩥猾冥⇗◷㪗㩥扦▊撮㩥

21. 架构重构 vs 治病生生病 or 不不舒服生生病架构腐化指标变差架构坏味望闻问切问诊&检查专家分析专家分析治疗方方案治疗方方案权衡设计重构方方案权衡设计重构方方案治疗治疗重构架构演进病状消除培本固元指标改善& 病状消除腐化消除指标改善坏味消除

22. 正如医疗仪器器不不会替代医生生的诊断架构度量量也不不能代替架构师和开发团队的权衡与判断

23. 实践一一：统一一的架构度量量标准SAI Standard Architecture Index 獑 SAI 3.0 ` 橃⛲⑉橃峄匇⃯㥛叞䫵⚲䥥俜净冈㪗㩥ㆇ撰㫨⒧ ō 5#+㪗㩥手㌈㪗㩥屢倁㪗㩥⨰❔挴 ō 㗪㪗㩥殯㬝ⓧ作ㆇ撰 ō 㗪㪗㩥夕冈ⓧ夕ㆇ撰 ` ō 㗪凷䳬廎峡ⓧ┌ㆇ撰㴂⨸冈㪗㩥ㆇ撰㫨⒧ ō 㢑⭿ 俜净冈㗨㫨 ō 㠐㗢%ֻ% SAI 2.0 ō SAI 1.0 /E%CNN㴂⩬ $QGJO㴂⩬ +51 KP(WUKQP 5#/ ⒰⻲⇄䫢❔挴猾医䐇㪗㩥冈ㆇ 撰㗨㫨⃯㪗㩥⨰❔挴 ` ō ⹭⡥ㆇ撰㴂⩬猾ㇶ⑆㪗㩥ⓧ夕 ⇄䫢冈㪗㩥ㆇ撰㫨⒧ ō 㮡㫆䲮㪗㩥⨰❔挴 ō 㠐㗢%ֻ% ō ℋ⇄䫢⨰❔挴⚫㗨㫨 ō 㠐㗢%ֻ% 猾,CXC 猾,CXC 猾,CXC猾,CXC5ETKRV猾2[VJQP猾4WD[猾)Q

24. 实践一一：统一一的架构度量量标准SAI（续一一） SAI 1.0度量量模型代码SAI 标准架构指数 SAI 架构属性 … 设计遵从度 … 设计属性度量项 … 结构复杂度 … 代码复杂度 … 模块扇入入数模块级设计违规数演进接口口稳定性全局变量量数模块扇出数文文件级设计违规数 … 代码行行行 … … …

25. 实践一一：统一一的架构度量量标准SAI（续二二） SAI 1.x 部分指标及早期计算模型 SAI的计算早期采用缺陷累计加权： SAI = ∑(权重i*架构坏味道i个数) / KLOC • 尊重惯例，分配初始阈值及权重，以延续产品团队的经验和感受 • C、C++和Java指标不同，相同的指标阈值和权重大致相同 • 由架构专家及度量专家，依据指标对应问题的严重性，调整/分配阈值及权重 • 管理团队重视的，适当加大权重 • 发放问卷，调查架构师、设计师对各架构坏味道影响高低的主观判断，根据结果排序，适当调整各指标及坏味道权重，使与大家“印象”尽量一致 • 为避免争议，不公开权重 • 随时访谈产品团队，优化指标及计算模型设定 Benchmark方方案：对常用用的C、C++和Java，分别选取一一组优秀开源软件，测算得到SAI，作为各自自的标杆

26. 实践一一：统一一的架构度量量标准SAI（续三） SAI 2.x 面面临的问题和挑战 • 服务化、组件化架构深入应用，如何度量各种不同的架构风格？ • 市场压力，迫使产品呼唤架构全面解耦，如何提供更完善的解耦度量，如，自研产品-开源解耦性？ • 更精准地度量架构 • 更精确地识别架构问题所在位置、层级及其影响，聚焦架构级问题 • 新型语言的产品越来越多，技术栈日益丰富，要求纳入度量 • 现有SAI度量和坏味道识别能力有限，部分产品SAI改进接近极限，如何牵引产品继续改进架构？ • ……

27. 实践一一：统一一的架构度量量标准SAI（续四） SAI 3.0 改进部分思路路 • （解决多种架构风格的准确度量）为服务化、组件化、单体架构，分别设置不同的度量指标集 • （为更多新兴编程语言提供度量支持）支持Ruby、JavaScript、Python、GO，不同语言，指标不同 • （更精准、更多角度地架构度量指标及问题的影响范围）将架构分为多个层次，设置相应的指标，关注点分离系统子系统组件模块文件函数/类

28. 实践一一：统一一的架构度量量标准SAI（续五） SAI 3.0部分指标示意架构度量指标指标名称所属SAI版本需求来源指标版本号上一版本号标准更新时间指标启用时间更新人指标定义&说明指标图示度量方案&算法重构建议实际案例社区讨论已知标准缺陷

29. 实践一一：统一一的架构度量量标准SAI（续六）基于问题的SAI 指标引入入方方法: 举例例 1. 根据团队反馈或架构审视，发现实际架构问题或标准缺陷（如，实际产品中某些服务、组件职责过于分散）指标名称：服务/组件功能不不单一一定义：外部调用用服务/组件时，被调用用的接口口可以分为两个以上互补相关的功能簇。版本：V1.0 所属标准：SAI 3.0 2. 思考，讨论，结合架构原理与实践经验，确定牵引方向（如，应牵引服务或组件尽可能执行单一职责，权重较高） 3. 绘制坏味道的架构图示（如右图） 4. 设计架构度量方案、算法及阈值等（略） 5. 设计指标 6. 试点，根据反馈和实际情况，调整指标定义、算法或阈值等 7. 将指标纳入SAI指标体系基于架构原理理的SAI 指标定义方方法: 略略注：不不同颜色色表明服务/组件内部实现(文文件粒度)间不不存在耦合（调用用或数据访问等）重构建议：将组件中互不不耦合的部分切分为（或划归）多个组件

30. 实践二二：架构质量量报告 SAIReport: 产品架构质量量仪表盘（星级、SAI、坏味道）及趋势一一目目了了然 SAI趋势、基线、各均值等 SAI及质量量星级架构属性得分架构要素得分架构坏味道加权得分，点击可进入入具体的坏味道列列表，含问题代码

31. ŉ㪗㩥⛐岧◷㧪㉩Ⰸ䥥ⱞ⯥猳▁⃡ℋ⃽屠浍⃫力叞䧬ⓛ獍㧪↡℩⃮⛩拣䥥猾浍⃫力⛐⇆㚱ⓛ㩆猾㡕㠚猳䠉恘㩆㉩㢚⊠猾⛐⇆⻚䢨⃬噐ּⱣ㩽㺰实践三：可定制的集成架构视图 ℋ㪗㩥ラ揞㙭㛂Ⅷ抺ℋ㕡叞猾厐⹻⇻⨉㠩䙨⃫㧪㉩Ⰸ䥥ⱞ⯥ּ ロ㧼叞Ⰰ㠐㗢㴂⨸冈匇⛩䥥⛐岧◷ּ拻抨㡑㙏廾䰛猾浒▉㇡⚲↛✹㕫⹤ 㡕㠚ֻ⇹◷ּň ŃŃ㪱䫵⚲⧃椀NGCFGT SAIVisualizer: 产品架构划分及其依赖、违约等，分层，可视，可定制，可导出 • 可凸显、展开选中组件的部件和依赖 • 可直接定位到接口、文件、包、代码...... • 可按需要自由组合 • 可在界面直接创建/编辑/取消架构规则 • ……

32. 实践四：模型驱动的构建 MDBEngine：颠覆大大规模软件开发的构建工工程活动模式理理想的架构设计，可现状：手工编写编译构建脚本；专人或各自维护；发现问题，人工调优愿景一：构建工程模型化、可视化，让开发团队彻底摆脱手工维护编译构建工程的低效和困扰。由诸多架构视图的相似的循环迭代构成构建度量量&看护 (再)设计构建模型逆向生生成构建模型生生成构建脚本(框架) 手手工工完善构建脚本执行行行编译构建自自动/人人工工构建调优关键技术：构建视图、构建模型定义，构建模型可视化，构建脚本自动生成，构建模型的逆向生成，构建工程度量模型及标准……

33. 某产品试点扫描并消除实践四：模型驱动的构建（续）构建坏味道，一一个多月月 MDBEngine：颠覆大大规模软件开发的构建工工程活动模式现状：大规模、长周期的软件的编译构建工程，往往存在大量缺陷，导致构建效率低下，且难以维护构建(反)模式，包括：弹匣模式，模板模式，策略模式、构建器模式、标志外置模式等，可用于指导构建模型的设计与脚本开发/维护举例例：模板构建模式，大大多数模块的构建脚本都很相似，脚本代码重复 GenBuilder +CopyAndFill GenBuilderA 50%！编译构建耗时减少25%！愿景二：高效的编译构建；构建工程易维护 Client 后，编译服务器器减少 GenBuilderB 构建坏味道，包括重复构建，废弃构建脚本，冗余文件，过深构建链，单一构建规模过大，多用途，散弹式构建，循环构建链，等，是构建视图的度量与重构的基础举例例：散弹式构建，一一个组件的编译链接，用用到大大量量其他组件目目录下的文文件

34. 实践五：组件化架构辅助重构 Componentizer：获得/恢复破坏的组件化架构现状：大多数的组件的初始设计无迹可寻，实现则面目前非。如何恢复或理顺已被“破坏”的组件化架构？方法之一：以组件聚类算法的结果为目标，开展重构 1. 设定组件化架构重构目标 2. 针对现有代码，开展架构度量，得到组件化架构度量指标 3. 组件化架构目标是否达成？ 4. 扫描代码，进行组件聚类分析 5. 以组件聚类分析结果为目标，策划并实施重构 6. 反复上述2~5，直至团队对重构效果和指标感到满意开发团队逆向思维的自自主创新

35. 架构自自动化度量量与演进在研发流程中的定位软件架构自自动化度量量、看护与演进需求分析与设计编码实现 Codebase 编译构建 Commits 测试&验证 Bug reports 部署&运行行行 Logs

36. 已在华为所有主力力力产品全面面应用用 130+ 产品 400+ 版本 17年年公司SAI平均提升 14.5%

37. 为研发效率提升提供了了支支持

38. 产品的认可 • 当前SAI对促进产品架构改进起了了很大大的作用用。17年年针对性地做了了部分改进，架构度量量工工具起到了了作用用……明年年重点优化…… • ……各PDU基本上都反馈对于架构解耦活动的开展有比比较好的牵引和指导作用用……已在12月月研发 ST上汇报，SAI在……例例行行行度量量可视化已获得认可……优化建议：…… • 从我的⻆角度看，不不可能一一把都搞定，度量量准确性还好。关键是有这个旗帜在，可以推动产品持续改进、优化…… • 随着SAI推行行行三年年下来，产品都有了了很大大的改进。如何持续SAI的牵引性？…… • SAI指数很好，度量量很全面面……能否呈现得更更立立体一一点，给出具体改进方方向，帮助辅助决策……

39. 架构自自动化度量量与演进推行行行·关键成功要素挖掘用用户需求 • 用用户支支持 • 产品用用户访谈 • 问卷调查 • 用用户社区度量量工工具使能设定公司战略略 • • 发布统一一的架构度量量标准 • 明确公司架构战略略 • 高高层汇报与沟通 • 牵引产品自自我改进 UADP ArchGuarding 跨领域专家组织支支撑技术及工工程应用用组合创新 • 跨领域软件分析与度量量技术组 • • 国际会议技术研究与合作

40. 一一直在思考...... 为何软件开发总是“996”？

41. 一一直在思考...... 为何没有“银弹”？

42. 软件规模一一直在迅速增⻓长

43. ……加速增⻓长 Volvo Downloadable SW Size 1000 917 500 250 117.5 V7 0 97 20.6 18.6 10.9 4.9 1.5 750

44. ……普遍增⻓长美国国防部新开发及维护代码的增⻓长率为约15~25% March,2017，“Software Productivity Trends and Issues”

45. ……生生产率的增⻓长却非非常有限 4% March,2017，“Software Productivity Trends and Issues”

46. 糟糕：生生产率会随规模增⻓长而而大大幅下滑！

47. 架构腐化是⻓长期的、不不可逆转的趋势 • 软件规模的持续增⻓长，本质是业务复杂度的增⻓长，是软件“吞噬世界”的必然结果 • 不不断遭到侵蚀和腐化的架构，使得软件维护成为一一场负重行行行军

48. (微)服务化、组件化固然好！代价是……运行行行期的复杂性和巨大大的不不确定性㿉獌⃫拑㡑㙏㜹哋䙬☤䱆勢ラ㨱㡺猾ㅗ⌻⭿孆 ň⓼持㌈Ⱂ䍖㤐䀜俜净䥥㫨㊸ּ⻜㹜㉩榟猾∧⻝哕㹜ↂ䥥惐♕㧪㣁㡑㩂ŉ ŃŃ--‫Ⱂ׃‬㚈ׄ

49. “午餐”收费理理由 • 匇⛩⃮䍎⹻㉬獌ň⹿∴棕匇⛩Ᵽ㩽⸹⨉猾⃮⇻⧁⇜∶⚀⧁勭䁩Ⱂŉ猾䙬㺦猾 ň匇⛩⃮㹜猾⛋㤐㙃䲮㢚ㇰ㕹呟≁ŉ猾✕㡨厽 • ⯮㨣ㆇ拳⭿䗽㏔獌ň扐⇗䥥⑦䱡⯮㨣ㆇ楰㣗棕拳⭿ŉ猾✕㡨厽猾` ⑦䱡⯮㨣ㆇ獌㔡㧪⛐峄匇䥥⚹◷揞嚘㉸峄匇䥥䛧㏔㎦⒖⃬猾扐⇗㪗㩥ℎ樺㋢挜扲惐㉥㡑ℬ❭ • ⯮㨣ㆇ⹩㌳⹻㉬獌ň峄匇猾◦㗍废庂㴂ㇰֻ㪗㩥㴂ㇰ殯㬝个㕡㨐䥥ㅵ䠉猾⛋叞ㄇ㩆扐⇗⯮㨣ㆇ䥥椮凕猺♔恬抲⑦䱡⯮㨣ㆇ猻㓷⚲䠀㣗棕㓷㉃㋢䥥才䳜猾ㅗ⃮叞⻝哕⯮㨣ㆇ䥥椮∯ŉ猾✕㡨厽猾` • ň扐⇗力⎰䒖猾㉩榟㙭㛂⃵㣁㾶䳑撰猾勭⃵猾抹捖⹩䏎╼⹇不Ⅽ⹻㉬猾⅀力㤐廕獌⹤=䥥⯮㨣ㆇ?㌜㤐⇻⭿▁ŉ猾0 14/#0 # 7)756+0'

50. 人人的智力力力是有上限和局限的 “…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

51. 软件的未来有个大大难题银没弹变化加快 ! 规模增大大复杂度增加腐化趋重效率下滑有

52. 每个解决方方案都会带来更更多更更复杂的问题

53. 改变是必须的……

54. 走走向自自动化、智能化，是未来软件工工程的必然选择！ “人类无法继续用手工方式应对未来软件开发的规模和复杂性挑战” M.L. Albort， M.T. Fisher《架构真经》

55. 脚下之路路：“架构演进+特性开发”双甬道模式需求自动化分析模型驱动的构建回归测试技术视图分析-平台选择&定制&开发 “自然选择只是利用微细的、连续的变异而发生作用；她从来不能采取巨大而突然的飞跃，而一定是以短的、确实的、虽然是缓慢的步骤前进。” 达尔文，物种起源

56. 脚下之路路：基于度量量的多视图迭代敏敏捷软件工工程 ō ō ō ō ō ō ō ō ō 挜扲岧⧟ ⇄䫢岧⧟ 㩥㇛岧⧟ 揉剓岧⧟ 抱嬭岧⧟ 䕚㌈岧⧟ 䀬庶岧⧟ 㕡㨐岧⧟ ŎŎ

57. 脚下之路路：近期技术发展路路线图架构工具外部开源 E2E构建工程自动化架构智能演进智能架构工程架构工具内部开源研究架构演进目标 &需求研究架构自动重构架构演进完善构建脚本自动生成技术构建坏味道自动调优研究坏味道辅助重构架构度量&看护研究特性解耦标准支持架构全面解耦的SAI 完善构建视图度量标准建立运行视图度量标准架构模型&视图优化线框图展示建立技术视图解耦标准完善代码视图试点应用债务视图架构恢复依赖分析完善热点视图研究特性视图恢复完善构建视图恢复从研发数据挖掘架构依赖全景图研究运行视图恢复 DSM工程化呈现研究部署视图恢复研究测试视图恢复研究技术视图恢复架构全视图

58. 未来之路路：f(AI, 人人机交互, …)=从局部重构到软件智能化演进智能化生态演进智能化软件演进智能辅助服务/组件演进智能辅助方面演进智能辅助架构重构䫢⑽ 䫢テ䫢䰿抨⚜^㔬テ㈴⃬^哋▉ 㨋㩆^㥛叞 ☯ℛ抹⨉抺播猳

59. 求：同道、加盟、合作谢谢！㐀弃獌㊸焰猾⧞牺猾椠㫨猾㓩☻猾椠怃ㅕ㩆䥥㩑ⓛテ∽❭燯╼㠐㗢猳㐀弃㔡㧪䥥⛩∽⇺∕猳㓲⇍⃡恘䠉㼸㼕❭㥛㑈弒⑺Ⅷ⃡㧓∀Ⰸ䥥亨䷁猳猳猳 ✕㡨厽 YWYGPUJGPI"JWCYGKEQO ㊏⋂獌YYU