做卓有成效的程序员
最近阅读了《卓有成效的程序员》(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++来“优化”项目中的瓶颈而走向时间泥潭的经历,比如贵公司是否又在雄心勃勃要做一个自己的框架,事实上这个框架对于项目本身毫无价值。诸如此类的情况会非常多,这本书主要介绍的是程序员要如何提高自身的效率,但我觉得程序员更多的也应思考团队的效率改进并发出声音。
建议继续学习:
- 程序员技术练级攻略 (阅读:31905)
- 再次写给我们这些浮躁的程序员 (阅读:15703)
- 给程序员新手的一些建议 (阅读:11956)
- 给年轻程序员的建议 (阅读:9908)
- 在西方的程序员眼里,东方的程序员是什么样的? (阅读:8826)
- 做个懂产品的程序员 (阅读:8736)
- 每个程序员都应该有张木桌 (阅读:8035)
- 再谈“我是怎么招聘程序员的” (阅读:7399)
- 如何在面试中发现优秀程序员 (阅读:7112)
- 架构师给程序员的一封信 (阅读:6790)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:Tim 来源: Tim[后端技术]
- 标签: 卓有成效的程序员 程序员
- 发布时间:2010-05-25 10:21:35
- [67] Oracle MTS模式下 进程地址与会话信
- [67] Go Reflect 性能
- [67] 如何拿下简短的域名
- [62] IOS安全–浅谈关于IOS加固的几种方法
- [59] 图书馆的世界纪录
- [59] 【社会化设计】自我(self)部分――欢迎区
- [59] android 开发入门
- [56] 视觉调整-设计师 vs. 逻辑
- [49] 给自己的字体课(一)——英文字体基础
- [47] 读书笔记-壹百度:百度十年千倍的29条法则