開發(fā)模式の不可能三角
- 質量：功能正確，BUG少
- 性能：代碼運行的速度快
- 效率：開發(fā)效率高，按時或者提前交付
優(yōu)缺點和必要性
質量
這是必須的，功能正確大于一切，否則就沒有意義
效率和性能
要想寫出性能好的代碼，需要開發(fā)人員精心設計，使用巧妙的數據結構、引入中間件等，因為引入了一些復雜的東西，所以容易出錯，需要花很多的時間自測、調參，所以效率不高；想要追求開發(fā)效率，提交交付速度，那么必然無法兼顧代碼性能，你能指望一個快速寫完的代碼性能有多好？所以這兩個指標在大部分場景下是互斥的。
那么我們究竟該怎么選擇呢？
首先從公司的角度來考慮一下這個問題
公司希望能夠快速的迭代，快速搶占市場，快速驗證產品模型和思路，所以有『效率』的訴求。公司同時也希望代碼性能高，客戶體驗好。但是如果一定要二選一，那么公司必然會選擇『效率』。因為效率上去了，產品夠豐富、夠深度，客戶才會來使用；而體驗好，只是錦上添花的東西。對于客戶來說，功能不好用，客戶都不會掏錢購買，再快沒用。而且為了追求性能，需要開發(fā)人員花費很多的時間來設計，這部分時間公司也都是花了錢的，而如今人比機器貴，一個應屆生月薪至少9K起，日薪400，而一臺4核8G機器一年只要 2800，一天7元，一個應屆生優(yōu)化一天，趕得上購買57天的4核8G機器了，而4G redis，一年只要540元，用redis優(yōu)化比人優(yōu)化要便宜地多得多。
站在開發(fā)者的角度
人，都要實現『勞動價值』，所以開發(fā)者加入公司后，就要在公司勞動，實現價值。而勞動就是去實現一個一個的業(yè)務需求，為公司創(chuàng)造價值。但是根據『馬斯洛需求』，人都有潛在的『自我實現』的需求，那么當一個開發(fā)者熟練掌握業(yè)務需求的實現套路后，必然謀求更進一步的發(fā)展。而對于『性能』這個東西，當你實現幾遍之后，就差不多摸清楚了套路了，再去實現無法得到有效的提升。舉一個實例的例子，大家都知道不要在循環(huán)里查詢數據庫，因為反復IO帶來了性能損耗，也都建議改批量為單次。但是當你在業(yè)務需求里實現了好幾遍之后，在你掌握之后，你再去做這個優(yōu)化，已經沒有太大的意義了，無法得到提升，而寫這塊代碼又比較花費時間，所以有經驗的開發(fā)者會止步不前。
solution
所以無論是從公司角度出發(fā)，還是從開發(fā)者角度出發(fā)，“過度”追求性能，都是弊大于利的事情（當然了對于初入職場的同學，或者對優(yōu)化手段還不熟練的同學，追求性能是一個提升很快的事情），所以我們需要擺脫這個束縛，輕裝上陣
當我們不再追求性能指標之后，事情就開始變得有意思了起來。首先不用花時間過度優(yōu)化代碼，那么時間就有富余，此時就可以去挑戰(zhàn)一些更有難度的問題了。而這些問題無一不是困擾了公司很久的問題，也是客戶抱怨已久的問題。一方面開發(fā)效率變快，公司滿意，客戶滿意；另外一方面，有經驗的開發(fā)者可以騰出精力來挑戰(zhàn)難題，獲得成長的同時修復了歷史問題，公司滿意、客戶滿意、開發(fā)滿意，怎么看都是三贏。
