核心思想就是越过基础建设，复制黏贴拿起键盘就是干，一把梭。
1）文档
文档一定不能写，越是复杂的业务逻辑，越是要惜墨如金。
什么流程图、示例代码、SQL查询语句、项目组件等都不能有，在一份WIKI文档中，写上几行意思意思，描述下这个业务的功能即可，或者就不要有文档了，一把梭。
某些重要业务常规的排错步骤也不能有，出现问题就让后人去查源码和数据库，一步步的调，基本弄个几个小时后一般都能查明原因。
各类团队规范也不必制订，像团队的代码规范、协作流程规范等都不需要存在，有问题口头传达即可，一次没传达成功，那就再来两次三次，总归会有成功的那次，下次继续这样周而复始。
2）组件库
组件库怎么能有，各自写各自的，自己写完了，绝对不要和其他人分享，就让它默默地呆在某个文件夹内。
自己知道有这么多组件就行了，其他人要相关功能的组件，如果问了，那就口头说下有这么个组件。
3）注释
越是重要的业务，越不要写注释，让后人去猜吧，最多在路由前面加个说明。
数据库表、字段的注释，也不要写，看表名和字段名就行了，而有些字段值是常量的，它们的含义也一并省略，让后人继续猜。
如果能让几个组的人都没猜出来含义，那这个坑挖的非常成功。
4）服务
当前自己组维护的服务，也记得不要写，后人遇到问题了，自然会去查那些服务。
给源码就可以了，一切尽在源码中。后人如果要查服务什么功能，就去问运维，运维不知道就看代码。
5）监控
让线上代码自由自在的跑着吧，不需要监控他们的健康情况。有问题运营或客服会反馈，再看源码也不迟。
性能优化量力而行，跑着没啥问题就行，当不能跑的时候，就重构吧。
6）代码
一个函数几百行是家常便饭，不要解耦，函数内的 if-else 要嵌套的多点，让人不容易发现哪个 if 和哪个 else 对应。
要利用好 JavaScript 弱类型的特点，在一些边界条件中埋些隐蔽的坑。多用全局变量，以及命名要普通，不要包含语义。
多用冷门框架或技术，配套文档和资源越少越好的那种，后人难以找到帮助信息，一遇到问题就得查源码。
7）项目
项目为了赶工期，将可配置的地方写死，边界条件能省则省，不要考虑扩展，各种临时方案。
项目跌跌撞撞能顺利上线就行了，接下来就留给后人来打补丁，接历史包袱。
暂时想到这些，如果你遇到过或经历过哪些挖坑或填坑的经历，欢迎在文末评论区分享。