多些时间能少写些代码
?
导读:作者陈皓在微博上说过这样一段话:“聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30%–50%的时间是在忙碌着编码,调试和测试。聪明的老板也会让团队这样做。而愚蠢的老板,愚蠢的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix大量的bug…所以,越差的团队一般会越忙,而且还忙不完。”文中作者就此观点进行阐述。
文章内容如下: 在现在这个浮躁的时期,再加上敏捷咨询师们念的歪经,他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的,这令那些管理者们很兴奋,就像巴甫洛夫的条件反射实验中的狗看到了肉就像流口水那样兴奋。他们使用TDD,快速迭代,不断重构,持续集成直至持续部署的方法在进行软件开发。 软件开发真是这样的吗?难道不需要花时间去思考吗?对此,有些观点在Todd的《“品质在于构建过程”吗?》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点:
所以,如果你能有多一些时间去和客户讨论一下需求和未来可能的变化,去调查一下实现的技术难点和细节,去和其他有经验的人讨论并推敲一下架构和设计,去思考设计上的缺陷,那么,你的coding会变得非常地直,直到你一眼就看到尽头,你的测试案例也会写得非常地好,你会几乎不需要重构,于是,你会在未来少写很多代码,从而你的软件开发会越来越轻松,直到技术开始换代。 我现在在做的项目,花了几乎4个月的时间来做设计,在这个过程中,我们反复思考、讨论和权衡若干种实现方法,并尽可能地穷举所有的场景和细节以及未来可能的变化(那怕是那些简单的模块),有个模块被重写了至少三次,每次都是写到一半就被推翻重写,我们整个团队不断地在和其它团队讨论,并在对系统不断地认识中对系统进行简化和优化,并力求达到完美。现在看来,没有贸然使用Scrum是明智的。 这就好像我们修路造桥一样,我们需要花大量的时间勘测地形地质,分析数据,思考可能出现的各种问题(各种自然灾害),评估不同的设计方案,而不是先尽快建好再说。 所以,多一些时间,不是让你多做几次迭代,多完成几个模块,而是可以让你少写一些代码,更快的交付一个更好的产品。 我相信你会有很多疑问,下面是我觉得你可能会有下面的一些观点,让我一条一条来回复:
文章出自:酷壳网 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- C#实现创建桌面快捷方式与添加网页到收藏夹的示例
- swift数据类型
- c# – 如何在GetInstance调用/备用解决方案后在Simple Inje
- C中是否有完整的实现定义行为列表?
- c# – RestSharp – 如何处理非200响应? RestClient在Exec
- xml – 要选择哪种设置存储格式?
- symfony2 – 为什么更新composer中的依赖是如此缓慢?
- ruby-on-rails – Ubuntu上的Ruby Gem Guard,没有’guard’
- c# – 如何首先在Entity Framework代码中创建具有相同类型的
- hdu 1011 Starship Troopers (依赖背包 树形dp)