网上看到的段子照进了现实，这种代码出现在我的项目中！

[szpinc1102]

给大家观摩一下，给我看傻了

[28Sv0ngQfIE7Yloe]

@xloger 我和你想的一样，我也觉得不好，随便套个 map + 策略都能解决一大部分重复代码。实在不理解一些回复说的直观，

[ZGame]

看看是股票折线图那些吗? 理论上也能解 , 你得定义 useHooks 相关的含义 view->维度,度量->dataset 这样？

[TUNGH]

建议让 ai 重构一下

[Sawyerhou]

这代码虽然给人第一印象脑残，但逻辑清晰，后期维护增删改都很灵活，其实没有很大问题。

楼上有说总字典的，但需求里显然不同列处理方式不一样，如果经常增删改需求，维护一个笛卡尔逻辑字典，其实还不如这个手搓 switch 来的容易。

代码写到后面，有时候 less is more.

[Leviathann]

@xloger 这就是 go 的基本盘，所以不奇怪 go 在国内用来写业务大火

[KnightJoker]

道理我都懂，为啥开头两个一样的“应用名称”？

[juzisang]

对不讲逻辑的代码最好不要考虑抽象，优雅，否则后续稀奇古怪的需求会让你想死😅

[PTLin]

一旦套上了“业务开发”，“业务经常变化”的 buff 之后，多丑的代码都可以接受了。

[zihuyishi]

所以有人写出更好的写法了么，我的想法是配一个 map[string]func(project Project) bool 的 table

[karmaisbitch]

我一般会用 ai 优化一下这种

[NX2023]

@TsubasaHanekaw 我专门为了这个东西写了个小工具，类似于 Excel 的 ORM ，跟插入数据库一样

[hewiefsociety]

写的还挺整齐得

[SekiBetu]

看得懂，性能也无影响，挺不错的，就是有点长，反而是某些为了少而少的写法搞得很晦涩，容易导致后期维护失误

[SekiBetu]

Excel 的表格的话，就是要这样一眼看过去很工整，后期维护才方便

[flmn]

又不是不能用

[jackmod]

考虑两点。一是逻辑是否通用，二是这个逻辑是否很难再变了。
确定满足这两个条件再用反射之类的玩意压缩类似的代码。
要不然后期再看这代码肯定会觉得当初以为这种方式傻逼的自己才是真傻逼。

[FallenTy]

用一个数组或者 map 就可以解决的事情，如果需要即时修改就再维护一张表来灵活调整，摆烂的人太多了

[wen20]

就说你一眼有没有看懂吧

[kkwa56188]

明显不行.
现在是几十列, 手搓代码勉强能搓出来,
换成几百列的场景呢, 几千的那种呢

[fan88]

打工挣钱，搬个砖，你非得要求人优雅，何必呢。

好卷啊，没必要啊。

这样写的人多一点不好吗？非得要求人人都是高标准，人人都是那么认认真真，累不累啊，多躺一躺，你自己不想躺没事，多点包容呗。 大家都躺了，你不躺，不是更加凸显您牛逼么？是不是

[pocketz]

谁能讲讲这个 DTO 是什么思路，为什么加了这么多 isXXXX()，这是 dto 该干的活吗？
我猜他这么写是不会或者不想写泛型

[p1gd0g]

可读性拉满了好吗

[kk2syc]

@xloger 可是他这个有关键词啊，比如你要改 ”应用程序“ 那栏，肯定直接 ctrl+F 定位过去了，是不是另一种一目了然？

[HappyAndSmile]

上面该有的注释也写了，不同类别也分组了，其实也还好

[lscho]

这虽然看起来比较垃圾

但是后期维护时真的方便，中途修改什么内容也方便，关键词搜索直接定位到

属于中用不中看的代码吧

[ZZ74]

@kkwa56188 别陷入开发者的思维。这种导出的业务需求，几百几千列的 excel 导出来 谁看啊 换句话说不会有哪个业务人员要求导出一个巨大的 excel 去看。当然自作聪明的 产品产品经理除外

[ccraohng]

🪨

[Cybrox]

我今天才在项目里看了一段代码，写代码的人想从一个 uint8 的 TArray 里取出二进制的数据传给 lua decode 接口，他遍历了一遍这个 TArray ，每次取出一个字节并用 .. 拼接到 lua 字符串上。。。

[adoal]

