架构设计与技术选型学习路线

定位：从"能实现别人设计的架构"到"能主导架构设计并对后果负责"的方向。
适用对象：3～6 年 Android/移动开发，希望往架构师方向纵向发展。
抗替代性逻辑：架构设计的核心是"在不完整信息下做权衡并承担后果"，AI 可以列出选项和优缺点，但不能替你承担选错的责任，这是本方向抗替代的根本原因。
与仓库关联：本文是聚焦"架构设计与技术选型"这一单点能力的精简路线，更全面的架构师综合能力（含性能、稳定性、工程效能、领导力）见 ../Android高级架构师学习路线.md。

一、为什么"架构设计"和"写代码"是两种不同的能力

写代码：给定方案，把它正确实现
架构设计：在多个不完整、有冲突的方案里，选一个并说明为什么

前者有标准答案（AI 擅长），后者没有标准答案（AI 擅长列举，不擅长拍板）

架构师的核心产出不是代码，而是 决策 + 决策理由 + 决策后果的责任承担。

二、能力地图

三、学习路线总览（建议 8～12 个月）

阶段 0：架构模式的本质理解              → 1～1.5 月
阶段 1：系统分解与模块化实战            → 2 月
阶段 2：技术选型方法论                  → 1.5 月
阶段 3：架构文档与决策记录（ADR）       → 1 月
阶段 4：架构评审实战                    → 1.5 月
阶段 5：架构演进与治理                  → 2 月
阶段 6：项目化与影响力建立              → 持续

四、阶段 0：架构模式的本质理解（1～1.5 月）

4.1 不要死记模式定义，要理解模式解决的问题

4.2 训练方法：给定场景，判断该用什么模式

练习示例：
- 一个纯展示型 5 屏小工具 App → 用什么？为什么不需要 Clean Architecture？
- 一个有复杂状态机的直播间互动页面 → 用 MVI 而非 MVVM 的理由是什么？
- 一个多数据源、长期迭代的电商 App → Clean Architecture 值得吗？

4.3 阶段产出

• [ ] 写一份《架构模式决策树》：给定业务特征，推导该用什么模式
• [ ] 能对着任意一个开源项目，评价它的架构选择是否合理

五、阶段 1：系统分解与模块化实战（2 月）

5.1 模块化的本质

模块化不是"拆文件夹"，而是"用编译边界强制约束依赖方向"
目的：让一个改动的影响范围可预测、可控制

5.2 典型分层结构

app（壳工程，只做组装）
  ├── feature-x / feature-y（业务模块，互不依赖）
  ├── business-api（业务对外契约，interface only）
  ├── lib-network / lib-ui / lib-account（基础能力）
  └── build-logic（Gradle 统一约定）

依赖原则：
✅ 上层依赖下层
✅ feature 之间通过 business-api 通信，不直接依赖
✅ 基础库暴露稳定 API，内部实现可替换
❌ 反向依赖、循环依赖

5.3 实战练习

1. 找一个单体 App（自己的项目或开源项目），画出当前模块/类的依赖关系图
2. 设计一版目标模块化方案，标注每个模块的职责边界
3. 制定迁移计划：分几个阶段迁移，每个阶段的验证标准是什么
4. 写一份《模块接口设计规范》：模块间通信只能怎么做，不能怎么做

5.4 阶段产出

• [ ] 完成一次真实或模拟项目的模块化拆分方案设计
• [ ] 写出《模块依赖治理规范》，包含允许/禁止的依赖方式

六、阶段 2：技术选型方法论（1.5 月）

6.1 结构化评估框架（避免"凭感觉选"）

面对任何技术选型，按以下维度打分（1~5分）：

1. 解决核心问题的匹配度
2. 团队现有能力与学习成本
3. 社区/官方长期维护的可能性
4. 对构建、包体、性能的影响
5. 退出成本（如果选错了，换掉的代价多大）
6. 与现有架构的兼容性
7. 是否有类似规模的成功案例可参考

6.2 案例训练（针对 Android 常见选型）

6.3 阶段产出

• [ ] 用结构化框架，对一次真实选型决策打分并写出结论
• [ ] 写 2 篇《技术选型对比报告》，包含备选方案、打分、最终决策理由

七、阶段 3：架构文档与决策记录 ADR（1 月）

7.1 ADR（Architecture Decision Record）模板

标题：ADR-00X [决策主题]

背景（Context）：
- 为什么需要做这个决策，当前面临什么问题

决策（Decision）：
- 最终选择的方案是什么

备选方案（Alternatives Considered）：
- 列出至少 2 个被否决的方案及否决理由

代价（Consequences）：
- 这个决策带来的正面收益和负面代价分别是什么

回滚方案（Rollback）：
- 如果这个决策后来证明是错的，怎么退回

7.2 为什么 ADR 是架构师的核心资产

没有 ADR：决策全靠口头传承，人一走方案就没人知道为什么这么设计
有 ADR：新人能看历史决策，避免"重新踩一遍坑"，也是你个人能力的书面证明

7.3 阶段产出

