如何在代码中埋雷

如何在代码中埋雷首先必须声明，这只是个我离职时，和同事聊天讨论的玩笑，讨论给了我一些新的启发。作为一个有职业操守的程序员，实际操作埋雷这种事还是免了，折磨的还是自己的老同事，给自己带来更多麻烦。

同时，有代码，必然有痕迹，有 git 纪录，也必然会被最终找到，不要心存侥幸。

前言埋雷是一门高超的技巧，尤其是如何定时生效，不会炸到自己。更进一步的还有“防御式编程”，这就又是一门高超的技术了，这里略略分几类，总结一下，只为乐子，不希望投入实践。

反过来看，这些“技巧”，又是我们想要吧代码写好，必须避免的情况了。

定时炸弹类未来的某时某刻会爆炸，你在谋害接手你代码的人。

时间限制的逻辑有些逻辑只能在当前与之后的一段时间内起效，在更远的未来会无效。比如写死的魔法值年份，依赖当前月份的逻辑等等。

某些特殊情况下逻辑不同比如在某些情况下，最后一位为多少的订单号，会与其他订单表现出不同的行为。这样的问题，更加隐蔽，更加难以复现，如果是在不重要的逻辑里，甚至很久之后才会被发现。

错误引用的第三方依赖被你引用的包存在某些问题，有些情况下会出现问题，只有你知道这是什么样的问题，这会大大消耗其他人的精力。

死锁某些情况下可能出现的死锁，比如数据库行锁，操作难度较大，但后果也令人痛苦。

不断缓慢增大的缓存在 Redis 里不要设置过期时间，让他自然生长吧。

防御式编程类没有人能维护你的代码，你就是神。

撒谎的注释其实也不用撒谎了，只是没来得及更新注释。

误导的注释# todo 需要修改

# 这里可能存在 bug

这些注释足以让人汗流浃背，如果实在一个一千行的函数里，带着一点具体的，误导性的信息，就更美好了。

以特殊方式存在的强依赖依赖枚举字面值而不是属性

另一个系统依赖此系统以魔法值存在数据库里的值，这样你永远不能更新这个魔法值了。

令人疑惑的变量名违背约定俗成，扭曲使用的人意志的变量命名方式。比如特意反向的 bool 类型，会被更改的全局变量，等等。

变量名称与对应的内容存在偏差，这会大大增加阅读者理解的难度。

用没有实际含义的 a,b,c 来命名变量。

有些语言允许内部作用域存在同名变量，多多使用这个特性吧。

只有你明白的框架引入一个复杂框架只为了完成一个很小的任务，这个框架的配置与细节如此麻烦只有你看得懂。比如响应式的框架。

函数的命名与逻辑不符func isGood() bool{

}

然而函数里却更新了数据库，谁都想象不到吧。

总结还是好好当人吧，我写的都有点说不出话了。

搜到一篇更细节的，可以看看。

coderlmn.github.io/frontEndCourse/unmaintainable.html

文档信息本文作者：nyaaar本文链接：https://nyaaarlathotep.github.io/2024/07/17/%E5%A6%82%E4%BD%95%E5%9C%A8%E4%BB%A3%E7%A0%81%E4%B8%AD%E5%9F%8B%E9%9B%B7/版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）