这是一个创建于 414 天前的主题，其中的信息可能已经有所发展或是发生改变。
如何在项目中埋当时不会发作，离开了一两个月之后会逐渐发作并且还很难排查的 bug 呢？
初步想到几个
后端
- 把全局变量变成私有；
- 在注释中撒谎误导；
- 更改日志级别然后将其上传到生产环境；
数据库
- 把日期类型改成字符串，然后照常 ORDER BY ；
- 多用模糊查询让索引失效；
- 更改某些定时任务插入数据的频率，快速塞满数据库；
欢迎各位 V2EXer 补充，仅仅用作技术探讨，于此同时也可以避免 bug
 |
101
lonenol 2023-09-22 14:17:30 +08:00
多写点设计模式。。。
|
 |
102
lsry 2023-09-22 14:18:24 +08:00
提高時間，空間複雜度吧，多調用幾次 RPC
|
 |
103
c2const 2023-09-22 14:22:51 +08:00
不要菜，要秀起来，一样可以埋坑，只从语法上说说：
0.尽情的秀语法就行了。 1.如果是 C/C++代码，可以写汇编 shellcode ，比如把部分代码写成汇编，再把汇报的二进制转成 16 进制的字符串，然后 C/C++直接写死去调用就行 :) 2.如果是 C++，可以用模板，正经用就是泛型，不正经用就是元编程天书，而且它是图灵完备的，所以它可以各种嵌套、递归函数，甚至创造一门新语言都可以，学习成本也不太高，好处是除了写的时候，事后自己也不知道写的是啥 :) 3.如果是 java 语言，了解不多，可能比较片面。第一是可以考虑动态修改字节码，大概类似 shellcode 一样；第二是多用 Function 相关类的方法引用，大概类似 C 系的函数指针？传参数全部传函数指针就行了，各种回调，反正正经的参数一个都别传:) |
 |
106
anzu 2023-09-22 14:32:31 +08:00
不建议这么做。
想起来遇到过 2 个比较难排查的 bug 。一是边界条件的处理上有问题，极少情况下输入的极值导致错误。二是某些资源用完了不释放内存，一直积累很长时间后才 OOM 。 |
 |
107
fcoo 2023-09-22 14:38:12 +08:00  3
如果故意这么做，感觉就人品有问题了，这样路会越走越窄
|
 |
108
lambda6 2023-09-22 14:38:54 +08:00
多用门槛高的新技术，多弄点自定义类，多抽象，多引用，关系搞得极其复杂，但是毫无扩展性。
多用缓存，本地数据库，服务器多个不同的数据，要保证同步，保证互相依赖。 不说了，正在维护这样的代码。 |
 |
109
zmcity 2023-09-22 14:44:32 +08:00 2
@c2const c++我再补充点，多用点新特性，coroutine ，ranges ，concept 。标准库缺少的功能自己用运算符重载实现一下，初学者写起来跟鬼画符一样。
|
 |
110
Enzoliu 2023-09-22 15:04:10 +08:00
不写注释只写代码就是最大的坑
若干月后自己都不认识那段代码 它还在线上平稳的跑着，没人敢去动 |
 |
111
THESDZ 2023-09-22 15:07:55 +08:00
多用魔法值,使用 map 等弱引用的方式引用全局配置
flag 用 UInt8 然后位运算读和解(不分装方法,用到哪写到哪) |
 |
112
qping 2023-09-22 15:08:00 +08:00
你这太明显了，只要把代码架构设计的一层套一层，套 8 层以上，互相依赖，后面不招高手你的代码就改不动
|
 |
113
visper 2023-09-22 15:09:01 +08:00
把你想象中的架构尽量设计成你差不多能理解的极限。那么他就会有很多奇怪的 bug 在里面。
|
 |
114
x86 2023-09-22 15:11:32 +08:00
认真写就行了，自然会又大坑
|
 |
115
lakehylia 2023-09-22 15:12:13 +08:00
正常发挥就行
|
 |
116
string2020 2023-09-22 15:16:40 +08:00
就和打游戏一样。你菜到认真打 比 你想恶心队友 送的都快。有什么好想的。
对你这种彩笔，尽最大努力写好代码。就能埋你自己都不知道的坑。 |
 |
