對於80/20法則，我想很多人都比較熟悉。該法則認為，你80%的成就來自於20%的努力；或者80%的收益來自20%的客戶。運用到軟體領域，那就是你80%的客戶往往只使用你軟體20%的功能。因此我們自然會問，在軟體開發的過程中能否只留其中20%的功能，而砍掉其餘的80%呢？著名博主
john d. cook
認為很困難。
事實上，很多人是反對這個推理的，下面是他的反對理由：
或許你的每一位客戶只會使用整個軟體很小的一部分功能，很多情況下沒有人使用的功能會超過5%。但是所有的客戶都在使用著不同的功能，當你把每一位客戶使用的5%加在一起時，你會發現所有的功能都會被使用。比方說微軟的辦公軟體word很大，我很懷疑有多少人使用該軟體的功能會超過1%，但是其每乙個功能都可能會在其它地方被使用到。
這是乙個非常關鍵的點，相比於實現這些功能之前，其實現之後也許才是最重要的。一旦發布了乙個新的功能，就會有人去使用它；而一旦有人習慣了使用這些功能，那麼他們就想要繼續使用它。
假設你的軟體提供了解決某項任務的兩種不同方案：方案一和方案二。一半的使用者選擇了方案一並且已經對此感到滿意，而另一部分使用者則選擇了方案二。此時你不能說把其中的任何乙個解決方案去掉，因為去掉任何乙個都會令其中的客戶感到不爽。但是如果一開始就只提供方案一，那麼所有人都會使用這個唯一方案並且不會感到不爽。
去掉一些功能幾乎是不太可能的事情，如果要簡化現有產品，那麼你往往會冒著得罪客戶的風險。但是當你一開始就提供簡化的產品時，同樣的這些客戶不會有任何意見並且樂於使用。
或許這也是為什麼有些軟體我們使用起來感覺很複雜，覺得很多功能完全沒有必要但是它仍然存在的原因。因為當我們創造了乙個新的功能時，可能就培養了乙個新的行為習慣，此時要改變這些行為習慣，面臨的阻力就會比較大。當然這就給許多創業團隊帶來了機會，比方說雲端筆記evernote。從功能上說，微軟的onenote要比evernote強大許多，但是為什麼evernote仍有機會取得成功呢？或許這就是微軟很難將onenote簡化所帶來的機會吧！
如果我們能在軟體功能發布之前就**到哪部份屬於20%，哪部份屬於80%，那麼……。當然，如果是這樣，可能就不會有後來者太多機會了。
軟體設計中的演算法
說到演算法這一塊，有大量的知識等著我們去了解，去學習，去 定義 演算法是對特定問題求解步驟的一種描述，它是指令的有序序列，其中每一條指令表示乙個或多個操作。特性 1 有窮性 finiteness 演算法的有窮性是指演算法必須能在執行有限個步驟之後終止 2 確切性 definiteness 演算法的每...
軟體設計中MV模式的應用
軟體設計中mv模式的應用 平時在基於j2ee的軟體開發中，時不時的會用到struts框架，這個框架是mvc模式的經典之作。mvc模式介紹 model 作用是根據前台請求資料呼叫後台業務處理並返回處理結果 view 就是前台顯示介面 controller 控制就是聯絡model和view的作用，根據某...
關於軟體設計中遇到的問題
在最近開發乙個專案的過程中遇到的一些純軟體的問題 1 整個軟體的功能劃分在已開始是明確的，但是隨著程式的編寫以及一些結構的調整，各個模組之間的聯絡越來越緊密，特別是事件相關的邏輯，地圖分析 實時事件報警 歷史事件查詢 事件回放等，都要用到事件，都要讀取事件。導致了這幾個模組之間的強耦合。2 有一些類...