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