117
zpf124 2023-09-22 15:19:58 +08:00
人心险恶， 这种报复社会的大多数时候只能坑害了其它打工人。
而且这是个楼主是没工作呢？ 还是不是正经搞开发了。 正常开发你只要按照一个外包或者是混日子人的工作心态干活就已经可以留足够多的坑了。 什么国产一键式框架，傻瓜式类库都引入一遍， 写代码不考虑风格和性能，写一大坨难以修改和梳理的屎山，写的功能以能跑就行为目标，做到这些就已经能让这个项目全是坑了。 |
 |
118
8355 2023-09-22 15:59:51 +08:00
你坑的只有留下的同事和跟你交接的人，你所谓的项目经理会改一行代码嘛？
要么你正面硬刚，你这样干真没必要。 |
 |
119
easyalarm 2023-09-22 16:10:44 +08:00
看到这个标题还是很震惊的，不要让一时的魔鬼冲动定义你的人生。
|
 |
120
middle2000 2023-09-22 16:13:43 +08:00
设置大于某个时间就固定触发某个 BUG
|
 |
121
dongtingyue 2023-09-22 16:16:25 +08:00
数据库定义的时候字段长度小一位
|
 |
122
luzemin 2023-09-22 16:17:57 +08:00
之前看过一个开源项目，其实就是几行 js ，让网页每天变透明，直到透的看不到（时间可以设置个 3 年）
|
 |
123
Naccl 2023-09-22 16:27:57 +08:00
搞过一次按月份分表的需求，有个函数是查前 24 小时的数据，SQL 中带 having 语句，每月 1 号时间范围触发跨表时就会报错😄
|
 |
124
kaoqinqin 2023-09-22 17:12:39 +08:00
evil.js
|
 |
125
xiangbohua 2023-09-22 17:15:02 +08:00
感觉故意留下 bug 在特定的时间触发，比写一个没有 bug 的还要难挨
|
 |
126
pota 2023-09-22 17:18:39 +08:00
正常"严格"的按照需求来改，不要考虑什么兼容。不要考虑什么升级，就行了。
|
 |
127
cando 2023-09-22 17:27:01 +08:00
多写几个存储过程，存储过程里干嘛，看你了。
|
 |
129
yuwen4012 2023-09-22 17:46:59 +08:00
你可以写复杂，但最好不要故意写错，你为难的终究不是老板，而是和你一样的打工人
|
 |
130
54xavier 2023-09-22 17:58:26 +08:00
发个 npm 包，然后过个把月把包删掉🤣
|
 |
131
ukpkmk 2023-09-22 18:12:50 +08:00
不写注释就够了 :)
|
 |
132
zhousir5071 2023-09-22 18:23:24 +08:00 1
作为小公司的老板，看到你这样的，真的感到你太可恶了，不知道你遇到了什么，相处不愉快离职便是，老板做得再差也是每月给你发工资的。你这样的人要是哪天创业当老板了，你再体会一下老板的处境，尤其是当下环境。不过你这个格局的人是不太可能当得了老板的
|
 |
133
ohwind 2023-09-22 18:39:46 +08:00
写 C 吧，你无需刻意制造 bug ，bug 将如影随形。
|
 |
134
davelm 2023-09-22 18:55:10 +08:00 1
@zhousir5071 这就是不同背景的人想法会有很大的差别，作为老板想的是，员工你和我相处不愉快离职便是（因为你不干有得是人干）
作为员工想的是，我和老板沟通（比如提高工资，多招点人，更合理的分配任务等等），万一给我小鞋穿怎么办，万一辞退我，在目前的环境下怎么办 我爸原来在大陆开过公司，就说过员工有这种想法很普遍，在 19 年之前就普遍不要说现在了，只能靠一层一层的复核制度来堵，和比较顺畅的发泄或者投诉的渠道，不要让员工的积怨积累到删库跑路的程度 |
 |
135
rrfeng 2023-09-22 19:06:53 +08:00
你就正常写。
|
 |
136
hankai17 2023-09-22 19:26:32 +08:00
多线程
|
 |
