作者：rossroma9466

https://juejin.cn/post/7404778998632890387

今天带来一位10年老前端的一些思考，看看10年的经验总结下来，有哪些是我们可以学习和借鉴的。作者的观点也不一定适合每个团队或者每个场景，大家还是要结合实际情况来具体分析哈。

下面是正文部分。

开发注意事项

• 考虑边界值：如果要展示一个列表，就要考虑列表为空、列表长度超过一页的情况；如果展示的是文字，则要考虑文字为空、文字超长的情况；访问a.b.c时，a或b是否可能为undefined。

• 考虑特殊场景：如交互状态（hover、disabled、文字提示）、浮点数计算精度（使用utils方法）、防重复提交、分辨率兼容、移动设备兼容、事件冒泡、防抖和节流；

• 考虑需求变更和功能拓展：需求变更是不可避免的，那就要在开发的时候考虑到哪些地方容易变(数值、变量)，哪些不容易变（框架、模式），提前做好设计规划，减少因需求变更造成的大规模重构。

• 考虑代码可读性：复杂方法标注用途、复杂逻辑解释清楚、修改他人代码先理解上下文并做好自测。

• 保持优化代码的好习惯：所有不合理的问题，都是可以改的，代价大，就细致谋划，不要搁置，避免埋雷。

代码越短就越好吗？

实际的业务书写中，如果减少10%的代码换来的是可读性变差，那并不推荐这么做。我们推荐的是，在保证可读性的前提下，尽可能让代码变少。

// bad 三元嵌套三元不利于可读性
let message = (age <3) ?'Hi, baby!' :
(age <80) ?'Hello!' :
 'What an unusual age!';


// good
if (age <3) {
 message ='Hi, baby!';
}elseif (age <80) {
 message ='Hello!';
}else {
 message ='What an unusual age!';
}


// bad
if (company =='Netscape') {
 return true;
}else {
 return false;
}


// good
return company ==='Netscape';

魔法值的问题

魔法值，也叫做魔法数值、魔法数字，通常是指在代码编写时莫名出现的数字， 无法直接判断数值代表的含义，必须通过联系代码上下文分析才可以明白， 严重降低了代码的可读性。除数字之外，代码中作为key值的常量字符串也被认为是魔法值， 尽管其表示含义比数值较为清晰，但是仍然会产生不规范问题。

// 魔法值举例
if(flag ==='5'){
 .......
}


if (businessType ===101){
 .......
}

通常会采用枚举类型来解决魔法值问题，由于JS中没有枚举类型，可以使用对象字面量的方式来模拟枚举，如下：

constBusinessTypeEnum = {
 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){
 .......
}

采用枚举的另外一个好处，当某个值因为需求迭代需求变更时，我们只需要在枚举中将该值替换，并不需要在全局搜素替换。

程序中的电车难题

如图，当一辆电车快速驶来，无论图上的人采取哪种选择，似乎都是错误的。

但是，在程序中出现预期之外的错误必须要导致一个负面结果时，一定要选择代价最小的。

举个例子： 某同学开发了一个新手引导弹窗功能，该功能有个透明的全屏遮罩，只有当新手引导结束时，遮罩才会消失。由于程序中存在一处逻辑判断不严谨，导致在特定情况下全屏遮罩不能被关闭，然后整个系统都不能被点击了。一个简单的新手引导功能却引发了系统不可用的严重故障，这是非常大的代价。

通过上述例子去分析，系统不可用的负面影响远大于新手引导不可用。因此，我们应该修改逻辑判断方案，当程序脱离预期执行时，直接去关闭新手引导。

// before
if (step ===0) {
 dialog.close()
}else {
 dialog.show()
}


// after
if ([1,2,3].includes(step)) {
 dialog.show()
}else {
 dialog.close()
}

我们无法保证自己写的代码没有任何差错，但是我们可以提前考虑，万一发生预期之外的错误，我们要如何处理来让损失最低。

不要让用户等待

由用户触发的交互操作，应立即给予响应。立即响应不等于立即呈现数据，有些异步操作，无法立即呈现数据给用户，但应马上给予loading提示，告知用户数据正在处理中。

下面的代码中，用户点击编辑按钮时，会先发起一个异步请求，拿到数据结果后再显示弹窗。这个短暂且没有任何提示的等待，会让用户认为是程序卡顿，体验不畅，间接诱导用户重复点击按钮。

正确的做法应该是先展示弹窗，再去请求数据。

三元和if该怎么选？

// 如果条件表达式后面跟的是返回值，建议使用三元运算，如下方的例子，就可以优先考虑使用三元运算
// good
a > b ?1 :2


// bad
if (a > b) {
 return1
}else {
 return2
}


// 其他复杂的分支代码，写成三元可能并不利于阅读，建议使用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的数字，参考如下代码：

let numArr = []
let i =1
while (numArr.length <10) {
 if (i %3 ===0 || i %5 === ) {
numArr.push(i)
}
 i++
}

while在某些场景下，可以代替递归函数。比如我们希望得到100以内的斐波那契数列：

// 使用递归
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只能在部分场景中来代替递归。