哎呀，给我逗乐了，我真没忍住笑出来了

看着像我上家的代码一样 里面基本上都是这种东西 都几行几行长

不懂就问，这个三条线的是啥玩意 /害怕

@amon 三个等于

@amon #2

@veture 哥，大发慈悲的告诉我，你上家是哪家，也许我们就是一家人！

js 中 === 我知道，这个三条线的是字体还是特殊符号？
@Baymaxbowen
@ma836323493

@amon 字体效果

知足吧，这个好歹还能看懂。 总比看不懂好。

@amon 有的字体有 ligature ，即连字效果。

那我不得不提这张图了
https://imgur.com/a/AMaB9bB

@hefish 屎马拉雅山上一片雪花中的其中一个原子罢了

想看看你优化后，这段代码是什么样

挺直观的

很多人根本不知道如何让 if 变得可读，最起码

const isSomeTypedOrder = item.orderType === 4 || item.orderType === 5
const isSomeKindOfOrderStatus = item.orderStatus !== 2 && (...)
const isXXX = ...

if (!isSomeTypedOrder && isSomeKindOfOrderStaus || ...) {
// ...
}

然后再在代码旁边写上注释解释一下这个业务的意思和为什么要写这个条件

有逻辑的人会自动本能地将条件一条一条按照逻辑摆放清楚，不需要额外教育；没逻辑的人会因为在代码和需求的上下文的频繁切换中大脑过热而降频，为了完成任务只能将一坨判断表达式写在一起，本质是脑袋不清楚

另外还有一些人用一个字母代表一个变量，问就是这个字母周围的代码很简单读读就懂了没必要写全，那么我只能祝福你早日下班

https://imgur.com/a/XXPA1NW
看看我公司其他团队写的组件吧

像极了让干活又不肯给钱的时候

export enum E_OrderType {
/**
* 这是 A
*/
A = 1,
/**
* 这是 B
*/
B = 2,
}

export enum E_OrderStatus {
/**
* 这是 A
*/
A = 1,
/**
* 这是 B
*/
B = 2,
}

export interface IOrderItem {
orderType: E_OrderType
orderStatus: E_OrderStatus
paidAmount: number
}

function isOrderXXX(order: IOrderItem) {
// example
return item.orderType === E_OrderType.A || item.orderStatus === E_OrderStatus.B || ...
}

上 TS 辅助把

@wuzzispacelake 是吧……我都想不通什么情况下才会写这种代码

我想可能是前期没约定好后端 xjb 加状态加字段改接口...这是我转后端的原因之一....

@amon 三条线这个是 IDE 搞的花里胡哨的东西

@wapzjn 真的逆天

还给你分行对齐，不错了。

@aikilan 一个做知产的公司

周易八卦

@wuzzispacelake 多此一举没事找事，那个 if 比你写的这玩意可读性高多了，跟你怎么写没关系，而是系统设计的问题，有两种可能，一是后端偷懒只提供一个接口，二是项目是在迭代过程中条件不断增多

第一步尝试懂了这段代码或者在这基础上加点代码能实现需求
第二步举一反三继承并扩展这段代码的风格，
然后你发现你就是公司核心骨干人员了，优化毕业之类的情况你永远是最后的人选。

@darkengine 让我想到了 apl 代码

后端菜，写的代码 没用枚举型或者枚举型没明确给 Json Serializer 和 Deserializer ，定制了 json serializer 后就有可读性了。

@zhonj 写这段代码的人被优化了已经，以为拉屎可以防住裁员，实际老板不知道你在拉屎，该裁还是裁

@dyv9 给了……而且我们接口自动生成，枚举值也一步到位

四年前刚入职时，公司前端专家的代码：

@aikilan #30 说明这个人还是不够核心，写边缘代码，所以要在核心处写高级代码，让所有人都看不懂。
这样做的好处大大的，首先还是那个说法写的乱七八糟的东西越多让别人看不懂，写到核心处，没人敢轻易裁你。其次哪怕裁了你，说明是个垃圾公司就应该毁灭，你写的高级代码会导致公司要改会消耗大量时间，你不爽么？

@aikilan #30 我朋友上家公司写的代码没一行注释，核心代码极其恶心复杂，可以理解为跑一个 springboot 买本地服务器起了一整套 k8s 的工作量。你不按照他定义的规则来写，后面公司嫌他贵把他开了，后面反复招人吃不下这一套，公司业务停滞了几个月，最终公司老板气炸了，他开心了，拿了赔偿，恶心到了公司。

这代码，说实话：

像极了需求的样子。。。。

哈哈哈哈,可能一开始只有一个 if,都是后来加上去的

我们算法策略那边有几万行这种代码。。。

上家就是这种代码，比这还要复杂，一个 if 里面七八个条件，同时里面又有多层嵌套。没人敢重构，所以只能往屎山上继续拉屎

@bzj 说明你不懂什么是封装。这里将代表多个细粒度业务的条件判断，分组归类为少量粗粒度业务。

你知道什么是系统设计吗？
一个 statement 一个 closure 也需要设计，顶层设计者不会关心这个粒度，但这是成长的必经之路。

@wapzjn #12 JS 魅力时刻

抽个变量也不至于是一坨

@zhuisui

不是，你一个前端扯什么封装？

涉及到逻辑判断的一律放在后端处理，像上面提到的 orderType=1 ，orderStatus=1 ，已经涉及到数据库结构了，这不是前端该操心的事情，通常做法是由后端提供一个包含各类条件的接口，顶层设计者不会关心是因为这纯粹是常识，谁能想到前端给自己加戏，能写出这玩意。

@bzj 前端没业务？谁跟你说封装只有后端能做了，封装是针对业务的、针对代码逻辑的，不是针对什么前端、后端还是什么端的。
至于业务逻辑该放哪儿、开发者能不能决定得了，那是另一码事。