137
ajaxgoldfish 2023-09-22 19:38:22 +08:00
@zhousir5071 #132 老板就是老板，“相处不愉快就离职” 说的那叫一个轻巧啊，要是你的几个甲方大客户坑你钱给你埋坑你也会说“不愉快就走” 吗？给我整乐了，身不临其境就断言，我看未必是 op 的格局小。
|
 |
138
ZZ74 2023-09-22 19:51:36 +08:00
@fcoo 35+失业就已无路可走了 何必想那么多
多线程就算了 CRUD 的项目用得到什么。 重复代码多一些，多弄接口抽象类。最简单的 多用写 stream 特别是并行 stream ，里面套 lambada 和 foreach 就完了 |
 |
139
xianrenT 2023-09-22 19:52:16 +08:00
|
 |
140
fkzz 2023-09-22 20:32:38 +08:00
if else 无限嵌套
|
 |
141
xd314697475 2023-09-22 20:44:36 +08:00
命名的时候名称与含义无法匹配
多用线程，什么都可以多线程 降级策略里引导高 cpu 内存占用操作保证无法降级 |
 |
142
GeekGao 2023-09-22 21:56:01 +08:00
多用一些反模式，然后留下看似“正确”实则胡说八道的注释。
变量命名尽量用英文缩写，例如把 userLoginToken 写成 uLT 尽量把代码加到某迷之功能的大函数/方法内，例如：do_all_login 尽量别考虑时区、语言等环境因素一律使用北京时间、中文简体作为基准 |
 |
143
ThinkCat 2023-09-22 22:10:03 +08:00
请尽情使用设计模式，觉得好像能套，就都用上，硬搬硬套，要多抽象有多抽象
|
 |
144
olaloong 2023-09-23 00:03:19 +08:00 via Android
多用设计模式+1
工厂策略责任链模板委派观察者一起怼上去，层层嵌套，极尽抽象。既能增加复杂度，又能锻炼自己运用设计模式的能力，问起来还能说是优化。 之前接受的一坨模块就这样，生产出现问题不把参数捞本地 debug 一下都不知道走到哪去了。看似高度抽象可扩展实则 protected 从上到下从里到外，改点东西牵一发动全身，哪哪都改不动，绝妙的平衡，最后被迫在外面又包了一层。 |
 |
145
nexo 2023-09-23 00:28:42 +08:00
变量把英语变成拼音而且是多音字那种
|
 |
146
n18255447846 2023-09-23 02:38:32 +08:00
我已经被公司坑过一次了，所以以后写代码都会留个心眼，复杂逻辑随便写，凡是涉及数学运算的全用位操作符
|
 |
147
duron600 2023-09-23 09:17:59 +08:00
哈哈哈伪装？太高看自己了。
|
 |
148
boobo 2023-09-23 09:49:53 +08:00
这对大伙儿很有用...
|
 |
149
evilman 2023-09-23 10:25:18 +08:00
其实有个很简单的方式，结合前面各位老哥说的，用一个=号啊，把&& 换为 & 巴拉巴拉 就一堆 很容易粗心犯的错误 配合 格式化模板（一般格式化代码都有模板配置的），你一次提交一大批这种新模板格式化的文件，很慢被发现，也很好留坑
|
 |
150
twofox 2023-09-23 10:47:47 +08:00
@zhousir5071 格局？华为能让员工进去 251 ，还得不到任何的赔偿和道歉。
作为一个小员工，我做的再差，也是付出了劳动的，你给我发工资不是应该？ 你公司开不了，有的是人开 创业阶段讲的就是同甘共苦，等发财了，就是卸磨杀驴了 |
 |
151
jackOff 2023-09-23 11:07:48 +08:00
1-大量使用循环和递归，访问量不多的情况下看不出问题，访问量上来了，cpu 会因为无法及时释放内存占用最终直接堆内存溢出。
2-大量使用第三方插件，比如 lombok 这种，一方面简化代码显得代码写的很简洁优美，一方面把这玩意的通用隐患继承下来 3-假借线程安全过量使用大量的读写锁，写个死锁或者数据不一致也很难查出来，尤其是数据不一致 4-多使用注解，尤其是定时任务、autowired ，一般出问题这种排查很难查出来，最好把 autowired 那几个兄弟都拿过来使用，尽可能把代码无限复杂化，让后人根本不敢随便动 |
 |
