你是否厌倦了编写简洁、可维护的代码？
你是否渴望编写无法调试的垃圾代码？
那么，你很幸运！
今天，我们将探讨 12 种最佳实践，它们将彻底摧毁你的代码库。
1. 从不测试代码
测试是给害怕错误的胆小鬼准备的。
不要为代码编写测试。跳过单元测试、集成测试和端到端测试，导致难以捕捉和修复错误。
只需将代码直接推送到生产环境中，让用户成为你的测试人员。他们会喜欢这种惊喜的。🎁
2. 模型过于复杂
当你可以创建复杂、错综复杂的模型时，谁还需要简单明了的模型呢？
将你的模型嵌套在其他模型中，并加入一些循环引用，以达到良好的效果。
此外，创建具有数百种方法和属性的单一模型。
这会使你的模型难以维护和理解。
而这恰恰是你的团队希望每天处理的事情！
3. 将业务逻辑与视图混合
在视图模板中嵌入复杂的业务逻辑，会给测试和维护带来挑战。
毕竟，谁不喜欢在视图、局部和纠缠不清的逻辑层中隐藏解决方案的代码谜题呢？
4. 从不写设计文档
文档是为那些希望自己的代码可以理解的loser准备的。
假设每个人都能凭直觉理解你的代码。
为什么要浪费时间编写注释、README 和 API 文档呢？让代码自己说话吧，即使它说的是胡言乱语。
5. 重复造轮子
框架有大量内置功能和库，可以让你的生活更轻松。
忽略它们！
编写你自己的身份验证系统、ORM 和路由框架。你一定会做得更好。💪
6. 不进行模块化开发
模块化是弱者的专利。如果你能拥有一个巨大的单体代码库，各种成千上万行的函数方法，为什么还要将应用程序分割成小的、易于管理的部分呢？
依赖关系越多越好！
7. 过度嵌套路由
创建具有多层资源的深嵌套路由。
这会导致路由混乱和性能问题。
8. 不用版本控制
Git？谁需要它？
只需将所有代码保存在本地计算机上即可。你又不需要与他人协作或回滚到之前的版本。
9. 随处使用全局变量
当你可以把所有东西都变成全局变量时，为什么还要传递参数呢？
这是一种引入隐藏依赖关系的绝妙方法，会让你的代码无法测试。
10. 忘掉命名约定
当你可以用各种字符随意命名变量和方法时，谁还需要约定俗成的命名规则呢？
让我们让其他开发人员猜测，确保没人能理解我们的代码。
11. 只在为时已晚时才重构代码
如果没坏，就不要修，对吗？
等到你的代码库变得一团糟无法维护时，再尝试一次性进行大规模重构。会出什么问题呢？
12. 硬编码一切
常量、动态配置和环境变量是为业余爱好者准备的。
直接在代码中对所有配置设置和神奇数字进行硬编码。更改它们轻而易举！
总结
这12 种最佳实践保证让你的代码库变得面目全非！
当然，这篇博文纯粹是出于搞笑娱乐的目的，希望你在实际开发工作中能做到这些建议的反面。
构建可维护、简洁的代码才是王道，因此请务必遵循最佳实践，祝你编码愉快！
更多精彩内容可关注
托儿所的前端秘籍