:10年前端的一些开发经验总结 10年前端的一些开发经验总结 10年前端的一些开发经验总结开发注意事项 考虑边界值:如果要展示一个列表,就要考虑列表为空、列表长度超过一页的情况;如果 - 掘金 
开发注意事项 考虑边界值 :如果要展示一个列表,就要考虑列表为空、列表长度超过一页的情况;如果展示的是文字,则要考虑文字为空、文字超长的情况;访问a.b.c时,a或b是否可能为undefined。 考虑特殊场景 :如交互状态(hover、disabled、文字提示)、浮点数计算精度(使用utils方法)、防重复提交、分辨率兼容、移动设备兼容、事件冒泡、防抖和节流; 考虑需求变更和功能拓展 :需求变更是不可避免的,那就要在开发的时候考虑到哪些地方容易变(数值、变量),哪些不容易变(框架、模式),提前做好设计规划,减少因需求变更造成的大规模重构。 考虑代码可读性 :复杂方法标注用途、复杂逻辑解释清楚、修改他人代码先理解上下文并做好自测。 保持优化代码 的好习惯:所有不合理的问题,都是可以改的,代价大,就细致谋划,不要搁置,避免埋雷。 代码越短就越好吗? 实际的业务书写中,如果减少10%的代码换来的是可读性变差,那并不推荐这么做。我们推荐的是,在保证可读性的前提下,尽可能让代码变少。
javascript 代码解读 复制代码// bad 三元嵌套三元不利于可读性 let  message = (age < 3 ) ? 'Hi, baby!'  :  (age < 80 ) ? 'Hello!'  :    'What an unusual age!' ;  // good if  (age < 3 ) {  message = 'Hi, baby!' ;  } else  if  (age < 80 ) {    message = 'Hello!' ;  } else  {    message = 'What an unusual age!' ;  }  // bad if  (company == 'Netscape' ) {  return  true ;  } else  {    return  false ;  }  // good return  company === 'Netscape' ;魔法值的问题 魔法值,也叫做魔法数值、魔法数字,通常是指在代码编写时莫名出现的数字, 无法直接判断数值代表的含义,必须通过联系代码上下文分析才可以明白, 严重降低了代码的可读性。 除数字之外,代码中作为key值的常量字符串也被认为是魔法值, 尽管其表示含义比数值较为清晰,但是仍然会产生不规范问题。
javascript 代码解读 复制代码// 魔法值举例 if (flag === '5' ){  .......  }  if  (businessType === 101 ){  .......  }  通常会采用枚举类型来解决魔法值问题,由于JS中没有枚举类型,可以使用对象字面量的方式来模拟枚举,如下:
javascript 代码解读 复制代码    const  BusinessTypeEnum  = {        SYSTEM : 0 , // 系统         CRM : 1 , // CRM         JXC : 2 , // JXC         UNKNOWN : 404 , // 未知对象类型         CUSTOMER_MANAGEMENT : 100 , // 客户管理         CUSTOMER : 101 , // 客户         CUSTOMER_FOCUS : 102 , // 重点客户         CUSTOMER_DEAL : 103 , // 成交客户         CUSTOMER_FOLLOW : 104 , // 跟进客户         CUSTOMER_PUBLIC : 105  // 客户公海池       }            if  (businessType === BusinessTypeEnum .CUSTOMER ){        .......      }  采用枚举的另外一个好处,当某个值因为需求迭代需求变更时,我们只需要在枚举中将该值替换,并不需要在全局搜素替换。
程序中的电车难题 
但是,在程序中出现预期之外的错误必须要导致一个负面结果时,一定要选择代价最小的。
举个例子:  某同学开发了一个新手引导弹窗功能,该功能有个透明的全屏遮罩,只有当新手引导结束时,遮罩才会消失。由于程序中存在一处逻辑判断不严谨,导致在特定情况下全屏遮罩不能被关闭,然后整个系统都不能被点击了。一个简单的新手引导功能却引发了系统不可用的严重故障,这是非常大的代价。
通过上述例子去分析,系统不可用的负面影响远大于新手引导不可用。因此,我们应该修改逻辑判断方案,当程序脱离预期执行时,直接去关闭新手引导。
javascript 代码解读 复制代码    // before       if  (step === 0 ) {        dialog.close ()      } else  {        dialog.show ()      }            // after       if  ([1 , 2 , 3 ].includes (step)) {        dialog.show ()      } else  {        dialog.close ()      }  我们无法保证自己写的代码没有任何差错,但是我们可以提前考虑,万一发生预期之外的错误,我们要如何处理来让损失最低。
不要让用户等待 由用户触发的交互操作,应立即给予响应。立即响应不等于立即呈现数据,有些异步操作,无法立即呈现数据给用户,但应马上给予loading提示,告知用户数据正在处理中。
下面的代码中,用户点击编辑按钮时,会先发起一个异步请求,拿到数据结果后再显示弹窗。这个短暂且没有任何提示的等待,会让用户认为是程序卡顿,体验不畅,间接诱导用户重复点击按钮。
正确的做法应该是先展示弹窗,再去请求数据。
三元和if该怎么选? javascript 代码解读 复制代码    // 如果条件表达式后面跟的是返回值,建议使用三元运算,如下方的例子,就可以优先考虑使用三元运算       // good       a > b ? 1  : 2             // bad       if  (a > b) {        return  1       } else  {        return  2       }            // 其他复杂的分支代码,写成三元可能并不利于阅读,建议使用if语句,如下面的例子       // good       if  (a > b && b !== 0 ) {        val = a + b      } else  {        val = a - b      }            // bad       a > b && b !== 0  ? val = a + b : val = a - b  while和for该怎么选? for循环往往是用来遍历一个固定长度的可迭代对象,遍历的次数一定是<=可迭代对象的长度,如数组遍历、对象遍历等等;for和while在绝大部分场景下都可以互换,只是部分场景下,使用while会更符合我们的直觉。while循环往往用于不定次数的条件执行 ,即达到目标条件就终止,但我们事先并不知道达到这个目标条件需要进行多少次执行。举个例子,我们希望从1开始,取前10个能整除3或5的数字,参考如下代码:
javascript 代码解读 复制代码    let  numArr = []      let  i = 1       while  (numArr.length  < 10 ) {        if  (i % 3  === 0  || i % 5  === ) {          numArr.push (i)        }        i++      }  while在某些场景下,可以代替递归函数。比如我们希望得到100以内的斐波那契数列:
javascript 代码解读 复制代码    // 使用递归       function  fib  (prev = 0 , next = 1 ) {        if  (next < 100 ) {          return  [next, ...fib (next, prev + next)]        }        return  []      }            // 使用while       functon fib2 (n = 100 ) {        let  prev = 0         let  next = 1         let  result = []        while  (next < n) {          result.push (next)          const  temp = prev          prev = next          next = next + temp        }        return  result      }  上面的例子很难用for循环去实现,因为我们并不知道100以内存在多少个斐波那契数字,但知道终止条件是数字必须小于100,因此更适合用while循环来实现。再来说说递归和while,递归往往在代码量上来看是简洁的,但本质上它是一个N层的函数嵌套,所以直觉上不易理解,且耗性能(不考虑尾递归优化的前提下);while循环只有一层嵌套,所以直觉上更容易理解,且性能更优。这里并不是说递归不好,不推荐大家使用,一来性能并不是大家首先要考虑的问题,二来while只能在部分场景中来代替递归。