爲何要花80%的時間去設計，再用剩下的20%時間去實現？

2019立刻就要過去了。相信臨近年末的你必定和我同樣有好多事情須要處理，好比：寫年終總結PPT、制定下個季度OKR、需求討論、技術方案設計、開發小夥伴找你調接口、產品小夥伴找你聊可行性等等，固然還有最重要的刷火車票。

時間緊、任務重，我該怎麼辦？

這許多事情堆積到一塊兒佔用了大量的時間和精力，因此此時此刻留給開發的資源就更加緊張。

就是在這種狀況下，我接手了一個任務。我該怎麼儘量高效的完成它？

若是咱們跳過跳過設計階段...

權衡之下咱們選擇了跳過詳細設計直接寫代碼。

好一陣埋頭苦幹後終於完成了任務，把鍵盤往前一推，心滿意足地靠在椅子上，不由感慨：「無他，惟手熟爾」。但再擡頭看看時間：什麼！這點玩意兒竟然寫到了飯點兒？頓時從虛假的成就感中驚醒了。

爲何這種爲了節省時間而採起的措施最終反而卻浪費了時間？實際上問題的根源是由於跳過了設計階段。

舉例來講，假設需求是要把一個包含產品名稱和價格JSON數據以key:value描述列表的方式展現在頁面上。代碼很簡單：

Object.keys(data).map(key=><span>{key}：{data[key]}</span>)

是否是 so easy ？運行一下看看效果：

price：13.5

emmmm，JSON內的key都是英文的，得把它轉換爲對應的中文才行。這也好辦，建一個Map存儲key和中文的映射便可：

const keyNameMap={
...
price:"價格"
...
}

Object.keys(data).map(key=><span>{keyNameMap[key]}：{data[key]}</span>)

此次輸出就沒問題了：

價格：13.5

可是demo多跑幾回後發現，因爲哈希表的特性，致使每次渲染不一樣的數據，其key的位置是不固定的。這對於用戶來講很不友好，繼續改：

const sortedKeyList = ['price','productName',...]
const keyNameMap={
...
price:"價格"
...
}
sortedKeyList.map(key=><span>{keyNameMap[key]}：{data[key]}</span>)

這樣就保證了key的位置是固定的。然而不幸的是需求發生了一點點偏移：咱們認爲顯示的是產品價格數據（Product），但實際上這個組件還須要支持身高體重性別類型數據（Person）、車牌號行駛證號排量型號數據（Vehicle）等幾個類型......

細心如你必定發現了，這段代碼不只存在複用性不夠的問題，並且健壯性也不夠。這一切都是由於咱們急於動手而沒有進行充分的設計，因而按下葫蘆浮起瓢，彷彿一個試圖挽救一條處處是破洞的小船的水手，一邊堵着破洞、一邊又要往船外舀水。

好的實現須要有好的設計

若是一開始就進行設計的話，上述示例適合使用策略模式進行封裝，針對不一樣的數據類型分別處理，而後統一進行渲染。這樣既符合單一職責原則，也符合開閉原則：

• 單一職責原則：分離關注點，在這個示例中表現爲數據與渲染分離。數據的異常不會影響渲染，反之亦然；
• 開閉原則：對擴展開放，對修改閉合。若是有新的數據類型須要渲染，咱們只須要在策略組中進行擴展便可，而沒必要修改原有功能。

示例代碼以下：

// 策略組
const strategies = { 
    Product:(data)=>{
        let formattedList=[]
        // 處理數據
        return formattedList
    },
   Vehicle:(data)=>{
        let formattedList=[]
        // 處理數據
        return formattedList
    },
}
// 渲染方法
const renderItem=(itemList)=>{
    itemList.map(item=><span>{item.name}：{item.value}</span>)
}

經過上述的簡單設計，咱們不但顯著的提高了代碼的可擴展性、可讀性，並且下降了維護成本。

請多花一點時間在設計上！

我大學老師曾經提及他學計算機時寫代碼都是要在腦子裏跑一遍感受沒啥問題後才捨得排隊去上機。現在機器不是什麼稀缺資源了，可是咱們的時間精力仍然寶貴。因此爲了可以早點下班、少撓頭，請多花點時間進行設計！