从贴图和回复来看，很多团队没有基础设施类公共代码的积累，也没有真正熟悉架构的领头人，就是靠直觉把业务逻辑代码 case by case 垒完交差就行。

[aaronzhang404]

不仅没有性能问题，还方便重构。哪怕产品瞎改需求，也能快速实现

[mgzu]

改过几千行 if else if 路过，改之前，定位 BUG 极其痛苦
只能说大部分业务代码考虑更多的是功能实现，而底层牛马不需要考虑后期的维护性

[Alexrx]

今天刚在项目里注入了一坨💩 点进来之前还紧张了一下是不是被同事发现了

[happy32199]

装 x 的真的太多了，就这么写有什么问题？所有人都看得懂，所有人都能改。
你怎么优化？把相同的提取出来，特殊的保持原样？？之后再有特殊的，再上面删掉，下面再加一个 ifelse ？
或者用什么注解之类的，碰到不熟练的同事，隐藏 bug 不知道埋多久。
全是培训班 PUA 了，还当真理了……
Linus 算什么东西，别人写的大便，他写的赶得上被骂的那些人的吗？？起了坏榜样。。
所有人都能维护不出问题，比你乱优化好太多！！

你截图这个是有字段先后顺序的，判断不一样，特殊字段也是不确定的，鬼知道某个字段，突然要加什么新需求。 不大动直接改不了，请喷的大侠自己优化看看 再和这个比比……

[cybort]

等保人是这样的

[cybort]

@aaronzhang404 产品给你改一改命名，一大堆代码要动🧐

[zhangk23]

cellValue.equals("应用 ID") ? !dto.getExportColumn().isAppId() :
cellValue.equals("应用名称") ? !dto.getExportColumn().isAppName() :
cellValue.equals("应用编码") ? !dto.getExportColumn().isAppCode() :
cellValue.equals("应用描述") ? !dto.getExportColumn().isAppDescription() :
cellValue.equals("应用类型") ? !dto.getExportColumn().isAppType() :
cellValue.equals("应用类型说明") ? !dto.getExportColumn().isAppTypeDescription() :
cellValue.equals("应用领域说明") ? !dto.getExportColumn().isAppAreaDescription() :

[iceheart]

代码为修改而设计，啥也不懂上来就瞎逼封装的才是新手。封装完了过段时间自己都不知道封装了个啥，一有变更的需求就抓瞎。

[Dyon]

这代码不完美也有 80 分了，同事写成这样我只会感恩，累的是他，而我读得很轻松🤪。
说真的好代码不就两点，1 是性能 2 是可读性可维护性，他这个看着也不需要什么性能，你也优化不到哪去，可读性拉满了，不要对别人要求那么高好吗

[Dyon]

@iceheart 真的是，觉得有问题的真是 too young ，以为各种抽象就是好，实则徒增耦合

[kaedea]

这代码要是 APT 生成的简直无敌了

[jim9606]

这样写好像问题不大，至少不是金字塔嵌套 if 。
楞要说的话就是匹配不太高效，而且没有缓存待比较值，不过有 JIT 的话也不见得会有大问题。
而且看上去也不是什么高频代码，不优化也说得过去

[EscYezi]

这段代码明显是可以优化的，但是重构要考虑全局，从读取表格甚至更前面的部分开始都需要重新设计，只改这么一段作用不大

[GeekGao]

有没有可能是这种故事：
你的小同事：“DBA 敷衍我，线上不给我加表啊，怎么破？ 曲线救国吧，我 hard coding..先 ”

[kile]

我觉得的话分两层 if
第一层区分 cell value

第二层 if 判断各种条件

if(cellValue=='项目 1'){
if(条件 a&&条件 b){
显示该列
}
}else if(cellValue=='项目 1'){
if(条件 a&&条件 b){
显示该列
}
}

改到这种程度就好，也不会过长到一屏看不全逻辑，也方便之后逻辑修改

[mohuani]

多半可以用 easyExcel 优化一下

[JeremyFeng]

@AlexRoot #17 同问，代码如何一次性截这么长的图？

[hafuhafu]

