有時我們會告訴客戶，對于該原則，要問3個“如何”，即如何簡化范圍，如何簡化設計，如何簡化實施。
1.如何簡化范圍
這個問題的答案是:經(jīng)常應用帕累托法則(也稱為80-20法則)。80%的成果來自于20%的工作嗎?對于我們的情況，直接問“80%6的收入來自于20%的功能嗎”。少做(只做20%的工作)多得(得到80%的收益你的開發(fā)組就能有時間做其他的事情了。如果去除產(chǎn)品中不必要的功能，那么你的工作效率就能提高5倍，產(chǎn)品的復雜度也會大大減小。如果只有1/5的功能，那么毫無疑問，功能之間的依賴關系就會減少，從而擴展起來更容易，擴展成本也會更低。此外，節(jié)省下來的809%的時間既可以用于開發(fā)新產(chǎn)品，也可以用于提前考慮產(chǎn)品將來的擴展需求。
不止是我們在思考如何在減少不必要功能的同時保留主要功能。37signals中的很多人對此方法都很擁護，他們在自己的書《重來》(Rework2)和博客“You Can Always Do Less”(你可以做得少一點) 中都討論過減少工作的必要性和所帶來的好處。事實上，“最小可行產(chǎn)品”這一概念是由 Eric Reis提出，由 Marty Cagan傳播開來的，它的依據(jù)是“用最小的努力得到最有效的客戶需求”這一理念。這種敏捷開發(fā)方法使我們可以快速地發(fā)布簡單且容易擴展的產(chǎn)品。如此我們的公司就能夠得到更大的產(chǎn)品生產(chǎn)力(公司可擴展性)，把時間用于構(gòu)建少數(shù)有更高可擴展性的產(chǎn)品上。通過簡化范圍，我們將具有更高的計算能力，同時工作得更少。
2.如何簡化設計
范圍縮小后，簡化實施的工作就變得容易了。簡化設計與過度設計的復雜度緊密相關。減少復雜度是刪除工作中不必要的部分，而簡化則是要找到一條捷徑。在原則1中舉過一個例子，把se1e1lct(大)from schema_name.tabe_name改為為 select(co1umn) from schema name.tabe_name，只查詢你需要的結(jié)果。簡化設計的方法則建議我們首先看看要查詢的信息是不是已經(jīng)存在于本地資源(例如本地內(nèi)存)中了。減少復雜度是為了減少工作量，而簡化設計是為了工作得更快更容易。
假設我們要讀一些源數(shù)據(jù)，對這些源數(shù)據(jù)中的中間令牌進行計算，然后把這些令牌綁定起來。在許多情況下，這個假設中的每個動作都可以被分解成一系列服務。事實上，這種方法和流行的Map-Reduce算法采用的方法類似。這種方法并不過度復雜，所以不違背原則。但是如果我們知道要讀的文件很小，不需要跨文件綁定令牌，那么開發(fā)一個簡單的整體式的應用，比把它分解為多個服務更合理。再看看前面的打卡系統(tǒng)的例子，如果目的只是計算每個員工的工作時長，那么用多個克隆的整體式應用讀打卡系統(tǒng)的隊列并執(zhí)行計算則更合理。簡而言之，簡化設計這一步會要求我們用一種容易理解、低成本、可擴展的方式來完成工作。
3.如何簡化實施
最后，來看看實施的問題。與原則2(實現(xiàn)可擴展性的D-I-D方法)致，這里的實施定義為解決方案的實際編碼工作。此日時要面臨的問題是用遞歸還是循環(huán)更合理?應該定義一個固定大小的數(shù)組，還是應該在需要時動態(tài)分配內(nèi)存?應該開發(fā)一個解決方案，還是應該采用開源的解決方案，還是應該購買一個解決方案?這些問題有一個相同的考量，即如何利用他人的經(jīng)驗和現(xiàn)有的解決方案來簡化我們的實施。
考慮到我們不可能事事精通，所以首先應該查查找能滿足我們需求的、被廣泛采用的開源解決方案或者第三方解決方案。如果沒有這樣的方案，應該在公司內(nèi)部詢問是否有人已經(jīng)開發(fā)了能解決該問題的可擴展方案。如果沒有專用的解決方案，那么應該再從外部尋找，是否有人描述過解決該問題的可擴展方法，而且我們可以合法地復制或模仿?只有當這三種條件都不成立時，才應該嘗試自己解決該問題。最簡單的網(wǎng)站建設實施方法都是已經(jīng)被實施過且被證明是可擴展的方法。
本文地址：http://m.murenxiang.com.cn//article/3444.html
