这是一个创建于 341 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如写了一段干净的代码，但不想让别人轻易读懂的时候，有什么工具能把它做成一坨的样子吗
之前我会手动替换变量名，效果有限
之前我会手动替换变量名，效果有限
 | 1 HTML001 2025 年 3 月 18 日 直接代码混淆，让你自己都看不懂 |
 | 2 tigerstudent 2025 年 3 月 18 日 用 ai 试试 |
 | 3 murmur 2025 年 3 月 18 日  3 没必要，现在都有版本管理，想搞你的时候不是会留下证据，除了新项目第一个月，你自己会造屎山的，不用故意，正常开发就行 |
 | 4 flamiNNgo 2025 年 3 月 18 日 3 有时候你觉得挺干净的代码实际上别人读起来就是一坨…… 文档、注释更重要 最简单的方案，代码版本 A->B ，但是注释不变动 |
 | 5 wu67 2025 年 3 月 18 日 没必要, 只要你不写注释, 不主动去优化逻辑, 慢慢的它就会自成屎山. |
 | 6 LieEar 2025 年 3 月 18 日 代码混淆就行了 |
 | 7 librasolo 025 年 3 月 18 日 写假注释 |
 | 8 snowtreetree 2025 年 3 月 18 日 12 知乎上看到一句话，「不用防御性编程，我正常写就行」。 |
 | 9 xiangbohua 2025 年 3 月 18 日 1 别太自信，有可能过几天自己的看不懂，更别提别人 |
 | 10 novaline 2025 年 3 月 18 日 一个文件从头写到尾，绝不回头 |
 | 11 sky3hao9 2025 年 3 月 18 日 只要设计巧妙, 不用主动防御编程, 简单的问题复杂化, 复杂的问题无序化, 要囊括各种奇技淫巧, 高端特性... 你应该看过汤姆设计的捕鼠器吧 ? 你看过就明白了 |
 | 12 pkoukk 2025 年 3 月 18 日 4 1.变量名不要超过三个字母 2.变量声明与使用离得越远越好 3.不要更新函数名和注释 4.弃用的函数不要删除，不要做标记注释 5.不要抽象复用，同一段代码复制粘贴一百遍 |
 | 13 shen13176101 2025 年 3 月 18 日 多大的仇多大的怨 |
 | 14 cyrivlclth 2025 年 3 月 18 日 嵌套一层又一层，有的嵌套 3 层，有的嵌套四层，同样结构的 DTO 不停转 |
 | 15 clemente 2025 年 3 月 18 日 没用 现在有 ai 做这些脏活了 |
 | 16 dumbass 2025 年 3 月 18 日 1 |
 | 18 huihushijie1996 2025 年 3 月 18 日 1  要开除的时候直接整个部门干掉 不要做这些无意义的 |
 | 19 CouleurVVEX 2025 年 3 月 18 日 @bojackhorseman 这简直是天才 |
 | 20 hwdq0012 2025 年 3 月 18 日 没事就往线程队列扔，一逆一个不吱声 |
 | 22 jobscolin 2025 年 3 月 18 日 只要不写注释，迭代两个版本，你自己都觉得是屎山了 |
 | 23 asLw0P981N0M0TCC 2025 年 3 月 18 日 2 @CEBBCAT 价值观是啥。 |
 | 24 InkStone 2025 年 3 月 18 日 让 AI 写。今天 Cursor 刚给我改了一个一千五百行代码的屎山出来。我感觉我自己写的话应该不会超过五百行…… |
 | 25 lyer5 2025 年 3 月 18 日 现在混淆代码靠 AI 解释也能很快理解了吧 |
 | 26 zmcity 2025 年 3 月 18 日 多用点高级编程技巧，对于不懂的人，它就是一坨 |
 | 27 dna1982 2025 年 3 月 18 日 把所有变量都写成全局的，谁看谁骂街。 |
 | 28 olaloong 2025 年 3 月 18 日 没啥意义，太长的混乱的代码直接让 AI 先看了，通义灵码插件写代码不行读代码还是很厉害的，点一下就像也很方便 |
 | 29 qq78660651 2025 年 3 月 18 日 没有用的，你再混淆，现在的 AI 都看懂，你 jsvmp 代码丢进去，AI 都能给你分析出每个变量什么作用；每个功能块在干什么。 |
 | 30 Esec 2025 年 3 月 18 日 via Android 偶尔主动偷偷加班，脑子不清晰的时候能写出自己也看不懂，但是能用的垃圾代码 |
 | 31 sleepyfevniv 2025 年 3 月 18 日 1 没必要特殊混淆，不然怕过不了 code review 。 正常写，然后变量名故意用错拼/乱拼，换别的关系不大的名字，比如物品价格，类似 item_price ，改成 goods_amuont ，主打文不对题。然后注释写物品量，再次主打文不对题。 如果是能用推断型的定义就用，比如 Java 的 var a = xxx.getItem()，主打不知道 var 了什么东西。然后变量和用的地方远离，Steam 和非 Steam 混用，多用数组来回倒腾数据，比如起名 needDeleteList 里面放 needAddItems 。函数入参越多越好，整上一坨方法的重写，函数套深一点，函数名也写得文不对题。 上面的写法过 code review 应该问题不大。再混淆下去那不一定过得了。 |
 | 32 particlec 2025 年 3 月 18 日 设计巧妙！！！ 越巧妙后期越一坨，让 ai 重写，重点要 巧妙深化 |
 | 33 liuidetmks 2025 年 3 月 18 日 别把代码当一回事啦， 基本都重写，反正都是边角料功能 |
 | 34 ywlvs 2025 年 3 月 18 日 学到了，还有防御性编程 |
 | 35 xuanbg 2025 年 3 月 18 日 笑死人了，你自认逻辑清晰没用，最好找个不熟悉相关业务逻辑的人来看一下，看他能不能读懂就完了。 反正我自己写的一段业务相对复杂的代码，写的时候单元测试一跑一个异常退出，好几种特殊情况没有进预期的分支。。。好不容易跑通了，隔了两天自己就看不懂了。 |
 | 36 cookii 2025 年 3 月 18 日 写长没用，要写散，用事件分发逻辑，把业务逻辑写散，慢慢就没人懂了。 |
 | 37 Hopetree 2025 年 3 月 18 日 一个函数上千行，或者一个函数两三行，不停的函数调用...想想就可怕 |
 | 38 YVAN7123 2025 年 3 月 18 日 去学一下设计模式， 学两天你想着都用在你代码上， 一段代码给它用个五六个设计模式  |
 | 39 main1234 2025 年 3 月 18 日 1 要求项目重构 1.拆成 V2 版本，V2 重构到一半想个理由无法推进，项目同时保留 V1 V2 2.拆成 V3 版本，V3 重构到一半想个理由无法推进，项目同时保留 V1 V2 V3 |
 | 40 cocong 2025 年 3 月 18 日 屎山是熵增定律，只要你不刻意优化代码，慢慢都会变成屎山，无非快慢而已。另外不要觉得对别人屎山是个障碍，只要输入输出明确，分分钟把屎山重构，所以没有必要。 |
 | 41 lyxxxh2 2025 年 3 月 18 日 我所遇到最难看懂的: 加个几十个没用的垃圾变量,test_list,testList ... 让他删不敢删,用又不知道用那个。 新增只能继续拉屎加变量。 修改.. |
 | 42 homewORK 2025 年 3 月 18 日 总觉得只要代码函数够长 函数名字乱起 注释是错的 这代码就没办法维护了 |
 | 43 lesismal 2025 年 3 月 18 日 引入多点的设计模式，只要能沾边的就弄成设计模式，然后就一坨坨的了。 如果你水平高、能把设计模式用得如鱼得水、那么就可以轻松搞出很多没必要甚至不合理的设计模式的垃圾代码，就更难理解，至少阅读代码层层嵌套就增加了理解障碍。 好处是可以用来作为自己代码的理由，别人没法拿这个当作你恶意代码的证据； 坏处是别人可能拿这种代码当 sb 、以能力为由干你。。。 我自己至今没学会设计模式，所以看到设计模式重的代码直接脑袋宕机变 sb ，但一直钦佩能把设计模式搞得精通的大神们 |
 | 44 chendl111 2025 年 3 月 18 日 一个函数几百上千行，但是没有注释； 只要不屑注释，多好的代码都会变成屎山 |
 | 45 maladaxia 2025 年 3 月 18 日 1. 把原来抽象清楚的函数删掉, 把代码复制粘贴到各个地方, 这样新增业务需求的时候改起来更快. 2. 变量和函数命名尽量用缩写, 越短越好 3. 嵌套一定要深, 只有嵌套深才能显示出水平 4. 尽量使用全局变量, 全局变量用的时候更方便 |