赶时间这么做倒是能理解，写个简单映射条件，然后代码生成一下，然后增加部分特殊的逻辑，应该不会有人手写这么长吧。
但是这明显也不太直观啊，整个代码块就很长，判断条件看着也长，看着好像工工整整，谁知道哪有啥坑，本来就没啥复杂逻辑，重构不重构都没性能问题，就是一个 dirty work 罢了。就算抽象出来，找具体的片段一样不会有啥困难，又不用封装很多层。
这种重复度高、本身逻辑并不复杂的如果有富裕时间确实可以好好设计一下，项目中肯定很多地方会用到的，导出 Excel 也算基础设施了吧，没时间就凑合来吧。

[jeffw]

可读性可维护性拉满，心智负担低，在我看来这代码挺好。瞎封装就能显得很高大上了？

[zgsi]

你还别说，你重构一个发出来看看

[dupenn]

又不是不能用.jpg🤣

[justfindu]

@kkwa56188 #119 几千列你也要一个个改啊 难道你还能盲猜列名?

[cocong]

我截取了部分代码让 gpt 优化，都差不多也是将判断逻辑放到 map ，改成字典查找执行，并没有优雅多少，反而阅读起来没这个容易。

另外，业务和技术还是有区别的，技术通常有规律且稳定，很容易抽象，而业务则通常没什么规律还特复杂多变，所以业务代码你再怎么封装优化，都是无法屏蔽其本身复杂性的，业务可能会因为你的抽象而简化，而技术通常可以。并且业务的变化，经常是超出了封装的承受范围，毕竟封装说白了是搭好了架子，但业务是可以直接整个需求不要重新推到重来，那封装除了增加加班时长还能干嘛。

真是应验网上流行的那句话：拿三千块钱工资，为老板操碎了心。老板都没想过业务长期发展，你反而考虑代码永久不变。

[Mandelo]

@xloger #92 看评论区才是大受震撼,这就是人均几万工资的 v 站水平吗?我们类似需求是实体注解+反射,遍历属性,像上面的通用字段直接走正常逻辑,然后 switch 去处理特殊的几个就行了

[liuidetmks]

看起来，这个可能一个月运行一次？
一把梭没什么问题。

[THESDZ]

这个代码不能算差，当然也不能算好，按照我的习惯，应该会将模板相关的，在外部定义
封装一个方法，参数是 excel 数据和模板配置，输出结果数据。可以考虑配置对象带泛型，让代码更优雅

[superkeke]

简单直接粗暴🐶，不过一般是陈年屎山这样吧

[zjzs]

这应该是为了应付能效数据，考核每天代码提交量，没有代码量，排名上不去。
别问我为什么知道 ，我现在就是这么干的。
尽量把一个函数能搞定的事，写个百来行，然后加上注释，几天的代码量都到手了。
后面几天就能愉快的摸鱼了。至于代码跑的好不好，维护难度大不大，这就交给下一任了。

[AlexHsu]

你们装啥呢 这种东西一眼看就是上线前期一天改八遍的需求

[NGXDLK]

虽然不简洁，但也算不上屎山，因为代码逻辑真的很清晰
真正的屎山看起来都费劲，想改一时半会儿都无从下手的那种

[chenyu0532]

你就说你一眼看不看得懂吧。。。哈哈哈哈哈。

确实太啰嗦，可优化。

说个反例：早期在北京开发游戏的时候，月流水稳定几百万的游戏里这种形式的代码很多。。但不影响游戏赚钱。。

[ww2000e]

又不是不能用

[egan0606]

虽然我也鄙视这种写法， 但是在实际开发，业务维护、迭代过程中你会发现，这种最原始的写法反而比较容易理解以及业务修改； 没有什么瓶颈；

[zy0829]

有什么问题吗？

[egan0606]

@egan0606 该鄙视还是得鄙视， 有次改逻辑， 感觉逻辑写的有点烂， 然后看了下 git ， 是几年前自己写的代码。 🤣。 该骂还是骂， 骂完再根据实际情况处理；

[fredweili]

卧槽，都是神人

[zt5b79527]

简单粗暴，好维护，好用！

搞工程的，这就够了。

那些看不起的，我只想说，talk is cheap ，show me ur code ，不是不相信你，只是大家伙儿想开开眼

[mitu9527]

可以理解，无需嘲笑，但也绝不接受！

[xdc]

写成这样 后面的人改起来还是挺简单的， 反正我自己写得抽出来

[tracebundy]

说代码优雅的，35 优化的就是这批人

[asche910]

刚毕业的我：这就是 shit ，什么人能写出这样的代码！
现在的我：又不是不能用？就问你能用吗？

