第一定律
在一個慣性參考系裡面來看的話，除非受到外力的作用，否則物體會保持靜止或者勻速運動。
外力簡直是太多了：
- 開發人員在解決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
本文轉載自：it.deepinmind