JavaScript复杂代码的优雅实现

压力巨大啊:
一般都是迭代出来的，随便重构别人的代码要担责任的

锋铓:
除了官方提供的es6解构赋值语法，所有的情况，都有例外，而这个例外在编程中恰恰是非常高的频率会遇到，即便没遇到也要为将来打算，假设遇到了怎么办？ 然后写了一堆冗余代码。 最后变成了啥？ 明明是简单粗暴干脆利落的解决方式，即便是刚入门的程序员，也能看懂的代码，强行被变成了所谓的优雅做法，把一大堆初级程序员拦在门外。 看似优雅，但是跟不写注释，瞎写注释，乱起变量名等防御性编程手段，异曲同工。 当然，更上一层楼，后者会被人说，被人一看看出你在捣乱，前者不一样，这是大神，你看不懂，是你菜。[笑哭]

【回复】回复 @小昕有雨 :前人已经堆了，你接着堆就行。 往往这种大段的ifelse里面嵌套了大量的面向过程编程代码。上面的简单的优化手段，几乎全部没有用。
【回复】当然，即便不考虑边界判断，没有冗余代码。 还是有问题，比如那个新增了数组变量的。 比如，评论区那个举例子，明明是一个对象一个属性，却新增了一大堆的属性，且以后会越堆越多。 只能说，现在“富裕”了，所以程序员，越来越有“条件”追求所谓的优雅了。 那我几年前的老电脑老手机举例，当年也是“大杀四方”的存在，看视频，玩游戏，上网页也没见得有什么干不了的。 现在是同样的需求，也没见有什么新增的不可替代的功能，但是卡到怀疑人生。 我记得当年开发，为了所谓的“优化”，无所不用其极，甚至网页中一堆图片，要压缩到一起搞成精灵图。一个酷的特效，带不动，要转成gif图。 现在的有条件了，不考虑那么多了，内存占用飙升。 都是代码中，所谓的优化，一行这么写没事，10万行呢？要新增多少变量，多占用多少内存。[呲牙][笑哭]
【回复】条件简单的if-else当然可以不动，但对于复杂逻辑，恰恰是这种写法增强了代码可读性和可维护性。长达500多行的if-else，判断条件乱七八糟，操作内容颠来倒去的代码：这种所谓简单粗暴的方式维护起来异常痛苦，光看懂就要花很多时间，更别说改里头逻辑异常导致的bug了。 至于把初级程序员拦在门外，这也没啥高深的东西啊[笑哭]人不能总在原地踏步吧
随便懒得起名字了-_-:
我就非常写这种，尤其是React中，直接映射组件，简洁明了，但是对于复杂业务逻辑还是老老实实if else，不要折磨自己折磨别人[吃瓜]

故乡再无春秋夏:
up的办法确实挺好的，但是不适合第一遍写。一般情况下第二遍才会去优化，没时间可能就不优化了[笑哭]

铁头小狸:
javascript要特别注意特殊值的存在，null,undefined,NaN，判断数组有没有元素不能包含NaN值，他自己都不等于自己，所以还是有一定局限性。对象属性值存在但值为undefined也没法判断，建议不要乱用特性，多个判断不想用if就用switch就好了。

番薯Vilo:
自己写哪怕写成火星文都没人管，只要你自己能维护！别人写的哪怕就是一坨屎你也得接受，除非你有能力不让整个项目出什么逻辑bug

蓬头人:
这不算不优雅吧，恰恰这样非常清晰易读

没有什么不利的:
视频里不太优雅的方法反而逻辑更清晰，更直观。

【回复】但是一般都是用对象的方式去匹配返回值的，这样写法多太多好处了，走判断你可能菜鸟能看的清晰，但是你自己维护修改都要多写if那本末倒置了
【回复】回复 @没有什么不利的 :对象属性的方法一样能调用方法，封装下就行了
【回复】回复 @这是一只大母鹅 :关键是大部分用if else不会，只是返回一个字符串，中间还有一些其他的逻辑。
咕力咕力动漫:
只要能跑起来，那管优雅不优雅，反正电脑又不懂什么优雅![呲牙]

黄古条:
越直观和易读，同时保证性能不差。就是最好的。

tfgbyfhgys:
刚毕业的时候看老代码：这什么屎山代码？干了一段时间，理解屎山，创造屎山

本期风娃:
一般情况下不可能这样简单的写，大部分都是根据条件执行不同的操作，根本是无法优化的，这种写法一般用于演示，实际项目写法请勿参考up主的优化

【回复】回复 @这是一只大母鹅 : 是可以写，但是这样写的目的是什么？目的可能是优化，但是为了优化又引入新的复杂操作，后面又需要优化这个为了优化前面需要优化的地方的操作，结果就是套娃，实际上造成负优化。 简单点说，就是别为了优化而优化，绝大部分代码其实并不需要多此一举！
【回复】对象里一样可以储存方法，这样就是正常写法啊
【回复】反正能跑就行，帮别人擦屁股小心到时候自己手上全是💩
章鱼丸子怪:
何必呢？我们要求的代码就是越简单越好，甚至不允许有太多的个人风格。因为项目换人是很正常的，我们要求的就是人人能够接受。什么是人人都能接受的，那就是大学课本里面教的那种中规中矩的。还有就是，代码不是你程序员的，是公司的

【回复】我们要求的代码恰恰是：当if中对同一个参数的两个及以上的可能值进行同样的判断处理时，改用【】.includes，为的就是阅读和维护。
椒香兔头:
从性能角度改用switch我还能理解，但这，还有调别人封装的方法或者用个语法糖把自己牛逼坏了的，就算不知道编译后的代码，没运行过看下效率？优雅只存在于运行效率和可读可维护性综合上，还以为自己是马思克呢

贴吧交换生:
写的简单容易扩展挺好的别人看得懂 能跑就行