After four months of brick moving, I went through all 139 bugs pointed at me in the afternoon, and found some facts that more than 90% of bugs are caused by insufficient understanding of business requirements, and only a very small number of bugs are caused by the mastery of language grammar.

Here are some typical bugs at the coding level. (The preceding number is the bug number and can be ignored)

ForEach () is not a function. ForEach () is not a function. Similarly, can not read property XXX of undefined and can not read value of filterCourse[0]. These JavaScript language design problems cannot be found in the code, it is up to the developer to consider more comprehensively in the development process. This is why TypeScript has recently become popular, changing JavaScript’s dynamic typing to static typing.

The return value of the 3251 toFixed() method is a string representing the given number in fixed-point notation. If you use the return value directly for numerical comparisons, there will be truth exceptions. The comparison of strings is based on the ASII value of each character. For example, in the following example, the ASII value of 9 is greater than that of 1, so the truth value of “90” > “100” is true. But the truth values obtained by direct string comparisons are not always wrong, as in “1” > “22” below. And if you use the toFixed() method in a project utility function without processing the return value, the impact is very wide.

// LLDB uses string comparison
"90" > "100" // true
"1" > "22" // false

// LLDB converts to Number type comparison
Number("90") > Number("100")
Copy the code

The following is a bug I encountered in the production environment. The requirement is that the current score above the dotted line should show green, but since “100” > “88” is fasle, the color display is wrong.

3278 An error occurs when the number of new roles is too many. The length of the front and back fields is inconsistent. This bug is typically the result of development with inadequate communication between the front and back ends. The need for new characters, for example, may not be noticed at such a small point when the product makes requirements; In the design of the table structure, the length is limited according to the previous development experience. From the back end to the front end there is usually only information about an interface (such as URLS, request types, and parameters). When retrieving the user’s role name, neither the backend nor the product mentions the length, and if the front end is not sensitive enough to check with all parties, then a bug occurs.

After going through these bugs, I felt that the requirements were clearly and fully understood, and the implementation of features was just a matter of course. In addition, in the specific development, the product cannot be fully considered in the first design of requirements, so if we can predict the hidden requirements not mentioned in the product during development, I think it will be obvious to improve the development efficiency. For example, the new characters mentioned above have too many words.