为后人挖坑指南

　　核心思想就是越过基础建设，复制黏贴拿起键盘就是干，一把梭。

　　

1）文档

　　文档一定不能写，越是复杂的业务逻辑，越是要惜墨如金。

　　什么流程图、示例代码、SQL查询语句、项目组件等都不能有，在一份WIKI文档中，写上几行意思意思，描述下这个业务的功能即可，或者就不要有文档了，一把梭。

　　某些重要业务常规的排错步骤也不能有，出现问题就让后人去查源码和数据库，一步步的调，基本弄个几个小时后一般都能查明原因。

　　各类团队规范也不必制订，像团队的代码规范、协作流程规范等都不需要存在，有问题口头传达即可，一次没传达成功，那就再来两次三次，总归会有成功的那次，下次继续这样周而复始。

2）组件库

　　组件库怎么能有，各自写各自的，自己写完了，绝对不要和其他人分享，就让它默默地呆在某个文件夹内。

　　自己知道有这么多组件就行了，其他人要相关功能的组件，如果问了，那就口头说下有这么个组件。

3）注释

　　越是重要的业务，越不要写注释，让后人去猜吧，最多在路由前面加个说明。

　　数据库表、字段的注释，也不要写，看表名和字段名就行了，而有些字段值是常量的，它们的含义也一并省略，让后人继续猜。

　　如果能让几个组的人都没猜出来含义，那这个坑挖的非常成功。

4）服务

　　当前自己组维护的服务，也记得不要写，后人遇到问题了，自然会去查那些服务。

　　给源码就可以了，一切尽在源码中。后人如果要查服务什么功能，就去问运维，运维不知道就看代码。

5）监控

　　让线上代码自由自在的跑着吧，不需要监控他们的健康情况。有问题运营或客服会反馈，再看源码也不迟。

　　性能优化量力而行，跑着没啥问题就行，当不能跑的时候，就重构吧。

6）代码

　　一个函数几百行是家常便饭，不要解耦，函数内的 if-else 要嵌套的多点，让人不容易发现哪个 if 和哪个 else 对应。

　　要利用好 JavaScript 弱类型的特点，在一些边界条件中埋些隐蔽的坑。多用全局变量，以及命名要普通，不要包含语义。

　　多用冷门框架或技术，配套文档和资源越少越好的那种，后人难以找到帮助信息，一遇到问题就得查源码。

7）项目

　　项目为了赶工期，将可配置的地方写死，边界条件能省则省，不要考虑扩展，各种临时方案。

　　项目跌跌撞撞能顺利上线就行了，接下来就留给后人来打补丁，接历史包袱。

 

　　暂时想到这些，如果你遇到过或经历过哪些挖坑或填坑的经历，欢迎在文末评论区分享。

标签：指南,不要,代码,挖坑,后人,源码,文档,组件
来源： https://www.cnblogs.com/strick/p/14862699.html