软件开发与牛顿三大定律

我不知道从何时起,速度(效率)这个词在软件开发领域安家落户了,以前可从来没有这么流行过。然而我非常确定的一点是如果你提到运动却没有提到三大定律的话,艾萨克·牛顿先生肯定会不高兴。

[b]第一定律[/b]


[i]
在一个惯性参考系里面来看的话,除非受到外力的作用,否则物体会保持静止或者匀速运动。
[/i]


外力简直是太多了:

[*] 开发人员在解决BUG
[*] 开发人员在增加新的特性
[*] 开发人员在产生新的BUG
[*] 业务方要求降低操作成本
[*] 第三方竞争改变了市场格局
[*] 用户在改变
[*] 未完待续


然而一个团队或者产品要么是黄了(保持静止状态)要么是在进行匀速运动(每天都生产固定的利润或者消耗一定的预算)。

现在我敢说,说起团队的速度(效率)是违背第一定律的,因为要维持团队的效率的话需要做什么?什么都不用做!

好吧,这会让很多主管感觉反感,”我还是希望我的开发人员做点事情的“。

那么我们需要看一下下一条定律。


[b]第二定律[/b]

[i]

F = ma。作用于物体的力的矢量等于物体的质量M乘以它的加速度矢量a。
[/i]


加速度是改变速度的能力。F在这里可以看作一个常量,因为说实话,你的团队的规模是固定的,除非你是在Google。你的时间也几乎是固定的,一天24个小时,除非你住在火星上,它可能会长点,也就是 24.622962小时吧。好吧,我们完蛋了。。只剩一个变量是可以修改了。根据第二定律,对于一个给定的F,加速度和质量是成反比的。质量是一个负担,它和加速度是相背的。

下面列出了一些提升质量的方法:

[*] 想拥有的特性太多了
[*] 太多技术债要还了
[*] 太多的抽象,一层又一层,ORM,DAO,服务,控制器,视图。从数据库捞出一个简单的{“userid”: 123}就需要这么多的东西。哦,我忘了提了,还有SQL,NoSQl....
[*] 太多的进程
[*] 太多的模式,企业级的策略工厂构造器适配器监听器拦截器。。
[*] 沟通的流程太长了,业务方——项目经理——业务分析——团队主管——开发人员(你还可以加入更多的角色)
[*] 太多的框架,java EE ,Spring, Hibernate, Struts, Bootstrap, jQuery, Augular.js,Ember.js,你敢看下Java EE吗?在Java EE 7下有39个Java规范请求!
[*] 太多的服务器。WEB服务器,关系型数据库,NoSQL服务器,缓存服务器,消息队列,第三方集成服务器。

[b]第三定律[/b]

[i]
作用力和反作用力总是同时存在的:或者说两个物体间的相互作用力总是相等的,并且作用于相反方向。
[/i]

A:“我们能删了XYZ特性吗?这样的话代码会简单很多”
R:“还是不要了,这是投资人ABC想要的”
A:“好吧,没关系”

A:“我们能改成git吗?”
R:“别啊,我们最喜欢这些老古董了”
A:”那下次再说吧“

A:“可以升级下Java 1.4吗”
R:“生产环境还有很多在服务器在用呢”
A:“好吧,那我还是坚持手动进行类型转化吧”

我还想多码点字,不过现在有一股反作用力在阻止我这么做。。。那今天就先到这吧。

感谢你浪费了这么长时间来听我啰嗦了这么多。

[b]引用[/b]


* http://en.wikipedia.org/wiki/Velocity_(software_development)
* http://en.wikipedia.org/wiki/Newton's_laws_of_motion


原创文章转载请注明出处:[url=http://it.deepinmind.com/%E5%85%B6%E5%AE%83/2014/05/27/software-development-and-newtons-laws.html]http://it.deepinmind.com[/url]

[url=http://sgdev-blog.blogspot.sg/2014/05/software-development-and-newtons-laws.html]英文原文链接[/url]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值