[sheng9632]

我觉得没啥问题

[xloger]

@xloger #92 再补充一下。似乎很多人有误解，以为重构的目的是“让代码量更少”。并不是如此，重构的根本目的是让规则更清晰，顺带它还有能让代码量更少的效果（减少冗余）。

代码本质上来说，是把现实世界的逻辑（需求）转换成机器能理解的语言，那么重要的是程序员能理解现实世界的需求，把其梳理成清晰的规则，再用代码实现这套规则。

拿贴中的代码为例，产品当时怎么说的？莫非是几十条数据挨个说一遍？他估计说的也是把这个数据导入导出 Excel ，这里 XX 如果没有那怎么怎么样，那里 YY 要这样那样。
如果代码里能很清晰地表现出这个规则，那不管它用的是 if else 还是设计模式，它都是好代码。

但是，这类一长串的 if else 代码统一的问题是，它并没有体现出这套代码的运作规则，这套规则只存在于编写者的脑海里。它只是一串 人脑分析完规则后编译出的 机器能执行的代码，而他人要看这串代码需要一行行理解，反过来归纳规则。

就像那些“AI 会不会取代程序员”之类的讨论中，大家都知道代码本身不麻烦（大部分时候），麻烦的是对现实中这套复杂机制的理解和抽象。而当你真的自己脑海里抽象好了整个规则的时候，那写代码起来也是顺其自然地不愿这样挨个 if else ，它反而是烦心的。

至于什么职场的角度，我不想讨论。

[ilvsxk]

不是，改成 map 不也是这样一大坨么，只不过变成了 map 一大坨，换个地方变成一大坨而已。

[Torpedo]

我个人感觉是大家很容易把业务复杂、繁琐和代码不整洁搞混
这两种都能产出难读、难维护的代码

[Tink]

debug 也方便

[ccfly]

这代码看起来不优雅 但是你要半路接手这种代码就知道调试多方便了 起码看起来一目了然 有的代码是看起来优雅，但是一个封装一个套娃 看懂逻辑都要看半天

[guanzhangzhang]

我同事的代码，就一个 groovy 里传递一个布尔值给 shell ，原本是
```
sh "xxx.sh arg1=${v1} arg2=${v2}"
```

然后他写法是：
```
if (cache=="true") {
sh "xxx.sh arg1=${v1} arg2=${v2} cache=true"
} else {
sh "xxx.sh arg1=${v1} arg2=${v2} cache=false"
}
```
类似的代码他写了好多次，说了就是屡教不改和找借口，然后他被裁了

[luckyrayyy]

包一个方法放到 ShitService 里面，看不见就行了

[neptuno]

话说这种代码如果不经常变动的话，这样写确实没问题的，你接手的时候也不会觉得很难。如果用太多模式，可能后面接手的人都看不懂呢。（上面说优雅的人肯定是来捣乱的，这种代码不提倡，excel 导出我自己倒是写了工具类的）

[forty]

说“又不是不能用”的，如果是玩梗也就罢了，如果是真的这么认为，那本质上就不太适合这个职业，干点什么不好？

至于怎么写更好，得看需求逻辑大概是怎样的，目前没有看到关于需求的描述。

我粗浅的理解，根据不同情况，可以把这些表格列名对应的区别，存入 1 个配置文件(excel, json, ini 什么的都行)，或存入数据库，代码不需要写这么多个方法成员以及逻辑语句。

这个代码有一点值得表扬，就是它的命名，还是使用比较正常的驼峰和英文，而不是拼音首字母缩写。

[mugglezzz]

第二个 和 第四个 “应用名称” 重复了

[adoal]

@ilvsxk 对于写这段业务代码的单个程序员以及这个具体项目来说是如此。但是如果公司在行业有足够的底蕴，做的项目多，以及有真正的技术功底好又能把握业务的架构师，那么应该针对每个项目里都会出现的类似场景做抽象设计，做成库或者框架，甚至用流程引擎、DSL ，解耦易变的业务规则和不易变的基础代码。就像 #172 说的，重构的目的并不是直接的“让代码量更少”，这里我补充的是，通过这种逻辑抽象的重构，单个项目里的代码量可能反而增加很多，但是提炼出的公用代码可以作为基础设施重用到不同项目，这样写业务逻辑的人就可以更多把精力集中到业务逻辑代码的编写和质量控制，而不是在跟混杂着业务逻辑和底层功能的几百几千个分支的条件语句搏斗。

