今天看了下《从小工到专家》的第二章：注重实效的途径，简单谈下自己的感受（感觉这一章有点难懂）。
这本书将重复分为了四个类别：强加的重复，无意的重复，无奈性的重复，开发者之间的重复四种。并告诉了我们一些有效解决重复的方法。
对于一些客户或项目要求的强加类重复，要学会取巧，发挥自己的聪明才智，合理利用些工具，如使用简单的过滤器代码生成器，一份优秀的代码往往在于他有一份更好的更容易理解注释，所以不要忘了代码中的注释，文档和代码也要做到同步的更新，对于语言引起的可观的重复（如重复类和变量）产生的错误，我们无法避免，但至少给了我们修改的机会。
对于设计引发的重复性错误（无意的重复），我们一定要避免，并且可以做到避免的，看到这本书上的例子，让我想起了分页的设计重复问题，如果设计了总记录数，总页数，那么每页记录数直接可以由这两者得出，根本不用定义新的变量。
无奈性的重复：或许一部分代码的功能和你储存的代码功能类似，甚至稍加改动就可以实现，这时你就面临了拷不拷贝的抉择，拷贝无可厚非，但一定要谨慎考虑会不会影响接下来的开发。
不同的开发者在开发中极有可能出现代码快重复，对于该重复最好解决方法就是开发者之前的交流，而这种交流可以多种方式实现。
开发中的正交性原则：正交性对于整个项目开发而言无疑是个非常好的助力，提高了生产效率降低风险，避免团队中组织的重复，做好团队的分工，当然道理谁都懂，如何根据现实做好团队正交便是一个优秀领导者的问题了。其实最让我深刻的便是解耦吧，可能因为我没有项目开发的经验，代码解耦后，每个人各司其职，提高代码的重用性，缩短了开发时间，这也是为什么有框架的存在。
曳光弹的合理使用：在无法明确用户需求时，或许曳光弹是个上上策，曳光弹的采用使你在项目中做了一个基本功能，符合用户的需求，那就只需要加工修改，不符合的话，我们可以修改，直到曳光弹指向总目标，这总比干净的编辑界面要好。