1. 前言
说来这本书也算有年头了，拿在手上的这本汉化版显示其第一版在2017年10月就出版了。
不过我知道这本书的时间并不长，相应的购买决定也是下得相当草率 —— 只是看着这个名字特殊亲切（我最近两年的一大块精力就是在干这个事情），再加上PDD的出现，于是也没啥多的犹豫。毕竟能够行文成书的，作者对于相关概念至少有着系统性的深度思考和总结的，对于我这种只缘身在此山中的彷徨者，拜读一下肯定能够有所收获。（从最终的观感来看，也确实如此）
2. 全书印象
过去这些年我都一直保持着专业阅读的习惯，所以对于书中的大部分知识点，感觉上其实并不陌生。
不过需要强调一下的是：这种所谓的"不陌生"主要是集中在对于行业内基础知识和概念的认知和了解上，但将这些认知落到"遗留系统重建"这一小块实际执行区域上，确实能够产生了一些意料之外的审视视角和方法论。也算是对"纸上得来终觉浅，绝知此事要躬行“的再次明证吧。
回到书籍本身：
- 本书的目的作者在开篇就挑明了：教会你将一个被忽视的老旧代码库转变为一个可维护的、功能良好的、能为你的组织产生价值的软件所需要做的一切事情。说实话，这个宣言很容易让人看得热血沸腾。
- 本书一共十个章节，被分为了三部分，
2.1 在第一部分里，首先是基本术语的介绍，做好正式开始前的起步工作、达成基本共识、打下交流基础；其次是介绍如何实现现有代码库的质量度量。从这两个开头章节就可以看出作者的专业：没有度量就没有优化；软件开发流程里最重要的是团队沟通，而沟通的前提则是团队内基本术语的一致性。
2.2 第二部分介绍如何通过重构来改善代码库。其中最让人欣慰的是作者在其中反复强调重写是最后的选择，这一点在过往诸多大能的著作里也是反复强调。而为了实现这个目标，作者在本部分分别介绍各类被证明有效的重构方法和技巧。
2.3 第三部分”重构之外——改善项目工作流程与基础设施”。作者在全书持续强调"软件开发中编码部分占比并不多；工作流程和基础设施方面的优化很可能有着更高的性格比"。现实工作中，我发现不少研发人员有意无意地将流程进行拆分，试图证明自己的职责只有编码这一项，以尽量减少自己身上的负载。但恰恰是这种行为大大增加了上下游团队的压力，以及整体软件产品交付上的压力。 - 虽然本书介绍的是"遗留系统改造"，但其所介绍的很多思路和方法都是可以应用到待开发的项目里的，所谓"有则改之无则加勉"，相较于事后补救付出的代价，事先进行的预防，其成本基本可以忽略不计。而且因此所带来的人员素养，以及流程效率上提升更是会产生持续性的回报。
说到软件产品，我们很容易被编码这件事情吸引去绝大部分注意力，而剩下的那点琐屑也都是为了让客户同意付款而被迫投入的；这样的态度在面对平均开发周期在1-3月的项目型软件时问题还不大，但在面对作为将被长期维护迭代的产品进行设计开发的软件时，这样的认知就存在巨大的问题了。
遗留项目也就意味着长期维护，而长期维护之下的要求之下，势必会产生于"快销类软件"开发流程产生截然不同的要求：
- 首先是对于团队交流的重视。书中作者对于沟通的反复强调，以及与本书同时穿插阅读的《Google软件工程》也都在强化这一条。
- 然后是全流程优化。这也是一个被讨论烂的话题 —— 局部的优化很多时候反而有害，软件研发作为一个上下游协作的工作，局部的提速会打乱下游的节奏，进而让其陷入混乱，如果没有全局性的指导，很容易造成更大的内耗产生全局性的反效果。本书里关于"不可变基础设施"、"DEVOPS"，"云基础设施"等等专有名词的出现和解释都揭示着 —— 工程领域哪来那么多的创新，现在所谓的热点其实早在几年甚至几十年前就开始了。
- 最后对于细节的要求。典型的就是代码可读性的要求，"童子军法则"、"代码是用来读的，只是恰好能够被计算机执行"等，虽然略显极端，但在"长期"这个要求面前，却又是基本要求。
3. 部分摘抄
3.1 代码检查工具的引入顺序
类似给我带来启发性思考的还有"通过统计GIT提交记录来分析有哪些文件是被经常编辑的，进而确定代码热点，进一步确定优化方向"等等。
3.2 重构纪律
- 将重构和其它工作分开。先完成业务功能，再重构，或者反过来。原子化操作，小步快跑。
- 依靠IDE。
- 依靠版本控制系统。
3.3 让用户为你工作
一直以来我们都非常强调所开发系统的可观测性，无论你作多少测试，总会有一个模式你没有能够测试到。从某种意义上说，你在发布之前运行的每个测试都是在尝试模拟经典用户的操作。
有几种方式来借助用户数据来帮助你确保软件的质量：
- 渐进式发布新版本，同时监控错误和回归问题。
- 收集真实用户数据，并利用它来使你的测试更高效。（所谓的"流量回放"）
- 区分部署和发布。（金丝雀部署，灰度测试）
3.4 大规模重写前，希望你已经用尽了其它所有的选项
大规模重写前，希望你已经用尽了其它所有的选项：
- 你试过重构代码库，但陷入僵局
- 你调查了使用第三方解决方案代替旧版软件的可行性，但它需要进行太多的自定义开发。
为什么我们认为重写遗留应用程序并不是一个好的选择：
- 首先，项目会无休止地拖延。而且花费的时间会比你预期的更长。这是被无数历史验证过的，你也绝对不会成为那个例外。
- 其次，尽管投入了巨大的精力，重写却只能给最终用户提供有限的直接价值。在最终用户看来系统的业务功能并没有增加，反而似乎BUG还多了。
另外作者使用了3.4一整个小节为读者从正反两个方面分析"重构 VS 重写"，并介绍了"增量重写"/"绞杀者模式"这一模式，对于有着类似需求和困境，需要说服团队的读者，可以仔细阅读下这个章节。
3.5 开发环境的自动化
作者在书中建议使用Vagrant + Ansible 进行开发环境的自动化。
关于这一点，不确定是作者在写书时间过早，Docker还不成熟还是什么原因，一直以来我都在犹豫是采用Docker还是再学习下Vagrant相关技术，来实现开发环境搭建的自动化，进而实现团队的一致性。
3.6 同样适用于待开发项目
虽然本书一直在以遗留代码为背景讨论，但很多想法同样也适用于待开发的项目：
- 源代码并不是项目的全部；（《人月神话》里的"编码只占整个软件工程流程里的1/6"）
- 信息不能是自由的；（信息需要被共享出来、易发现、易阅读、可信。而不能被当事人恣意处理 —— 比如因为各种原因选择不分享等）
- 工作是永远做不完的；（所以不能以"时间紧迫"而拒绝代码审核；以ROI去衡量事情处理的优先级等）
- 自动化一切；（始终留心观察可以进一步自动化的那部分开发工作流程）
- 小型为佳。 （轻装上阵，快速迭代）
4. 后记
对于一个软件研发人员来说，而相较之下遗留系统维护里的处处掣肘，做全新项目总是让人欣喜的 —— 新技术，完全不需要考虑技术债等。但对于一个有所追求的研发人员，这样的经历却存在隐患：总是在做新项目，也就意味着你所参与的工作内容没有所谓的长期性，写出来的目的就是为了扔掉。项目缺乏长期性，也就意味着你所要面临的问题缺乏长期性，自然无法深入的研究，最终你所解决的大部分问题属于"是个人就行"，无法构建出属于自己的技术路线上的职业壁垒。
所谓"求上得中、求种得下、求下无所得"，现在年轻人都喜欢说"不是不爱吃苦，是不爱吃没有回报的苦"，那么从手上的工作开始，对自己要求严格一些，自己给自己带上这副镣铐，跳好眼前这场舞蹈，让自己在之后面临更严格场景时，能够从容些。
5. 相关
- 自来水 -《10x程序员工作法》
- 《匠艺整洁之道》- 测试驱动开发
- 《人月神话》。整个软件生命周期里，编码时间只占1/6。
