管好技术债：低摩擦软件开发之道

　　随着软件系统越来越复杂，在预算或开发进度受到约束的背景下早期做出的设计或代码决策到后期会阻碍系统的演化和创新。这种现象被称为技术债务，而对此的解决之道早已有之。在《管好技术债：低摩擦软件开发之道》一书中，三位行业顶尖的专家介绍了从经验中总结的开发原则和实践，任何软件专业人员都可以运用这些原则和实践来管理软件系统中的技术债务。本书讲述了在软件研发过程中，如何对技术债务的全生命周期进行管理，内容涵盖技术债务的方方面面，包括技术债务的定义与识别，技术债务在源代码与架构等不同抽象层次上的表现，技术债务的成本计算与偿还策略，以及在什么情况下，与技术债务共存是一个可以接受的选择等。书中也提出了具体的可供实践的理论与方法，让软件研发人员能将技术债务管理与整个软件研发的工作结合起来，从而通过管理技术债务给软件研发带来切切实实的收益。本书适合参与软件研发工作的开发者、管理者、架构师，以及对技术债务感兴趣的读者阅读。对于每一位想要加速现有系统的创新或建立更容易维护和演进的新系统的软件专业人员来说，《管好技术债：低摩擦软件开发之道》都是一本极具参考价值的书。

　　Philippe Kruchten是加拿大温哥华不列颠哥伦比亚大学软件工程教授。他从事工业界近30年的职业生涯后于2004年加入学界。在工业界，他主要从事电信、国防、航空航天和交通领域的大型软件密集系统设计工作。他在软件开发方面的经验体现在Rational Unified Process（RUP）中，他从1995年到2003年担任该项目的负责人。他是《Rational Unified Process： An Introduction》（Addison-Wesley，1998）、《RUP Made Easy： A Practitioner's Guide》（Addison-Wesley，2003）和《Software Engineering with UPEDU》（Addison-Wesley，2003）等书籍的作者或合著者，还撰写了关于Pascal和Ada编程的早期书籍。他获得了法国工程学院信息系统学博士学位（1986年）和机械工程学位（1975年）。Robert Nord是卡内基梅隆大学软件工程研究所的主要研究员，致力于开发和传播规模化敏捷、软件架构和管理技术债务的有效方法和实践。他是面向实践者的书籍《Applied Software Architecture》（Addison-Wesley，2000）和《Documenting Software Architectures： Views and Beyond》（Addison-Wesley，2011）的合著者，并讲授与架构中心方法相关的课程。他在卡内基梅隆大学获得计算机科学博士学位，并是ACM的杰出会员。Ipek Ozkaya是卡内基梅隆大学软件工程研究所的主要研究员。她的主要工作包括开发提高软件开发效率和系统演化技术，重点关注软件架构实践、软件经济学、敏捷开发和管理复杂大规模软件密集系统的技术债务。此外，作为她的职责的一部分，她与政府和工业组织合作，改进他们的软件架构实践。她在卡内基梅隆大学获得计算设计博士学位。Ozkaya是IEEE的高级会员，也是2019-2021年《IEEE Software》杂志的主编。冯文辉，现任ThoughtWorks中国区资深架构咨询师，具有11年的软件行业经验，曾服务于多个世界500强企业，覆盖银行、保险、通信、汽车、物流等行业。为客户提供敏捷开发、DevOps、架构设计与数字化转型等咨询服务。热衷于探索更好的架构设计方法，助力企业的数字化转型。译有《SRE生存指南：系统中断响应与正常运行时间最大化》。

第1部分 探索技术债务全景 1
第1章 软件开发中的摩擦 2
管理技术债务的价值 2
关于技术债务 4
技术债务示例 5
你的技术债务如何 10
本书适合谁 11
技术债务管理原则 11
本书概念导航 13
今天能做点什么 15
扩展阅读 15
第2章 什么是技术债务 16
框定讨论的范围 16
技术债务全景 17
技术债务项：工件、原因和后果 19
本金与利息 20
成本与价值 23
潜在债务与实际债务 27
技术债务时间线 28
今天能做点什么 31
扩展阅读 31
第3章 土星的卫星——关键的上下文 33
视情况而定 33
三个案例：土星的卫星 35
上下文中的技术债务 39
今天能做点什么 42
扩展阅读 42

第2部分 分析技术债务 45
第4章 识别技术债务 46
哪里感到疼痛 46
技术债务的可见后果是什么 48
撰写一份技术债务描述 50
理解评估技术债务的业务上下文 52
评估技术债务上下文中的工件 54
今天能做点什么 56
扩展阅读 57
第5章 技术债务与源代码 58
寻找魔杖 58
了解关键业务目标 61
识别源代码问题 62
定义可观察的度量标准 64
选择并应用一个分析工具 66
记录技术债务项 67
迭代 69
下一步发生什么 69
今天能做点什么 70
扩展阅读 71
第6章 技术债务与架构 72
超越代码 72
询问设计者 75
研究架构 77
检查代码，以深入了解架构 80
Phoebe项目架构中的技术债务案例 82
今天能做点什么 87
扩展阅读 87
第7章 技术债务与生产环境 89
超越架构、设计和代码 89
构建与集成的技术债务 92
测试技术债务 94
基础设施技术债务 95
Phoebe生产环境中的技术债务案例 96
今天能做点什么 98
扩展阅读 98

第3部分 决定修复什么技术债务 99
第8章 技术债务的成本计算 100
将经济焦点放在技术债务上 100
细化技术债务描述 102
计算补救成本 103
计算经常性利息 104
比较成本与收益 105
集中管理技术债务项 108
今天能做点什么 110
扩展阅读 111
第9章 偿还技术债务 112
权衡成本与收益 112
偿还技术债务的途径 117
发布流水线 121
将技术债务作为投资的商业案例 123
今天能做点什么 126
扩展阅读 126

第4部分 从战略和战术上管理技术债务 129
第10章 技术债务的成因是什么 130
技术债务成因识别的困惑 130
产生技术债务的根本原因 132
什么导致技术债务 133
业务原因 134
上下文变化的原因 135
开发过程原因 137
人和团队的原因 140
结论 143
今天能做点什么 143
扩展阅读 144
第11章 技术债务信用检查 145
查明原因：技术债务信用检查 145
了解项目状态的四个重点领域 148
Phoebe项目技术债务原因分析 150
Tethys项目技术债务原因分析 152
今天能做点什么 155
扩展阅读 155
第12章 避免非故意的技术债务 156
软件工程 156
代码质量和非故意的技术债务 157
架构、生产环境和非故意的技术债务 161
今天能做点什么 169
扩展阅读 169
第13章 与技术债务共存 170
你的技术债务工具箱 170
在土星的三颗卫星上 175
技术债务与软件开发 177
结语 179