最近阅读了《卓有成效的程序员》(The Productive Programmer) 一书，此书虽是2009年出版，但是介绍内容的价值并不会随着时间过去而降低，相信5－10年后对于大部分开发者仍然具有借鉴价值。
大部分章节是介绍具体的方法来如何提高程序员工作效率。记住具体的技巧未必有太大价值，很多人都认同一种观点就是，读一本书最终的目标是忘记其中所有的观点，但是它会潜移默化影响了你以后的思维和或观点，包括你的行为。因此我认为此书直接的影响就是帮助思考开发过程的方法和问题，思考以前的惯例是否存在问题。比如最近在设计某个产品删除功能的时候，一位同事突然提到是否产品将来有需要查看行为历史，如果需要记录历史，删除的流程就会变复杂，不但影响删除功能的实现，还会影响后端数据的规模，从而进一步会影响架构的设计。因而我的直觉是这是一个过早优化，也就是书中第9章讲的YAGNT(You Ain’t Gonna Need It 你不需要这个特性)。由于第一时间的质疑，这个可能需要耗费大量开发时间的特性被暂停，对于项目本身或许是一件好事。
此外书中一些敏捷的思路也会带来一些间接影响,我还意识到过去一些非敏捷方法可能会给项目带来风险，一个过去的项目，开发完成之后逐渐变得臃肿，和大部分后端服务相似，需要依赖一些特定的数据库及其他依赖环境。由于不希望开发环境与真实环境差距太大，开发环境也全部按真实环境最小单元的配置来进行，这就导致开发依赖的环境很多
内部依赖
MySQL master/slave
分表
Memcached(多个)
外部依赖
Message Queue(消息队列)
用户及鉴权服务
internal HTTP service
导致的问题
需要特定的环境才能开发，比如公司配好的环境中
无法在家中或咖啡馆干活，因为系统跑不起来，无法看到效果
一旦部分依赖环境有问题，则无法开工，只能等着服务恢复
一旦几天没跟进代码，可能就由于环境设置的变化而无法独自启动工程。
这些问题就导致代码改进的工作令人生畏，要像Google那样做到任何对代码感兴趣的人可以patch代码的意愿都会变成”mission impossible”。因此对于这个项目来说，最急需的一个改进是分析依赖，让项目能够随时随地可以方便的跑起来，大家可以很简单的改进代码，对改进的代码进行测试验证，测试之后新的代码基本可以无风险的运行到线上环境去。否则臃肿的项目只会降低大家的贡献的热情，最后变成一个死气沉沉的工作任务。
你的项目中的惯例是否存在问题呢？比如Java中POJO中无用的get/set方法，比如一些使用c/c++来“优化”项目中的瓶颈而走向时间泥潭的经历，比如贵公司是否又在雄心勃勃要做一个自己的框架，事实上这个框架对于项目本身毫无价值。诸如此类的情况会非常多，这本书主要介绍的是程序员要如何提高自身的效率，但我觉得程序员更多的也应思考团队的效率改进并发出声音。
