作卓有成效的程序员

最近阅读了《卓有成效的程序员》(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++来“优化”项目中的瓶颈而走向时间泥潭的经历，好比贵公司是否又在雄心勃勃要作一个本身的框架，事实上这个框架对于项目自己毫无价值。诸如此类的状况会很是多，这本书主要介绍的是程序员要如何提升自身的效率，但我以为程序员更多的也应思考团队的效率改进并发出声音。