为何要花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>)
}

经过上述的简单设计，咱们不但显著的提高了代码的可扩展性、可读性，并且下降了维护成本。

请多花一点时间在设计上！

我大学老师曾经提及他学计算机时写代码都是要在脑子里跑一遍感受没啥问题后才舍得排队去上机。现在机器不是什么稀缺资源了，可是咱们的时间精力仍然宝贵。因此为了可以早点下班、少挠头，请多花点时间进行设计！