书很细，无经验读着有压力

        一两个月前看到了这本书，那时候正对编写高质量的代码很感兴趣，于是借来读。这一个月断断续续的读完，实际上读书的时间仅有10天左右的业余时间。读的很浅，但也有小小的收获。
        这本书讲解如何在不漂亮的旧代码下写漂亮的新代码，依照先有测试后有功能的思想，作者全书都围绕如何让代码可测试展开。
如果旧代码特差，而又时间紧迫，不足以把旧代码纳入测试，通常是让新代码跟旧代码独立开。这可能需要用上继承，会让代码有不必要的层次，这没关系，重构一直在进行，只要代码纳入了测试，以后就可以把它们去掉。
        让代码纳入测试，很多时候是说能够用伪造的东西替换真实的东西，这个伪造的东西是测试用的。可以有很多种修改方法让代码能有单元测试，主要有几类方法：预处理期、链接期、修改代码（对象、方法的替换）。
        本书看完之后，能回忆起来的东西很少，可能是因为没细看，也可能是写的太细了，实际工作中从来没有试过像书中所说的那样去写代码，步骤那么细，有必要吗？修改代码时，步伐要小是正确的，但小的书中所讲解的那种地步就有点受不了。本书可以总结为三个字“解依赖”，细节上就是各种各样的案例。
        看这本书需要有大工程代码的修改经历，不然会觉得很无趣，我现在就有点无趣，跟第一次看设计模式一样的感觉。测试驱动开发，这是我初次接触到的概念，虽然工作中挂着敏捷的羊头，但我们的代码不存在单元测试，连影子也没有。看书的时候想，实际工作不一定要有真实的测试先行，只要头脑里有单元测试的思想，写代码的时候就会尽可能的往那一个方向去，在设计的时候就会想，假如需要测试代码能这样写吗？自然的就会让代码有更少的依赖，更多的分层，这也就有了单元测试的影子，依赖少了，可扩展也强了。这也就是读这本书的潜移默化的影响。
        书里讲解看旧代码时，也讲解了些外围的东西，画图看代码就是很不错的方法。还有编译依赖导致一个工程的构建花费很多时间，这点书里谈到的不多，但工作中深感触，不必要的头文件包含、模板的滥用都会导致依赖增多，编译时间变长。
        这书跟《重构改善既有代码的设计》是同种类型。不过这本书怎么是这个书名呢？英文版是“Working Effectively with legacy Code”，也就是“在遗留代码上有效的工作”，强调的重点就不一样了。
        看这本书有些名词不熟悉的压力，看到了很多新名词，譬如“函数签名”（其实就是形参），“朴素化参数”（可能是说让被切入测试的函数的参数是一般类型），“自由函数”（术语表有解释，C++中是非成员函数），“领域类”（就是MVC中的逻辑M，这个词在《重构》上出现过）……这些新名词也不知道是不是通用的，如果不是通用的，搞出一个离本意遥远的新词来，又不在章节的开头给概述性解释，就真是让看者莫名其妙了（我又想到了那个“名字粉碎”的翻译，这本书里也用了它，很文艺很奇怪）。译者有些地方太小心了，加了不必要的译注，有些地方又感觉翻译得不容易快看，如果能意译会好些。