不知道这算不算一本好书，但对我这个出入"IT江湖"的小白。这些技巧非常的受教。当然，在看完了这本书后，与之前自己浏览过的那本经典之作《重构—改善既有的代码设计》有些地方存在吻合的。但是，这本书更令人如沐春风，为什么？我们程序员最喜欢的就是与源码。不管怎样，都会吼一声"翠花，上源码"。所以说，这本书的例子，更令我快速掌握其介绍的技巧（遗憾的是自己也没完整的做过大部分练习，感觉很不爽）。不废话了，免得忘了自己要做什么！写点读书的笔记呗！
书中的技巧都是针对现实编程中出现的实际问题而引出的，但是都需要我们在获得此技巧时，也要注意一定的使用场合。
移除重复代码
如何发现重复代码？相信每个程序员都晓得咯！想想曾经写的DAO那些代码，你就寒心了。重复代码多吧！个人感觉，逻辑结构相同的，有一样的处理结果，在两处地方以上出现等等，都需要的是自己如何判断罢了，没有书面的答案。
为什么要移除重复代码？我们不要指望代码行数越多，就能带来更大的优越感（曾经，初学编程时，我就以写更长的程序为目的，能写出来了，颇为自豪，但是在工作中，这点不可取）。Why？如果在某个N多地方出现的一样功能的程序。那么，你每一次的修改，都是一场噩梦！慢慢享受吧。如今的江湖，需要更精练的代码。
将注释转换为代码
在软件开发中，最让我们受教的就是，在编码中要加上适当的注释，为的就是日后的代码维护，不用猜字谜一样猜某段代码的功能了，毕竟你都加上注释，是吧！
但是，亲爱的，你喜欢这样的代码吗？你会暗地里骂写这代码的人吗？我想我知道你心里所想(>_<)
在这里，我们能做什么呢？我也曾记得应该给一个变量起一个有意义的名称？为的 就是让人一眼就知道这个变量所代表的意义！而不是加上一段注释。如此可以避免你在 前几行能记住这个变量的含义，但是隔了段时间或写到N行后，我想你就忘了那个变 量兄弟究竟是干嘛的了。
有时候要舍得删除额外的注释？注释具有让人更容易的理解代码的功能；而问题也 在于，因为常常没有吧代码写清楚，所以才会找到注释这个工具捷径，好让程序更让人 容易理解。也往往让我们忽略了好好的去组织代码结构。长年累月，留下：本身 就不 清晰的代码，加上一些不正确的注释。
书中给的建议：每一处注释都是改进代码的好机会
针对上面的代码，可以利用【注释转换为变量名】技法，解决。除了此法，还有以下列 表可供君参考：
参数的注释，转化为参数名（其实刚刚那一条）
将注释转换为方法的一部分
删掉没用的注释（不要因为可怜自己的劳动成果，而留下没用的）
可用方法名来表达注释的意思（利用小方法，细化掉大方法体；让代码都处在自己所需 表达的意义的有效范围内）
。。。。。
去除代码异味
出现代码异味的原因是代码的不稳定。在编写代码前，如何确定代码是否稳定？一种有效而被动的方法是：当你第三次修改代码时，就考虑这段代码是不稳定的，是有异味的！ 而普遍的代码异味是，类别码和switch表达式。以下提供些异味列表：
太多的注释
类别代码
switch if-then-else-if
想给一个变量 ，方法或者类名取个好名字时，也怎么也取不好
用类似XXXUtil, XXXManager, XXXController 和其他的一些命
在变量，方法或类名中使用这些单词"And"、"Or"等等
一些实例中的变量有时有用，有时没用
一个方法的代码太多，或者说方法太长
一个类的代码太多，或者说类太长
两个类都引用了彼此（相互依赖）
一个方法有太多参数
对于普遍的类别码移除，常见的两种方法：
1. 用基于统一父类的不同子类代替不同的类别
2. 用一个类的不同对象代替不同的类别。
对于存在的"代码异味"，更多的是要我们在发生变更时，需要修改类的内部，而不是 通过扩展或其他不动原来的类的方法进行变更。如此的代码结构是有问题的，因为没有 考虑到日后的代码变更所带来的额外工作量。也不符合【开闭原则】。在编码中应该要 多多注意到这一基本原则，避免自己的代码在日后的维护中，走向深渊！
