CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
软件架构师入门/课时/治理与方法论
RawBlame
课时目录12 节

软件架构师入门

  1. 01软件架构是什么
  2. 02架构师软技能
  3. 03设计模式与原则
  4. 04架构风格
  5. 05数据架构
  6. 06API 与集成
  7. 07安全架构
  8. 08云与设计模式
  9. 09网络基础
  10. 10技术栈选型
  11. 11治理与方法论
  12. 12综合练习

治理与方法论

TOGAF、Scrum、ITIL。

30 分钟

治理与方法论

这一课你将能做到

  1. 说清楚 TOGAF 的 ADM 循环在中小团队如何裁剪落地
  2. 为本站设计一套轻量架构治理机制:评审清单 + ADR 流程 + 技术债台账
  3. 解释 Scrum、Kanban、SAFe 各自的适用团队规模,并为本站 15 人团队做选择

为什么要学

架构不是设计出来就完事的——代码会腐化、团队会扩张、边界会模糊。没有治理机制,再漂亮的架构图一年后都会变成「文档里的架构」和「实际跑的架构」两张皮。

人话:治理就是给架构装「物业」。房子是设计建出来的,但没有物业管:乱搭乱建(随意加依赖)、管道老化(技术债)、违章改造(绕过架构规范),三年后小区没法住人。

先建立图像

架构治理的三层体系:

┌─────────────────────────────────────────┐
│ 战略层:技术雷达 / 架构原则                 │
│ 「我们不用闭源中间件」「数据不出私有云」      │
├─────────────────────────────────────────┤
│ 机制层:评审 + ADR + 技术债台账            │
│ 新服务准入 checklist / 重大决策留痕        │
├─────────────────────────────────────────┤
│ 工具层:架构适应度函数(Fitness Function)  │
│ ArchUnit 校验分层 / 依赖扫描 / 契约测试     │
└─────────────────────────────────────────┘

跟着做

步骤 1:TOGAF ADM 的中小团队裁剪

完整 ADM 有 8 个阶段,本站裁剪为四步循环:

原版 ADM: A架构愿景→B业务架构→C信息系统架构→D技术架构
         →E机会方案→F迁移规划→G实施治理→H变更管理

本站裁剪版(每季度一轮):
1. 愿景对齐(半天):本季度业务目标 → 架构要支撑什么
2. 现状盘点(1 天):架构图更新 + 技术债台账复审
3. 差距与方案(2 天):列出差距 → 排序 → 排进迭代
4. 实施守护(持续):PR 里 ArchUnit 自动校验 + 月度评审

步骤 2:用 ArchUnit 把架构规范变成代码

治理不能只靠自觉,要让规范在 CI 里自动执行:

@AnalyzeClasses(packages = "com.coderoadmap")
class ArchitectureTest {

    // 分层规则:Controller 不许直接访问 DAO
    @ArchTest
    static final ArchRule layered = layeredArchitecture()
        .consideringAllDependencies()
        .layer("Controller").definedBy("..controller..")
        .layer("Service").definedBy("..service..")
        .layer("Dao").definedBy("..dao..")
        .whereLayer("Controller").mayNotBeAccessedByAnyLayer()
        .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
        .whereLayer("Dao").mayOnlyBeAccessedByLayers("Service");

    // 领域规则:领域层不许依赖 Spring(保持纯净)
    @ArchTest
    static final ArchRule domainPure = noClasses()
        .that().resideInAPackage("..domain..")
        .should().dependOnClassesThat()
        .resideInAPackage("org.springframework..");
}

PR 违反规则 → CI 直接失败。规范从「文档里的建议」变成「过不去的门禁」。

步骤 3:技术债台账管理

| 编号 | 债务 | 引入原因 | 利息(不还的代价) | 本金(偿还成本) | 优先级 |
|------|------|---------|------------------|----------------|--------|
| TD-01 | 订单模块未拆服务 | 当初赶上线 | 每次发布全量回归,30min→2h | 3 人周 | 高 |
| TD-02 | 课程表缺索引 | 早期数据少无感 | 慢查询已出现 3 次 | 0.5 人天 | 高 |
| TD-03 | 前端还在用旧组件库 | 历史遗留 | 新需求开发慢 20% | 5 人周 | 中 |
| TD-04 | 单点 Redis 无哨兵 | 省钱 | 挂了就全站缓存失效 | 1 人周 | 高 |

规则:每个迭代固定 20% 容量还债,优先还「利息高、本金低」的。

讲清楚要点

  1. 治理的目标是一致性,不是完美:十个服务用同一种「够用」的模式,胜过十个服务各自「最优」。认知一致性让小团队维护大系统成为可能。
  2. ADR + 自动化校验是治理的最小可行组合:ADR 管「为什么这么决策」,ArchUnit/契约测试管「规则是否被遵守」。两者成本极低,收益极大。
  3. 敏捷方法论按团队规模选:5 人以下 Kanban(流程最轻);5-30 人 Scrum(节奏感强);跨多团队大型组织才考虑 SAFe。框架是工具,站会开了三周没价值就砍掉。
  4. 技术债是金融工具不是耻辱:为了赶上线窗口主动借债是合理商业决策,关键是有台账、有计划还。失控的不是借债,是不知道自己欠了多少。
  5. 企业框架(TOGAF/ITIL/PRINCE2)学思想不学形式:小团队不需要 TOGAF 全套文档,但「愿景→现状→差距→迁移」的思考闭环值得每个架构师内化。

