《Agile Java》阅读笔记

最开始想学TDD，在图书馆看到了这本书，便借来看看。我看书有一个习惯，就是顺着主线把所有的例子都自己调试一遍，不管难或简单。毕竟我们是个工学学科么，而且我也是一个励志做一个工程师的人，多写代码才是王道。昨天把前四章的主线都写了，看着不顺眼的地方都是按照自己的编码风格改写的，没有一味的遵照书上的做法。书后的例题木有做，暂时没有时间。

     个人感觉这本书讲的很细，对编程基础要求的不高。但是它对于Java的很多特性剖析的很清楚，对TDD也讲的很不错，中间还穿插了一些设计模式和重构的一些东西，“21天全能”哇。这本书最大的好处就是实用，并不是一本停留在理论上的书。个人认为所谓的实践模式和设计模式就是前人的经验总结，把一些经常遇到的场景的最佳实践进行了总结。与其去死记硬背，不如在遇到了之后做一个参考，看看人家是怎么弄得。多做几次就记住了。而且如果不了解模式提出的背景，没有和实践结合起来，恐怕只会画虎不成反类犬。而重构的目的就是为了保证代码的质量，比如：可读性、可扩展性和稳定性。重构的定义大概是说，在不改变代码功能的前提下，对代码质量进行优化。那么它的前提，不改变代码功能就需要测试来支撑了。只有有了足够的测试，我们才能确信我们的重构没有引起功能上的变化。那么对于一个我这样的初级开发人员来说，能自己编写的测试恐怕还是单元测试居多。那么为了保证我们的代码质量，我们势必会编写足够的单元测试。那么在此基础上，TDD并不会带来更多的负担，它只是把编写测试用例的时间提前。在编写代码之前就写测试用例的好处是保证了我们代码的可测试性。这样，势必会降低功能之间的耦合性。

      然而，没有银弹。首先TDD对于开发人员的要求势必比糙快猛的开发要求高。其次，功能性的开发可能比较好撰写测试代码，但是对于一些UI方面的东西，我还是压根不知道怎么去测试的。第三，TDD适合在项目开始的时候进行，对于一个已经开始一段时间的项目，我们能做的可能不多。当然在Balto童鞋给我的教导中，我们还是可以从以下几个方面做一些尝试：1.开辟一个独立的功能模块，应用TDD，把握一块是一块；2.推倒重来。

      对我来说，编程就是一场修行，很多东西我们知道好，但是不会坚持。要做的其实很简单，把我们知道的好的地方，严格的坚持下来，然后及时总结我们遇到的好或不好的地方，找寻解决方案，就好了。水滴石穿。