152
zxCoder 2023-09-23 11:36:36 +08:00
多封装
|
 |
153
Jirajine 2023-09-23 12:24:35 +08:00 via Android
最简单最可靠的：data race 。
尽可能的引入 data race ，难以发现，难以排查，影响非常隐蔽，排查到了也不用承担法律责任，无法认定成主观故意。 像是什么订单、事件随机性的 10 条入库丢失一两条，或者关联到错误的条目，等用户报告发现了自己的账号里出现了别人的数据或者丢失也无法挽回，因为整个业务数据库都是被污染了的。 这是在坑害其他打工人？错，这是在提高总体的需求工作量，反而是在制造更多岗位、缓解“你不干有的是人干”的现状。 |
 |
154
skiy 2023-09-23 13:40:40 +08:00
不敢苟同这么多人这种心理。不知道有没有人搬运下本文到 reddit 。看看老外怎么评的。
|
|
155
zhousir5071 2023-09-23 14:20:58 +08:00 via iPhone
@twofox 在职的时候，能合作就合作，不合作就该赔偿赔偿该离职离职，用得着干这种背后见不得光的事情吗？我想表达的意思是，要光明正大，不要背后搞小动作。
|
|
156
twofox 2023-09-23 15:04:30 +08:00
|
 |
157
sordidclown 2023-09-23 16:22:51 +08:00
按楼上说的，逻辑写复杂一些。
提供几个思路： 1. 闭包内套高阶函数再在闭包内调用； 2. 如果语言允许，产生迭代器的迭代器，再在迭代器中调用； 3. 多个 stream 流套起来，最好是什么 map, filter, reduce 写成一行； 4. 猴子补丁打起来； 多用些语言的边角料，或者一般生产用不到的语法特性，总之多用些书里明确劝你不要用的。又能练手，出了事还能说与我无关。埋坑不一定要自己埋，守株待兔也是种方法。 |
 |
158
vivisidea 2023-09-23 19:25:59 +08:00
没必要
而且，老哥这么自信么，说不定在后面接手的人里，你现在用心写的代码就已经是坑了…… |
 |
159
KENNHI 2023-09-23 21:51:18 +08:00 via Android
刻意破坏不如浑然天成的愚蠢。
我说几个。 ①把表数据抽出来用嵌套循环 if else 筛选数据。 ②在 sql 语句疯狂嵌套子查询，并在能加动态 sql 的地方加上动态 sql ，把一个业务需求都扔进一条 sql 里面写 500 行并且不加注释。 ③什么异步代码看不明白也不知道怎么调，设置定时器等待 500ms 执行下一个函数。 ④试图将 4000 万条数据抽出来放到内存里让程序逐条处理业务逻辑。 ⑤选择没什么人用的冷门或者闭源商业框架，等待 10 年后整个项目必须全部推倒重来。 |
 |
160
zhangxzh 2023-09-23 22:15:40 +08:00
这得看你的级别能不能自己决定自己使用的技术
例如用一些其他人不熟悉的语言实现一个服务: 我用 C++写 web 后端 我用 kotlin 写 spring 的服务, 并且用的全是异步的 Reactive 风格 |
 |
161
voila1106 2023-09-24 02:04:28 +08:00
去 CWE 翻一翻有什么方便实现又不容易看出来的，被发现了就说不小心的
|
 |
162
someonedeng 2023-09-24 16:01:34 +08:00
进来看看大佬们怎么做埋点
嗯？ 埋坑？ |
 |
163
iorilu 2023-09-24 17:50:51 +08:00
其实很简单
多用全局变量， 自然就有很多 bug ， 而且很难查， 即使不是你故意的 |
 |
164
dropdatabase 2023-09-25 13:23:27 +08:00
😂我想知道: 为啥这么多人收藏？
|
 |
165
yagamil 2023-09-26 09:36:41 +08:00
自己做的可能还是容易被别人发现.
可以多看看同事的代码. 如果接口外网能够范围, 看看那些 post 有漏洞的. 后面黑进来就 ok 了 |
 |
166
Navee 2023-09-27 10:29:52 +08:00
把 bigdecimal 全部替换成 double
|
Select Language