你可能会懵的地方

  • 治理会不会降低团队效率? 好的治理减少的是「不一致带来的隐性沟通成本」。新服务准入 checklist 看似多一道手续,实际上避免了「又有人引入一个新 MQ 中间件」的运维灾难。判断标准:治理项是否自动化(自动化的没负担),是否解决过真实事故。

  • Scrum 和 Kanban 核心区别? Scrum 有固定迭代(Sprint)和角色(PO/SM),强调承诺和节奏;Kanban 没有迭代,强调流动和限制在制品(WIP)。需求变化剧烈的团队(本站早期)适合 Kanban;需要可预测交付节奏的适合 Scrum。

  • SAFe 为什么争议大? SAFe 试图把敏捷扩展到几百人组织,但引入了繁重的角色和流程,常被批评为「披着敏捷外衣的瀑布」。只有真正多团队依赖复杂的大组织(车企、银行)才值得评估,而且落地需要专业顾问。

  • 架构评审委员会(ARB)怎么不变成官僚机构? 三条原则:评审基于公开的清单(不是评委个人好恶)、提供自助通道(清单内绿灯事项不用上会)、例会制而非随叫随审。评审输出必须是「通过/有条件通过/拒绝+理由」,而不是漫谈。

  • SAP/Salesforce 这类企业平台和架构师什么关系? 大中企业里 ERP/CRM 平台是架构的重要约束:定制开发的边界、数据集成模式(IDoc/API/CDC)、升级策略都需要架构师参与。原则:平台能力优先配置而非定制,定制代码隔离在防腐层后面。

错法对照

错法问题正解
治理全靠文档和口头约定三个月后无人记得、新人无知违反ArchUnit 等自动化校验进 CI
技术债只记录不偿还台账变成墓碑列表每迭代固定 20% 容量,高利息优先
为 5 人团队上 SAFe流程开销超过产出5 人 Kanban,15 人 Scrum 足够
架构原则定成口号(「高内聚低耦合」)无法执行和验证原则要可校验:「领域层不依赖框架」
大爆炸式重构还债业务停摆数月,风险极高绞杀者模式逐步替换,持续交付价值

卡点急救

  1. 团队绕过评审直接上线:不要先追责,先看流程——是不是评审周期太长(超过 2 天就是流程问题)?把评审改成异步(PR + 24 小时静默期),重审必要性。
  2. 技术债排期永远被业务需求挤掉:把债务翻译成业务语言汇报(「不还 TD-04,Redis 挂了全站课程页 500,预计每月发生 1 次」),并争取「每迭代 20%」的明文约定。
  3. ADR 写了没人看:把 ADR 链接放进相关代码包的 README 和架构图注释里;新人 Onboarding 清单里列「必读 ADR Top 5」。

面试常问

  • 什么是技术债?怎么管理? 定义:为了短期交付速度而做的、已知会增加未来成本的技术妥协。分类:有意 prudent(赶窗口主动借)、有意 reckless(懒得做好)、无意(当初认知不足)。管理四步:1) 台账可见(记录本金和利息);2) 翻译业务语言向管理层汇报;3) 固定容量偿还(每迭代 15-20%);4) 新债准入评审(新债必须有偿还计划)。金句:「技术债失控的标志不是欠得多,而是没人知道欠了多少。」

  • 怎么保证架构设计在开发过程中不走样? 三层答:1) 代码层:ArchUnit 分层校验、契约测试(Spring Cloud Contract)进 CI;2) 流程层:ADR 决策留痕、架构评审、设计文档模板;3) 度量层:适应度函数监控关键指标(耦合度、循环依赖数),趋势劣化时预警。核心思想:把架构约束从「人的记忆」转移到「机器的校验」。

  • Scrum 在实际落地中最常变形的是什么? 三个典型变形:1) 站会变成汇报会(应该同步障碍,不是向领导汇报);2) Sprint 内随意加需求(破坏承诺,需要 PO 守门);3) 回顾会流于形式(改进项无人跟进,下次还犯)。补充:成熟的团队往往会从 Scrum 演化到 Kanban——仪式做减法,流动做加法。

自测三问

  1. 本站的「新服务准入 checklist」应该包含哪 5 项?
  2. 技术债的「本金」和「利息」分别指什么?为什么优先还高利息低本金的?
  3. 为什么 ArchUnit 比架构文档更能保证架构不走样?

小结一句话

架构治理的本质是把一致性从「靠自觉」变成「靠机制」:原则要可校验、决策要留痕、债务要有台账、流程要匹配团队规模。

延伸

  • 《演进式架构》(Building Evolutionary Architectures)——适应度函数思想来源
  • TOGAF Standard 10(官网免费版,看 ADM 章节即可)
  • 《Scrum 敏捷软件开发》(Mike Cohn)
  • 下一课:综合练习——为本站设计课程推荐服务,输出完整架构文档。
加载本节练习…
← 上一课技术栈选型下一课 →综合练习