码农挖坑指南.docxVIP

码农挖坑指南 2021-07-17 核心思想就是越过基础建设，复制黏贴拿起键盘就是干，一把梭。 　　 1）文档 　　文档肯定不能写，越是简单的业务规律，越是要惜墨如金。 　　什么流程图、示例代码、SQL查询语句、项目组件等都不能有，在一份WIKI文档中，写上几行意思意思，描述下这个业务的功能即可，或者就不要有文档了，一把梭。 　　某些重要业务常规的排错步骤也不能有，消灭问题就让后人去查源码和数据库，一步步的调，基本弄个几个小时后一般都能查明缘由。 　　各类团队规范也不必制定，像团队的代码规范、协作流程规范等都不需要存在，有问题口头传达即可，一次没传达成功，那就再来两次三次，总归会有成功的那次，下次连续这样循环往复。 2）组件库 　　组件库怎样能有，各自写各自的，本人写完了，确定不要和其他人共享，就让它悄然地呆在某个文件夹内。 　　本人晓得有这么多组件就行了，其他人要相关功能的组件，假如问了，那就口头说下有这么个组件。 3）注释 　　越是重要的业务，越不要写注释，让后人去猜吧，最多在路由前面加个说明。 　　数据库表、字段的注释，也不要写，看表名和字段名就行了，而有些字段值是常量的，它们的含义也一并省略，让后人连续猜。 　　假如能让几个组的人都没猜出来含义，那这个坑挖的格外成功。 4）服务 　　当前本人组维护的服务，也记得不要写，后人遇到问题了，自然会去查那些服务。 　　给源码就可以了，一切尽在源码中。后人假如要查服务什么功能，就去问运维，运维不晓得就看代码。 5）监控 　　让线上代码自在拘束的跑着吧，不需要监控他们的健康情况。有问题运营或客服会反馈，再看源码也不迟。 　　功能优化量入为出，跑着没啥问题就行，当不能跑的时候，就重构吧。 6）代码 　　一个函数几百行是家常便饭，不要解耦，函数内的 if-else 要嵌套的多点，让人不简约发觉哪个 if 和哪个 else 对应。 　　要利用好 JavaScript 弱类型的特点，在一些边界条件中埋些隐蔽的坑。多用全局变量，以及命名要一般，不要包含语义。 　　多用冷门框架或技术，配套文档和资源越少越好的那种，后人难以找到挂念信息，一遇到问题就得查源码。 7）项目 　　项目为了赶工期，将可配置的地方写死，边界条件能省则省，不要考虑扩展，各种临时方案。 　　项目跌跌撞撞能顺当上线就行了，接下来就留给后人来打补丁，接历史包袱。 ? 临时想到这些，假如你遇到过或经受过哪些挖坑或填坑的经受，欢迎在文末评论区共享。 - END - 推举阅读： DDD衰亡的缘由以及与微服务的关系 全局负载均衡与CDN内容分发 谈谈雪花算法的使用及源码 流利说统一可观看性平台实践 DevOps 工程师需要必备哪些技能？ 关注我 学习架构学问