本书的第二章讲的是“敏捷编码 ”主要从以下几个方面来讲述:
1、 代码要清晰地表达意图
a、开发代码时，应该更注重可读性，而不是只图自己方便。代码阅读的次数要远远超过代码编写的次数，所以在编写的时候值得花点功夫让它读起来更简单。
b、要编写清晰的而不是讨巧的代码。向代码阅读者明确表明你的意图，可读性差的代码一点都不聪明。
2、 用代码沟通
a、用注释沟通。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能代替优秀的代码。
3、 动态评估取舍
a、动态评估权衡。考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
b、如果现在投入额外的资源和精力，是为了将来可能得到的好处，要确认投入一定要得到回报（大部分情况下，是不会有回报的）。
c、过早的优化是万恶之源。
4、 增量式编程
a、在很短的编辑、构建、测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。
b、要像重构你的代码那样，重构你的测试，而且要经常重构测试。
5、 保持简单
a、开发可以工作的、最简单的解决方案。除非有不可辨驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
b、要将目标牢记在心：简单、可读性高的代码。强行让代码变得优雅与过早优化类似，统一会产生恶劣的影响。
6、 编写内聚的代码
a、让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不用创建无所不包的大杂烩类。
7、 告知，不要询问
a、面向过程的代码取得信息，然后做出决策。面向对象的代码让别的对象去做事情。
b、作为某段代码的调用者，开发人员绝对不应该基于被调用对象的状态来做出任何决策，更不能去改变该对象的状态。这样的逻辑应该是被调用对象的责任，而不是你的。
c、告知，不要询问。不要抢别的对象或是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。
8、 根据契约进行替换
a、替换代码来扩展系统。通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是继承。
总结：一个好的代码不在于它有多复杂，而在于阅读对象是否能够清楚的明白其意图，在于其是否可以运用最简单的编码来表示一些复杂的东西和其组件是否可以替代一些大的组件。进行动态评估时，要进行适当的取舍，当主要部分得到实现时再考虑其他的因素。