我所認識的軟件開發原則：二八原則

[size=medium]
二八原則源自經濟學理論，表述爲：通常一個企業80%的利潤來自於20%的項目。由此推廣出對日常生活的很多描述，如20%的人投資明天，80%的人消費於今天；20%人的正面思考，80%的人負面思考等。20%和80%只是一個概數，表示少數與絕大多數的對比，它的主要思想是不要平均、對等地看待和處理問題，而是認真分析並找到問題的關鍵點，集中精力於這些關鍵點上，獲得事半功倍的效果。

二八原則也適用於軟件領域，通常的表述：計算機在80%的時間執行20%的常用代碼或是系統在80%的時間使用着20%的常用數據。只是簡單描述不會產生感性認識，下面來看幾個例子。

計算機體系中的存儲結構，見下圖：
[img]http://images.cnblogs.com/cnblogs_com/jeffreyzhao/Learn-Computer-Architecture-For-Performance/1.png[/img]

數據通常存儲於計算機的外部設備上，但每個數據的處理都得經過CPU。正常情況下CPU可以操作的數據只是所有數據的一部分，爲了減少經常通過外接總線取數據的時間消耗，就有了內部存儲器的誕生。同樣的道理，CPU與主存之間儘管有高速總線連接，但無奈處理頻率不一樣，取常用數據的時候CPU還是會等待很長時間，這樣就有了CPU內部寄存器，用於緩存CPU常用的數據。（[i]注：計算機的存儲體系是最初設計時就定義好的，這裏爲了描述方便，還原它的設計過程[/i]）。注意到這裏很多時候提到的一個詞：常用。正常情況下我們會經常操作數據中很常用的那部分，所以基於這種概率的緩存策略是很有用的。

Java因執行速度慢飽受詬病，後來JVM中引入的JIT(Just-in-Time)編譯器用於將常用的Java字節碼編譯爲機器碼保存起來，下次執行時就不用再去解釋這些字節碼，這樣可以有效提高Java的執行速度。同樣，在分析Java對象的生存週期後，就可以對那些大量產生，但有效期很短的對象快速執行GC。JVM的內存分代和GC模型充分考慮到對象生存週期及大小的問題，以正確對待客觀現實的方式解決JVM內存使用的問題。

還有一個值得探討的問題是樂觀鎖與悲觀鎖。正常情況下，我們只會操作表中的少數數據行，這時如果爲了數據一致性而鎖住整個表，就會大大降低DB性能。這種行爲可以說成在80%時間只是操作部分行，少數20%的時間纔會有對整個表的操作。客觀的做法是降低鎖的粒度，以更符合實際情況的行爲來操作鎖。儘管可能增加解決鎖衝突的複雜度，但對DB性能的提高是可觀的。這種DB鎖的問題也出現在程序中，如Hashtable，就可以用ConcurrentHashMap提高併發性能。

在列舉了一些實際問題後發現，很多時候對於事實數據的分析是在程序或是系統出現問題以後才做的，這樣的問題如性能瓶頸，響應時間等。在分析清楚事實數據的本身屬性及系統的癥結之後，就可以有針對性的提出解決方案，用於解決極少數關鍵問題對整個系統的影響。同樣在設計階段，如果能認識到系統中的主要問題，就可以針對性地設計以提前避免瓶頸的出現。

怎樣找到系統的關鍵點，決定於事實數據的屬性，系統的關鍵指標，設計者的經驗等。如果在設計之初不能很清楚地找到關鍵點，就應該採取保守策略，不做任何想法優化，等出現問題時再去處理。這樣的好處是如果爲了解決所認爲的關鍵問題而引入複雜的邏輯，倒是降低了系統的開發和維護成本。

其實在軟件流程上的很多時間，找關鍵點的目的就是爲了優化，提高系統可用性。優化應當以事實數據或是分析報告爲切入點，在不確定關鍵點的時候不能想當然地做優化。以JavaEye前段時間很熱的一個帖子[url=http://www.iteye.com/topic/680130]從小case看大道理[/url]來說。如此優化的前提，應當是在分析完大量數據請求後，明確這幾個狀態碼的請求佔絕大多數，那麼這樣的優化纔是成功的。

二八原則可以有很多解讀，但主要一點就是找準主要矛盾。每個人可以試着分析自己系統或是模塊的關鍵點，花更多心思來維護，以獲得更優的結果。[/size]


[size=medium][url=http://langyu.iteye.com/blog/746179] 我所認識的軟件開發原則：權衡[/url]
[url=http://langyu.iteye.com/blog/744455] 我所認識的軟件開發原則：封裝[/url]
[url=http://langyu.iteye.com/blog/745053] 我所認識的軟件開發原則：簡單表述[/url]
[url=http://langyu.iteye.com/blog/745296] 我所認識的軟件開發原則：減少等待時間[/url][/size]