如何在项目中埋当时不会发作,离开了一两个月之后会逐渐发作并且还很难排查的 bug 呢?
初步想到几个
后端
- 把全局变量变成私有;
- 在注释中撒谎误导;
- 更改日志级别然后将其上传到生产环境;
数据库
- 把日期类型改成字符串,然后照常 ORDER BY ;
- 多用模糊查询让索引失效;
- 更改某些定时任务插入数据的频率,快速塞满数据库;
欢迎各位 V2EXer 补充,仅仅用作技术探讨,于此同时也可以避免 bug
如何在项目中埋当时不会发作,离开了一两个月之后会逐渐发作并且还很难排查的 bug 呢?
初步想到几个
欢迎各位 V2EXer 补充,仅仅用作技术探讨,于此同时也可以避免 bug
|
kkk9Sep 22, 2023
1
与其这样惹上官司不如直接删库跑路
|
|
2
@kkk9 如果你想踩缝纫机,删库跑路是最快的方式,并且,也没什么用。
代码有版本控制不可能删掉,数据库大概率有备份,如果买的 RDS ,binlog 的备份粒度很可能是五分钟,你全库 drop 毫无损失。至于服务器,如果也是买的 ECS ,那肯定是有快照的。 |
|
3
讲个门槛高一点的:用元编程的思路写某一类业务——即给业务写一套 DSL ,然后把 DSL 的高阶逻辑做成宏的形式。这样在后面的开发中难免触发死循环还不好找死循环的原因,笑。
|
|
4
根据我调试的经验:
1. 能上多线程,就上多线程。 2. 能搞分布式(微服务), 就搞分布式. 3. 按自己爽的方式写代码, 完全不考虑性能因素, 比如用一些高阶函数, 类似 <a list with few items *at first*>.foreach, x.map, etc. |
|
5
再加一条:
4. 增加依赖, 为了一个排序, 引入一个科学计算库. |
|
chaoschickSep 22, 2023 via Android
6
switch 分支中少些几个 break
|
|
levelwormSep 22, 2023 via Android
7
用不安全的方式加几个 exploitation
|
|
youggSep 22, 2023 via Android
8
不要直接在经过你手的代码上动歪心思,commit log 追根溯源始终能找到你。
-然而你可以试试供应链攻击- |
|
9
加班写出来的代码不需要任何技巧全是坑
|
|
10
最重要的是有理有据,让人看不出你是故意的。😂
|
|
11
多依赖一些已经停更的第三方库就可以了!!
|
|
12
不用刻意添加,平时写出来的代码已经遍地都是坑了。
|
|
ruanimalSep 22, 2023
13
把所有新特性都用上,数据结构和算法都往复杂了搞,接口多封装几层
|
|
14
只要是复杂的逻辑不写注释,估计连你自己过几天都不会了。。。还要踩什么缝纫机
当然,像我这样容易把复杂逻辑写简单的,就得刻意去做了。嗯这确实有点难度啊。。。不如随便找个能把简单逻辑写复杂的人替我写一下,这种人才我可以一抓一大把。 |
|
15
我一般是相信自己的实力,正常写代码就行。肯定都是坑。
|
|
dangyuluoSep 22, 2023
16
写汇编
|
|
chingyatSep 22, 2023 via iPhone
17
单线程的程序改成多线程,并且不加锁.
|
|
18
正常发挥就行了,不用刻意
|
|
cookiiSep 22, 2023 via Android
19
最恶心的还是搞多线程,用事件去触发,把代码调用链路断开。
|
|
AbocederSep 22, 2023
20
@chaoschick 你这在测试那一关就过不了吧
|
|
jadelikeSep 22, 2023
21
我一般是相信自己的实力,正常写代码就行。肯定都是坑。
|
|
miniliukeSep 22, 2023
23
写一些超出自己能力的偶发 BUG 代码:比如随便写个无锁并发容器、写个算法依赖时间增长的一旦机器时间自动同步程序就会出错。利用一些编程中容易混淆的错误:比如队列写入操作用数据满了直接返回 false 的方法导致丢数据、故意不处理一些可能出现异常的地方、多线程使用线程不安全的容器
|
|
24
你正常写就行了
|
|
chendySep 22, 2023
25
一般程序员正常拉屎就能把后人恶心死了,不用多想
|
|
26
希望楼主记住这句话:玩火者,必自焚。
你觉得工资和你的能力不匹配就换一家跟你匹配的嘛,真没必要故意搞这些事情。 作为员工,要有老板(主人翁)意识:努力推进工作、思考创新解决办法,提升产品价值,一起做大蛋糕。 |
|
csliveSep 22, 2023
27
|
|
twofoxSep 22, 2023
28
上传修改过的工具库 jar 包到私库
多用存储过程 |
|
GBdG6clg2Jy17ua5Sep 22, 2023
29
多引入一些自己的私有工具库。
|
|
LuJasonSep 22, 2023
31
1. 搞特殊的版本:用新特性 或者 用旧的已经被遗弃的特性
2. 增加依赖,用一些不知名的模块 |
|
32
正常发挥就行
|
|
33
@cslive 我们公司的人日常都是 List<Map> 梭哈,这样公司就不能没有我们。哈哈
|
|
chaoschickSep 22, 2023
34
@Aboceder 既然我我说了这个例子 自然是在生产中遇到过
|
|
wu67Sep 22, 2023
35
把代码写得尽可能多或者尽可能少, 然后不写注释, 神仙难救.
|
|
36
不用埋坑的,你把所有听说过的中间件往项目里面塞就行了,项目到最后没有多少人能接过来,知识量太大了。
你还获得高高手得称号,这不美哉? |
|
Mystery0Sep 22, 2023 via Android
37
如果,自己没有离职,然后这堆代码线上出了问题,造成大的损失是不是后面要自己把这些坑一一填好?或者直接强行毕业没赔偿?
|
|
bruce0Sep 22, 2023
38
说一个 go 的, 返回一个 `var err *T` 这样的 error, 快的话,可能一眼就找到了,慢的话可能排查一天也查不出来, 尤其是在 多层函数调用的嵌套里
|
|
chenPiMeiHaoChiSep 22, 2023
39
26 楼什么情况,一时分不出认真的还是反讽?
|
|
PromtheusSep 22, 2023
40
我觉得这是个有趣的想法,虽然看上去不太道德。但是往往资本家对你不道德的时候,又没人站出来了。
|
|
41
不过你这几个方法太刻意了 ,一下就查到了。要装的像是自己菜导致的,而不是故意这么写。我觉得比较简单的方法就是搜集下公司历年出的问题,然后照着写。一般这种问题都是运行好久才爆出来的。撑死了就是和前辈犯了一样的错而已
|
|
liuidetmksSep 22, 2023
42
尽量使用新东西,边看 demo 边写那种
|
|
wqhuiSep 22, 2023
43
用 String 代替 enum ,多用 json\object\var ,时间久了没人敢保证自己知道里面究竟有什么东西
|
|
devopsdogdogSep 22, 2023
44
你能碰服务器或者版本包,你可以手动改代码 不提交 git 服务器。 这种是天花板了
|
|
45
@andytao 员工给蛋糕做大了,老板吃完抹嘴给留点渣不?
|
|
FelldeadbirdSep 22, 2023
46
看你要埋的坑要具有多大的破坏了。推荐结合时间触发需求加逻辑判断。
if( time > 2022-09-22 && 1 =1 ) 类似这种,1= 1 只是例子,现实中应该是一种业务判断,写代码有时候写等号会只写一个,导致判断恒久生效。 switch 结构中漏写 break 也行。 这种逻辑错误是直接影响公司正常运作的。属于隐性破坏。 当然了,要求写测试的团队一般有工具校验出这种问题。 所以埋坑最终应该以自己实际情况自己整理合适的坑。 |
|
XbluerSep 22, 2023
47
[把全局变量变成私有;]
反掉了吧 |
|
nothingistrueSep 22, 2023
48
@shmilypeter #2 1 ,如果你不想踩缝纫机,那就别干能导致你踩缝纫机的事。2 ,删库跑路是踩缝纫机的充分条件,不是必要条件。
|
|
LieNoWellSep 22, 2023
49
不建议这么搞,没必要,以直报怨,以德报德。
如果真想搞,那就把代码混淆一下,各语言都有方案,相信我,真的会吐 |
|
enzoccSep 22, 2023
50
mongo TTL 索引
|
|
51
故意埋坑最终可能只有 5%影响到了你坑的人/组织,而 95%影响的只是和你一样的其他打工人。所以考虑下有无别的手段吧
|
|
sky857412Sep 22, 2023
52
服务启动时,启动一个后台线程跑任务,然后在特定数据情况下,线程挂掉,后台任务停止运行
|
|
ShowYourPromptSep 22, 2023
53
公司没有 cr ,那可太简单,直接关键业务模块打包成静态库,源代码只有我有....
|
|
54
正常写代码就行了
|
|
skiySep 22, 2023 via iPhone
55
?结果苦的是下一个接手的同行。到时接手的同行,直接把坑往 v2 一发…又是一轮的口诛笔伐。
?往后的背调不打算过了? |
|
wuqi5920Sep 22, 2023
56
|
|
shawnshSep 22, 2023 via Android
57
用 C++写,内存泄漏就够了
|
|
thinkmSep 22, 2023
58
用人名作为变量名
int peter = 3; double vincent = 1.0; |
|
59
关键的条件判断处少写一个=号,合理
|
|
dcsuibianSep 22, 2023 via Android
60
要我就不埋坑,何苦为难下个打工人
|
|
61
不提议这么做,但是技术方案很多,代码中各种宏,还有 goto 横飞。
|
|
wu00Sep 22, 2023
62
为什么要主动去干这种事呢...
我都是把能填的坑先填了,不能填的提前告知,不然会觉得丢人 |
|
tabris17Sep 22, 2023
63
所有代码写在一个文件里
|
|
64
之前公司出现过开发离职删了几个文件,的确过了几个月才发现问题,排查半天 Git 找到人。
技术老大人好,内部告知一下捂住了,说人家还年轻。我估计会有人告诉那个开发。 不然按照我们当时老板的性格,那个人警察上门少不了。 供参考。 |
|
sakae010Sep 22, 2023
65
多用已经停更的或很老的第三方包就行
|
|
me1onsodaSep 22, 2023
66
操作数据库。大多数情况账号权限混乱,不知道是谁操作的,把索引删了之类的
|
|
67
写开源库,然后你的项目引用🌚
|
|
e9pWeUbh9PGCnp95Sep 22, 2023
68
闭着眼睛直接上多线程, 什么数据竞争, 什么内存一致性, 统统抛脑后.
|
|
adimnSep 22, 2023
69
能异步处理的全部放到线程里处理, 嵌套, 三行代码单独写一个方法写一个类, 设计模式满天飞, 策略模式和观察模式是最容易挖坑的, 另外反射也给他用上
|
|
70
“把全局变量变成私有”
一看这第一句话就是外行写的。 |
|
wednesdaycoSep 22, 2023
71
java 的话试试这种
// \u000d a="world"; |
|
72
正常写就行了,坑不会少,而且确实是无意的,很无辜。
|
|
qiumaoyuanSep 22, 2023
73
“把全局变量变成私有”,感谢你对代码可读性的优化做出的努力。
所以说正常写就行了。 |
|
zidianSep 22, 2023
74
在注释中撒谎误导;
这不是每个项目都有的么 |
|
token10086Sep 22, 2023
75
多用 go to 语句, 变量命名产考 OOoo0o 和 Il1LLll 等形式
|
|
clfSep 22, 2023
76
想办法把磁盘塞满()
|
|
jackmodSep 22, 2023
77
|
|
justin2018Sep 22, 2023
78
1. 代码写成💩山
2. 重复代码 ctrl+c 和 ctrl+v 3. API 请求加定时器 |
|
keepfunSep 22, 2023
79
把代码写的高级点 一般人看不懂 多用高级特性 别人不敢动
|
|
RightHandSep 22, 2023 via Android
81
看组内技术如何,多用设计模式,突然离职。故意埋坑容易被发现,多用设计模式是正当优化
|
|
opengpsSep 22, 2023
82
好像有个 github 项目就是这么搞的
|
|
pengtdydSep 22, 2023
83
把注释删掉就可以了,可以开发一个插件一键删除所有注释
|
|
yousabukSep 22, 2023 via iPhone
84
当然是:数据溢出,内存溢出,条件性的(漏判)进入死循环,条件性的内存非法引用了。
|
|
wangxin13gSep 22, 2023
88
少写注释,在 java 里用科里化,多用 Map<String,Object>
|
|
shyangsSep 22, 2023
90
先和老闆敬酒三杯,再寫. (三杯不夠喝十杯)
喝完酒後,走路無法走直線,你的邏輯思維也是,但是你卻察覺不到,會覺得我沒醉,在醉酒和宿醉狀態正常發揮即可. |
|
LeeeeexSep 22, 2023
91
|
|
zypy333Sep 22, 2023
92
不要用任何第三方库,全自己写
|
|
hyperbinSep 22, 2023 via Android
93
正常写就行(doge
|
|
FeaturesSep 22, 2023
94
国内的话,写个代码,每个月随机几天,200 个线程,超时时间 10 秒,每 100 毫秒请求一次谷歌
IO 问题基本不占用 CPU ,不占用内存,很难排查 |
|
learningmanSep 22, 2023
95
Java 全部 Object ,C 全部 void*,要用的时候再 cast
|
|
joinSep 22, 2023
96
用 rust 或 c++即可。
|
|
wyl986Sep 22, 2023
97
你就正常发挥
|
|
sprite82Sep 22, 2023
98
你可能想找的是这个,但是你要是这么做了,可能是自己承担这个后果。写少了,没什么影响,写多了,肯定大骂哪个鲨笔写的,一看 git 记录:哦,是我写的 🤡
https://github.com/trekhleb/state-of-the-art-shitcode |
|
99
@Promtheus 对,我的意思就是第一要伪装成自己菜导致的,第二要过一段时间才会有很难排查的,并且也影响业务的后果。
|