2019 will soon be over. I believe that you must have a lot of things to deal with as I do near the end of the year, such as: writing year-end summary PPT, formulating OKR for the next quarter, demand discussion, technical scheme design, adjusting interface with development partners, discussing feasibility with product partners, etc., and of course, the most important thing is to brush train tickets.

What should I do if I have a tight schedule and a heavy task?

All of these things add up to a lot of time and effort, so the resources left for development at this point are even tighter.

It was in this context that I took on an assignment. How can I do it as efficiently as possible?

If we skip the design phase…

On balance, we skipped the detailed design and went straight to the code.

After a long period of hard work, I finally finished my task, pushed the keyboard forward, and leaned back in my chair contentively, saying, “There is no one but my hand.” But look up at the time again: What! How is this supposed to be on the menu? Suddenly woke up from the false sense of achievement.

Why does a time-saving measure end up wasting time? In fact, the root cause of the problem is skipping the design phase.

For example, suppose the requirement is to display a JSON data containing the product name and price as a list of key:value descriptions on the page. The code is simple:

Object.keys(data).map(key= ><span>{key}, {data [key]}</span>)
Copy the code

Is it so easy? Run it to see what it looks like:

Price: 13.5Copy the code

Emmmm, the key in JSON is in English, it has to be converted to the corresponding Chinese. Create a Map to store the key and the Chinese mapping:

const keyNameMap={
...
price:"Price". }Object.keys(data).map(key= ><span>[key] {keyNameMap} : {data [key]}</span>)
Copy the code

This time the output is ok:

Price: 13.5Copy the code

However, after several runs of the demo, it was found that due to the characteristics of the hash table, different data was rendered each time, and its key position was not fixed. This is not user friendly, continue to change:

const sortedKeyList = ['price'.'productName'. ]const keyNameMap={
...
price:"Price". } sortedKeyList.map(key= ><span>[key] {keyNameMap} : {data [key]}</span>)
Copy the code

This ensures that the key’s position is fixed. However, unfortunately, there is a little deviation in demand: we think it shows Product price data, but in fact, this component also needs to support several types such as Person, license plate number, driving license number, and displacement model data……

Careful as you must have noticed, this code is not only not reusable enough, but also not robust enough. It was all because we were so eager to do it that we didn’t design it well enough, so we floated the gourd, like a sailor trying to save a boat full of holes, plugging the holes and bailing out.

Good implementation requires good design

If you’re designing from the start, the examples above are suitable for encapsulation using the policy pattern, processing each data type separately, and then rendering it uniformly. This is consistent with both the single responsibility principle and the open and closed principle:

  • Single responsibility principle: Separation of concerns, in this case data and rendering separation. Data anomalies do not affect rendering and vice versa;
  • Open closed principle: Open for extension, closed for modification. If there is a new data type that needs to be rendered, we can just extend it in the policy group without modifying the existing functionality.

Example code is as follows:

/ / policy group
const strategies = { 
    Product:(data) = >{
        let formattedList=[]
        // Process data
        return formattedList
    },
   Vehicle:(data) = >{
        let formattedList=[]
        // Process data
        return formattedList
    },
}
// Render method
const renderItem=(itemList) = >{
    itemList.map(item= ><span>{item name} : value} {item.</span>)}Copy the code

Through the above simple design, we not only significantly improve the extensibility and readability of the code, but also reduce maintenance costs.

Please spend more time on design!

My college teacher once said that when he was learning computer, he had to run the code in his head before he could wait in line to get on the computer. Machines are not a scarce resource these days, but our time and energy are still precious. So in order to leave work early and scratch your head less, spend more time designing!