多些时间能少写些代码
我在我的微博上说过这样一段话,我想在这里把我的这个观点阐述地更完整一些。
@左耳朵耗子:聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% - 50%的时间是在忙碌着编码,调试和测试。聪明的老板也会让团队这样做。而傻逼的老板,苦逼的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix 大量的bug… 所以, 越差的团队一般会越忙,而且还忙不完。
在现在这个浮躁的时期,再加上敏捷咨询师们念的歪经,他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的,这令那些管理者们很兴奋,就像巴甫洛夫的条件反射实验中的狗看到了肉就像流口水那样兴奋。他们使用TDD,快速迭代,不断重构,持续集成直至持续部署的方法在进行软件开发。
软件开发真是这样的吗?难道不需要花时间去思考吗?对此,有些观点在Todd的《“品质在于构建过程”吗?》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点:
所以,如果你能有多一些时间去和客户讨论一下需求和未来可能的变化,去调查一下实现的技术难点和细节,去和其他有经验的人讨论并推敲一下架构和设计,去思考设计上的缺陷,那么,你的coding会变得非常地直,直到你一眼就看到尽头,你的测试案例也会写得非常地好,你会几乎不需要重构,于是,你会在未来少写很多代码,从而你的软件开发会越来越轻松,直到技术开始换代。
我现在在做的项目,花了几乎4个月的时间来做设计,在这个过程中,我们反复思考、讨论和权衡若干种实现方法,并尽可能地穷举所有的场景和细节以及未来可能的变化(那怕是那些简单的模块),有个模块被重写了至少三次,每次都是写到一半就被推翻重写,我们整个团队不断地在和其它团队讨论,并在对系统不断地认识中对系统进行简化和优化,并力求达到完美。现在看来,没有贸然使用Scrum是明智的。
这就好像我们修路造桥一样,我们需要花大量的时间勘测地形地质,分析数据,思考可能出现的各种问题(各种自然灾害),评估不同的设计方案,而不是先尽快建好再说。
所以,多一些时间,不是让你多做几次迭代,多完成几个模块,而是可以让你少写一些代码,更快的交付一个更好的产品。
我相信你会有很多疑问,下面是我觉得你可能会有下面的一些观点,让我一条一条来回复:
关于软件项目管理的文章,还可以参看《软件公司的两种管理方式》,最后,欢迎大家表达观点。
(全文完)
建议继续学习:
- 神马?用excel来做项目管理? (阅读:42211)
- 腾讯敏捷开发及快速迭代 (阅读:6499)
- vim的一个js代码整理的插件jsbeautify.vim (阅读:4673)
- 测试驱动开发(TDD)跟敏捷开发有冲突 (阅读:3726)
- 写代码这件事 (阅读:3838)
- 一页纸项目管理表格学习笔记 (阅读:3334)
- 数据即代码,我和小伙伴们都惊呆了! (阅读:3340)
- 给你的代码《约法四章》:基本功能、错误处理、智能纠错、日志收集 (阅读:3122)
- 如何写出无法维护的代码 (阅读:2940)
- 十种更好的表达“你的代码写的很烂”的方法 (阅读:2877)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:陈皓 来源: 酷壳 - CoolShell.cn
- 标签: 代码 敏捷 项目管理
- 发布时间:2011-10-25 13:37:40
- [68] Go Reflect 性能
- [68] 如何拿下简短的域名
- [67] Oracle MTS模式下 进程地址与会话信
- [62] IOS安全–浅谈关于IOS加固的几种方法
- [61] 图书馆的世界纪录
- [60] 【社会化设计】自我(self)部分――欢迎区
- [58] android 开发入门
- [56] 视觉调整-设计师 vs. 逻辑
- [49] 给自己的字体课(一)——英文字体基础
- [48] 读书笔记-壹百度:百度十年千倍的29条法则