• [ ] 完成 3 篇高质量 ADR（真实项目或复盘历史决策）
• [ ] 建立团队/个人的 ADR 归档习惯

八、阶段 4：架构评审实战（1.5 月）

8.1 一次好的架构评审应该问什么

1. 这个方案解决的核心问题是什么？不用这个方案会怎样？
2. 有没有更简单的方案？为什么不用？
3. 这个方案对现有系统/团队的影响范围有多大？
4. 极端情况（高并发/异常/边界）下会怎样？
5. 如果 3 年后业务规模扩大 3 倍，这个方案还撑得住吗？
6. 如果这个方案错了，多久能发现？代价多大？怎么回滚？

8.2 练习方式

1. 找一份公开的技术方案文档（或自己项目的历史方案）
2. 用上面 6 个问题逐一提问并写下答案
3. 模拟评审会，邀请同事对你的方案做同样的提问
4. 复盘：哪些问题当时没想到，说明什么能力短板

8.3 阶段产出

• [ ] 主导或参与至少 2 次真实架构评审
• [ ] 整理一份《架构评审检查清单》，可复用于未来评审

九、阶段 5：架构演进与治理（2 月）

9.1 架构不是一次性设计，而是持续演进

常见误区：追求"一次性完美架构"
正确认知：架构要能在业务不确定的情况下，以可控代价演进

演进能力体现在：
- 预留扩展点而不过度设计
- 技术债可见、可量化、可分阶段偿还
- 重大重构前有充分的影响面评估

9.2 技术债治理方法论

1. 建立技术债清单（不是模糊的"代码不好"，要具体到模块/问题）
2. 量化影响：构建耗时、Bug 率、开发效率、招聘难度等
3. 排优先级：影响面大 + 修复成本低的优先处理
4. 争取时间：用数据说服业务方给技术债处理的排期
5. 分阶段处理：避免"大重构长期不可用"的风险

9.3 评估重构 ROI 的框架

重构成本 = 开发时间 + 测试验证时间 + 风险（可能引入新 Bug）
重构收益 = 效率提升 + 故障率下降 + 后续开发速度提升
只有收益明显大于成本，且团队能承受迁移期风险，才值得做

9.4 阶段产出

• [ ] 写一份《技术债清单与治理计划》（真实或模拟项目）
• [ ] 完成一次"评估某个重构是否值得做"的分析报告

十、阶段 6：项目化与影响力建立（持续）

10.1 架构师影响力的来源

不是职级给的，而是：
- 你的方案被反复验证是对的
- 你的评审提问总能提前发现风险
- 遇到架构级问题，同事第一反应是找你讨论

10.2 建议的产出节奏

10.3 简历/面试表述框架

不要写：「负责 App 架构设计」
要写：
「主导 XX App 模块化重构，将单体架构拆分为 8 个业务模块 + 3 个基础库，
建立模块依赖治理规范，将平均编译耗时从 XX 分钟降至 XX 分钟，
新功能并行开发冲突率下降 XX%。」

十一、能力自检清单（22 项）

打勾 ≥ 16 项，可视为具备独立架构决策能力：

判断力

• [ ] 能根据业务场景推导该用什么架构模式，而非死记定义
• [ ] 能评价一个开源项目架构选择的合理性
• [ ] 独立完成过至少 1 次真实模块化拆分方案

方法论

• [ ] 使用结构化框架做过至少 2 次技术选型决策
• [ ] 写过至少 3 篇高质量 ADR
• [ ] 建立过模块依赖治理规范

评审能力

• [ ] 主导或参与过至少 2 次真实架构评审
• [ ] 有自己的架构评审检查清单
• [ ] 能提前发现方案里的边界/极端情况风险

治理与演进

• [ ] 写过技术债清单并推动过至少 1 项治理
• [ ] 完成过重构 ROI 评估分析
• [ ] 理解如何在不确定业务下预留合理扩展点

影响力

• [ ] 有同事主动找你讨论架构问题
• [ ] 做过至少 1 次架构/选型相关技术分享
• [ ] 简历上有可量化的架构改进数据

软技能

• [ ] 能清晰表达一个决策的备选方案与否决理由
• [ ] 能承认并复盘一次自己选错的技术决策

十二、常见误区

十三、最短路径

1. 建立架构模式决策树，理解各模式解决什么问题（1个月）
2. 完成一次真实/模拟项目模块化拆分方案（2个月）
3. 用结构化框架做 2 次技术选型并写报告（1.5个月）
4. 写 3 篇 ADR + 主导 1 次架构评审（2个月）
5. 输出 1 份技术债治理计划或重构 ROI 分析（持续）

一句话总结：

架构设计能力的护城河不是"知道更多模式名词"，而是"在不完整信息下做权衡决策、并对后果负责"的能力，这正是 AI 能建议但不能替你承担的部分。

十四、关联文档

• ../Android高级架构师学习路线.md — 更全面的架构师综合能力路线（含性能/稳定性/工程效能/领导力）
• ../Android移动开发方向抗替代性与薪酬分析.md — 本方向的替代率与薪酬定位
• ../十年以上Android开发面试问题.md — 架构相关面试题