[MoYi123]

用 map 也是换汤不换药啊, 正确做法是在 struct 里加 tag, 然后这里反射遍历结构体再存 excel 吧.

[Hilong]

不是，楼上还有洗的吗？这种代码都能洗不知道说什么了。

[em0miao0]

赞同 35 楼，建议楼主: do it OR shut up

[easonwood91]

我们工作 10 年的初级程序员是这样的

[forvvvv123]

说实话，我觉得这种反而是最好的写法，清晰，主要是 excel 单元格可能出特殊逻辑，比如背景色、特殊单元格格式，如果不这么写后面一定吃瘪，会变得特别难维护；

[forvvvv123]

@Hilong 我做过类似的需求，自己先是抽象好了，这些单元格都分哪几类，该怎么填充，但是后面稍微一变，前面封装的都得拆开，要么就再里面再加 if ，非常难读，最后感觉还不如这样；

[dupenn]

我们这边现在每个月要统计代码行数，明明一行的代码我一定会拆成两行写，IDEA 一直给我各种提示，估计 IDEA 内心都崩溃了，哈哈哈哈

[XINGXlNG]

switch,枚举和策略模式,Map,多态

[me1onsoda]

目前看到的只有一个敢 show code 的，方案还不咋地😅

[runliuv]

优秀，一看就懂。

[ala2008]

还行吧，不过一般超过三个 ifelse 就考虑 switch 等了

[zoharSoul]

感觉挺好的 很好看懂 也好改

[zoharSoul]

@woodwhales #23 这种来回跳着看, 更累 还不如这样一把梭拉倒了

[dk7952638]

注释明确, 代码结构清晰, 具有拓展性, 这代码已经算不错的了, 知足吧兄弟

[AlexRoot]

chatgtp 使用反射方式的解决方案：
要使用反射优化这段 Java 代码，反射可以用来动态地调用方法和设置字段，从而减少重复的代码。以下是一些优化的思路：

### 1. 使用反射动态调用方法

可以通过反射来获取对象的字段和方法，并根据需求动态调用。例如，如果 `getColumnValue` 是一个在多个地方使用的方法，可以通过反射一次性获取并调用：

```java
Field field = dto.getClass().getDeclaredField("columnName");
field.setAccessible(true);
Object value = field.get(dto);
```

然后使用反射方法 `invoke` 来执行相关逻辑。

### 2. 将重复的 if-else 逻辑提取为方法

可以创建一个通用的处理方法来简化 `if-else` 的逻辑。通过传入字段名称和相应的操作来执行相同的处理：

```java
private void setColumnIfMatches(Sheet sheet, Cell cell, String columnName, String methodName, IDto dto) throws Exception {
if (cell.getStringCellValue().equals(columnName)) {
Method method = dto.getClass().getMethod(methodName);
Object value = method.invoke(dto);
sheet.setCellValue(value != null ? value.toString() : "", true);
}
}
```

然后在主逻辑中调用：

```java
setColumnIfMatches(sheet, cell, "column1", "getColumnValue1", dto);
setColumnIfMatches(sheet, cell, "column2", "getColumnValue2", dto);
```

### 3. 使用映射来简化逻辑

可以用一个 `Map<String, String>` 来映射字段名称和方法名，使用反射来动态获取和调用：

```java
Map<String, String> fieldMethodMap = new HashMap<>();
fieldMethodMap.put("column1", "getColumnValue1");
fieldMethodMap.put("column2", "getColumnValue2");
// ... more mappings

for (Map.Entry<String, String> entry : fieldMethodMap.entrySet()) {
setColumnIfMatches(sheet, cell, entry.getKey(), entry.getValue(), dto);
}
```

### 总结

使用反射和映射的结合可以显著减少代码的冗余，提升代码的可维护性和可扩展性。同时请注意，反射在某些情况下可能会引入一些性能开销，需在关键路径慎用。

[me1onsoda]

@xloger #92 好在维护的时候可以直接搜索定位到哪一行，一千个一万个 if 多少个特殊处理的逻辑也不要紧，没有人会一排看下来

[spiffing]

如果是会经常改的，即使对原来业务不熟悉的上手改也没啥大问题

[trzzzz]

@jiabing520a 领导：可读性最重要