80/20法則下的設計

軟體的設計從某種角度來看是一門藝術。就像是大師的設計，有時實在會讓人不禁感嘆其精巧及絕妙。可是，除了具有藝術的特質之外，從別的面向來看，軟體設計同時也處處充滿了需要算計的現實問題。

在我們的開發經驗中，時常會提到「軟體工程」這個名詞。雖然軟體開發本身兼具科學及工程的特性，但是當我們用工程而非科學的角度來檢視軟體開發時，該項觀點所重視的實用性，就會變得相當重要。

若我們用工程的觀點切入來看軟體設計的工作，軟體設計的工作基本上是一門「取捨」的學問。這個領域經常面臨許多實際上的限制，例如時程、人員、硬體設備的等級、產品的規格、需求的範圍、維護的難易與否……，這些都是實際面臨到的各種限制。

想要面面俱到，現實中難以達到
就拿極限編程（eXtreme Programming）來說吧！在這個開發方法中認為，影響到軟體開發有四個主要的因素，分別是成本、規模、時程、品質。這四個主要的因素之間相互交錯影響，只要更動了其中之一，很難不同時牽動其餘三者。例如，想要縮短所需的開發時程，就一定得投入成本、或者（並且）縮小規模、或者（並且）降低品質。

事實上，每個開發團隊都期盼能夠最佳化這四項因素，希望自己所開發的產品或服務，成本最低、規模最大、時程最短、品質最好。但完美的事經常不存在於人間，所謂的「工程」，就是要面對現實。這四者不可能同時都達到極致，真正的最佳狀態，往往是落在均衡的中間地帶──具有一定的品質、在有限的預算及既定的時程下，盡可能地提供最多功能。

我時常反覆地提到：「軟體設計就是一連串設計決策的過程，在這個過程中，我們會有很多設計上的限制條件存在，而設計者的任務，就是在這些限制條件的約束下，盡力達到最好的結果。魚與熊掌不可得兼是千古不變的道理……」一個好的設計者，通常不會僅針對單一特性最佳化，例如，我們並不會試著設計出最有彈性的系統，因為這種系統，通常會有最糟糕的執行效率。

正因為可能的限制條件繁多，而且又不可能針對單一或多個因素盡可能地最佳化，因此，設計者的主要任務之一，便是拿捏其中分寸，針對諸般需要，從中取捨。許多錯誤的設計決策，往往就源自於錯誤的取捨，例如之前提過的「設計的過度工程化」便是取了過多的需求或彈性而引發的問題。

設計上的取捨，自然是一門極大的學問。對大多數的設計者來說，在面對設計上的抉擇時，通常不知從何下手。其實方法並不複雜，大多數的取捨決策，只需要把握所謂的「80/20法則」就行了。

善用80/20法則，發揮以小博大效應
「80/20法則」又被稱為「帕雷托法則（Pareto principle）」，維基百科上對這個條目的解釋是：「在眾多現象中，80％的結果取決於20％的原因」…例如，在電腦系統中，80％的資源是由20％的活動所使用，所以想要最佳化對這些資源的使用，就必須針對這20％的活動來著手。有些人將80/20法則稱為「最省力法則」，因為80％的收穫源自於20％的努力，其餘20％的結果卻必須付出80％的力氣才能獲得。善用這種因與果之間不平衡的自然現象，就可以發揮以少博多的槓桿效應。

在設計上所面臨的許多限制條件，彼此之間往往是相衝突的。好比，我一再提到的彈性和複雜度的取捨──想增加彈性，就得付出提高複雜度做為代價，到底我們需要多少彈性？又得付出多少複雜度做為代價，才能換取到這些彈性呢？我們在購買各種商品的時候，常常會談到C/P（Cost/Performance）比的概念，事實上，設計上的取捨也可以套用相同的觀念。究竟我們以多少的A去換取多少的B是最划算的呢？而80/20法則就是在告訴你，要適當運用、操作20與80這種不平衡的因果關係，而且就因為這種情況，使得槓桿效應得以發揮作用。

就好比，在許多系統的開發中，付出20％的複雜度，多半可以換取到80％的彈性，但想要得到100％的彈性，又得付出其餘的80％的複雜度。對我們來說，用20％的複雜度去換80％的彈性，是C/P比最高的。

綜合現實上的各種因素，理性考量
如同前述強調的：「軟體設計同時也處處充滿了需要算計的現實問題」。軟體設計者有時就得像是拿著算盤精打細算的生意人一樣，希望所投入的每一分心力，都能得到最佳的回報。倘若對我們來說，只需要提高20％的複雜度，就能增加80％的彈性，但是如果要再多付出其餘的80％的複雜度，才能得到最後的20％彈性，達到百分百完美的境界，那麼是否該考慮放棄那最終20％的彈性呢？

最近我有一個經驗，負責管理產品的同事針對某一項功能的實作程度並不滿意。倘若從產品的規格來看，其實，那時的實作是否符合規格，是處在一個模糊的地帶。有爭議的規格是一條關於權限控管的功能，用來防止盜版的使用者無法使用該系統。就「無法使用」四個字來說，是有點抽象的，因為讓使用者完全無法用是一種，讓使用者用起來極為麻煩，使得他根本就不想用，也是一種。就這個規格來說，防止非法的使用者的動作，可以從基礎的做法著手，進而防範到非常嚴密的程度，但系統所需要付出的效能代價也截然不同。如果只做基礎的措施，系統就只需要付出額外20％的效能代價，但是如果想做到極為嚴密的防範，系統卻需要額外再付出80％的效能代價。

從產品管理者的角度來看，多半希望達到幾近百分之百的防範，但從設計者的角度來看，不能只看到功能面上是否能達到完美，他還必須考量許多其他的限制，並從中取捨。就拿這個防範動作來說，為了做到更嚴密的防密，系統必須額外加上負擔更重的檢查機制，進而大大地犧牲掉系統的效能。如果百分之百的防範是必要的，那麼系統的效能就必須犧牲，無庸置疑。不過關鍵即在，倘若回過頭來檢視需求，其實只做到基礎的防範功夫，仍是可以接受的。

以少做多，更貼近現實需求
我們有時會盲目地、不可克制地，想要去追求100％完美的東西，但事實上，認真的把自己拉回來冷靜的檢視需求，其實我們要的並沒有那麼多，我們只需完美的80％。而這樣的結果又時常只需要付出20％的代價就可以取得。系統中有太多的需求必須要被滿足，我們倘若針對每個需求都試圖達到完美，那麼，勢必付出極多的力氣。然而要求百分之百的完美，卻常是許多人陷入迷思陷阱中的產物。

我們通常不需要百分之百的完美，如果從「工程」的角度來著眼，更應該以一種「算計」的心情，來衡量投入的成本以及所得到產出的比例。

80/20法則告訴我們的，並不是80與20這兩個固定的數字，而是告訴我們許多因果之間的不平衡現象。套用在不同的情況下，也許是70/30、也許是90/10。但是，真正的關鍵在於，要去明白這種不平衡的現象，並且適度運用。

當我們的最佳，並不是結果本身的完美，而是投入的成本與所得之比例的最佳時，善用此種法則便能夠幫助我們操作最小的力氣，得到最多的結果。在軟體的設計中，以四兩撥千斤的工程觀點，或許也是另一種類型的藝術吧。

作者簡介：
王建興
清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。