读《驯服烂代码——在编程操练中悟道》--未完

读《驯服烂代码——在编程操练中悟道》

第2章

1. 在IDEA中把光标定位到那些红色的有编译错误的代码上，然后按快捷键Alt+Enter能快速帮助我们生成所需要的代码。

2. 如果能做到当有少量代码改动时就频繁地把代码提交到本地代码库而不管其是否通过编译，且每次提交都能填写有关此次代码改动的、意图明确的Commit Message，那么这种每次少量且意图描述清晰的代码提交，一方面增加了将来阅读代码变动的可读性，另一方面当代码写错需要回退时也能有助于做到更精细的回退。

第4章

1. 测试后行的开发方法所表现出现的问题包括：文档经常与代码缺乏同步造成理解偏差，写main()方法进行的测试无法让计算机自动判断软件行为是否符合预期导致效率低下，问题产生后没能立即发现耽误修复时间，照搬设计模式导致设计出不必要的抽象和编写出从未被调用的方法造成时间浪费，程序调试过程无法让计算机来代替并自动化并自动化地反复使用导致代码维护时间剧增。

2. 用测试后行的开发方法所开发出来的代码，会使与代码相关的所有人，在对代码的行为理解、问题感知和质量维护方面都反馈迟缓，其后果就是浪费这些人的时间、精力和金钱。

第5章

1. 把以前所提到的带有强制、专制和持久色彩的“需求”一词，换成了“产品特性”这种基于沟通的字眼，能够让产品特性在频繁沟通的保证下更加具有价值。

2. 把测试方法的名字写得很长，并在单词之间加上空格，使得测试方法名成为易于阅读的文档。

3. 一个测试通常包括Arrange、Act和Assert这3部分，分别表示测试准备、调用待测方法和验证结果是否符合预期。

4. 在一个测试中先写出最后的Assert部分，然后推到出Act和Arrange这两部分代码，会更加符合TDD的测试驱动风格，营造出分形的和谐气氛。

5. 没有适当的面向对象的设计，就无法写出合理的意图代码。所以在测试中编写意图代码就能促进在写测试代码时做出适当的设计。

6. 在测试中写好了所有的意图代码后，由于生产代码还未编写，势必有许多编译错误，而这种用修复意图代码编译错误的方法来驱动出生产代码的做法，能够让生产代码的开发过程更加具有方向性。

7. 在逐个解决上述编译错误的过程中，只写能让编译通过的、尽量少的代码，比如空类或空方法，而把编写其具体实现的内容留到后面运行测试出错时再写，同样能够让生产代码的开发过程更加具有方向性，且有助于编写出不多不少并能让测试运行通过的代码，避免了时间的浪费。

8. 用直接返回假数据的方法，让测试尽快运行通过，这样能够快速结束当前编写测试的环节，进入下面的重构环节，并能进一步指出重构的方向。

第6章

1. 把在编程中随时发现的要处理的问题，在代码中相应的位置写成Todo，正在处理的Todo标记为Todo-working-on，并在将来使用快捷键Alt+6来查看，CTRL++来展开Todo，能让随时发现的问题不致中断现有的工作，并且不会遗忘任何发现要做的事情。

第8章

1. 每次重构代码后都随时运行测试，以检查是否破坏了原有代码行为。

2. 是否选择将测试代码中的重复代码移动到测试类中以@Before标注的方法中以消除重复，也因人而异。因为有人认为这些重复的代码在每个测试中都是上下文的一部分，如果被提取到@Before中，会造成阅读测试代码时频繁地跳跃，产生不便，所以这部分人偏向于不提取测试中的重复代码。

第9章

TDD开发方法具有的优势：

1. 把代码本身当成代码编写的沟通基础，令代码成为可以运行的文档，会让那些代码即文档的读者——包括程序员、测试工程师、产品专家等——在理解代码行为方面反馈迅速。

2. 把测试的期望值写成Assert语句告诉计算机，使其能够代替人脑来判断结果是否符合预期，会让程序员在感知代码问题方面反馈迅速。

3. 先写测试并频繁运行测试以立即发现错误，会让程序员、测试工程师和开发经理等所有与代码相关的人在感知代码问题方面反馈迅速。

4. 专注在用“最少量”的代码让编译和测试运行通过，接着治理代码“腐臭”，通过计算机自动且反复运行的测试，发现那些被限定在一个个粒度很小的测试之内的bug，都会让程序员在维护代码质量方面反馈迅速。

第10章

烂代码的定义

1. 能够运行

2. 需要修改其中的bug或在其中增加新功能

3. 对于代码的编写者、测试者和维护者来说反馈迟缓。

PS：码农酒店GitHub，该代码则是驯服烂代码中的第一个实例。