| 46 maladaxia 2025 年 3 月 18 日 @xiangbohua 自己看不懂更好啊 锁匠如果造一把自己都不能打开的锁, 难道不是更安全吗 |
 | 47 masterclock 2025 年 3 月 18 日 几年前遇到的前端代码，200 行不到点，非常复杂，看不懂，问清楚功能后重构成 3 行，纯 3 行，没有引入内置以外的其他方法 |
 | 48 popvlovs 2025 年 3 月 18 日 问题是这一坨即使别人看不懂，不还是要你来维护，过两天自己都看不懂了，维护成本不还是得自己承担 |
 | 49 orange323787 2025 年 3 月 18 日 同事遇到过只写注释没写代码的 |
 | 50 wqhui 2025 年 3 月 18 日 加班写出来的就是了，已经略疲惫了+只想着赶快糊弄完下班 |
 | 51 NoOneNoBody 2025 年 3 月 18 日 1 @qwertyzzz #23 代码是自己的好，老婆是别人的好 |
 | 52 ODESZA 2025 年 3 月 18 日 完全可以，比如变量名用英文+拼音组合，然后再缩写，保证自己都看不懂，比如我今天遇到的 用户积分、用户名，直接缩写成 Ujf 、Umc ，真他娘的命名鬼才 |
 | 53 TimPeake 2025 年 3 月 18 日 懂 自保是吧 |
 | 54 Apllex 2025 年 3 月 18 日 用 claude 或者直接用 cursor 混淆。上周刚刚防御性编程，把十几个 lua 脚本从一百行混淆到一千行。用 claude 很好使，直接告诉他要混淆成屎山就可以了 |
 | 55 Justin13 2025 年 3 月 18 日 via Android 有办法同时做到逻辑清晰和难读懂 那就是函数式编程 |
 | 56 iorilu 2025 年 3 月 18 日 都 ai 时代, 谁有空看你代码 直接丢给 ai 改或解释总结就行 |
 | 57 shulandmimi 2025 年 3 月 18 日 命名：函数、类、字段 和 变量 全部用 a 、b 、c 、d 、e ...，需求写完过两天遗忘了你自己都不认识 |
 | 58 akira 2025 年 3 月 18 日 多加几个需求进去，多迭代几个版本，迟早变 si 山的 |
 | 59 James369 2025 年 3 月 18 日 简单一点，quanbu huancheng pinyin jiuhao le |
 | 60 jamesjammy061 2025 年 3 月 19 日 很简单啊，有时候就是产品一句话的事情，video 字段塞 image ，还没注释。新来的自个儿 debug 去学习就完事了 |
 | 61 msg7086 2025 年 3 月 19 日 更大的可能是过几天自己都看不懂自己写的啥了，然后老板给点简单的活就只能疯狂加班重新读自己的代码。 |
 | 62 darkengine 2025 年 3 月 19 日 1 @bojackhorseman 感觉这个名字应该用 CodeShitify 会更好，哈哈 |
 | 63 csfreshman 2025 年 3 月 19 日 这和我的认知有点不一样，我们要写高效 易懂的代码，如果你写了还是你维护的话，如果你想提升自己的竞争力建议从别的方面入手，即使混淆 ai 重写，别人也用 ai ，可以看得懂。 |
 | 64 micao 2025 年 3 月 19 日 设计模式混着用，使劲儿用，不能套用的地方也用。这样代码看着高深，别人也觉得你牛摆，但是就是读不懂，过两天你也不懂，但是就是好使，谁敢碰。 |
 | 65 qq05629 2025 年 3 月 20 日 一个模块用一种技术框架 |
Select Language