如何在代码中埋雷

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

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

前言

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

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

定时炸弹类

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

时间限制的逻辑

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

某些特殊情况下逻辑不同

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

错误引用的第三方依赖

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

死锁

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

不断缓慢增大的缓存

在 Redis 里不要设置过期时间，让他自然生长吧。

防御式编程类

没有人能维护你的代码，你就是神。

撒谎的注释

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

误导的注释

# todo 需要修改

# 这里可能存在 bug

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

以特殊方式存在的强依赖

• 依赖枚举字面值而不是属性

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

令人疑惑的变量名

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

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

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

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

只有你明白的框架

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

函数的命名与逻辑不符

func isGood() bool{

}

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

总结

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

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

coderlmn.github.io/frontEndCourse/unmaintainable.html