致软件开发人员：软件开发与牛顿三大定律
2014-05-28 09:50:01 来源： 评论：0 点击：
我不知道从何时起，速度（效率）这个词在软件开发领域安家落户了，以前可从来没有这么流行过。然而我非常确定的一点是如果你提到运动却没有提到三大定律的话，艾萨克·牛顿先生肯定会不高兴。第一定律在一个惯性...
@我不知道从何时起，速度（效率）这个词在软件开发领域安家落户了，以前可从来没有这么流行过。然而我非常确定的一点是如果你提到运动却没有提到三大定律的话，艾萨克·牛顿先生肯定会不高兴。
第一定律
在一个惯性参考系里面来看的话，除非受到外力的作用，否则物体会保持静止或者匀速运动。
外力简直是太多了：
第一定律
在一个惯性参考系里面来看的话，除非受到外力的作用，否则物体会保持静止或者匀速运动。
外力简直是太多了：
- 开发人员在解决BUG
- 开发人员在增加新的特性
- 开发人员在产生新的BUG
- 业务方要求降低操作成本
- 第三方竞争改变了市场格局
- 用户在改变
- 未完待续
- 然而一个团队或者产品要么是黄了（保持静止状态）要么是在进行匀速运动（每天都生产固定的利润或者消耗一定的预算）。
现在我敢说，说起团队的速度（效率）是违背第一定律的，因为要维持团队的效率的话需要做什么？什么都不用做！
好吧，这会让很多主管感觉反感，”我还是希望我的开发人员做点事情的“。
那么我们需要看一下下一条定律。
第二定律
F = ma。作用于物体的力的矢量等于物体的质量M乘以它的加速度矢量a。
加速度是改变速度的能力。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服务器，缓存服务器，消息队列，第三方集成服务器。
- 第三定律
作用力和反作用力总是同时存在的：或者说两个物体间的相互作用力总是相等的，并且作用于相反方向。
A：“我们能删了XYZ特性吗？这样的话代码会简单很多”
R：“还是不要了，这是投资人ABC想要的”
A：“好吧，没关系”
A：“我们能改成git吗？”
R：“别啊，我们最喜欢这些老古董了”
A：”那下次再说吧“
A：“可以升级下Java 1.4吗”
R：“生产环境还有很多在服务器在用呢”
A：“好吧，那我还是坚持手动进行类型转化吧”
我还想多码点字，不过现在有一股反作用力在阻止我这么做。。。那今天就先到这吧。
感谢你浪费了这么长时间来听我啰嗦了这么多。
引用
* http://en.wikipedia.org/wiki/Velocity_(software_development)
* http://en.wikipedia.org/wiki/Newton's_laws_of_motion
原创文章转载请注明出处：http://it.deepinmind.com
英文原文链接
上一篇：Autocad在启动时屏幕上一闪就关怎么解决？
下一篇：Micro-channel is no longer barbaric growth
分享到：
收藏
收藏
