1.第一坨屎-变量
为了不让下任『接盘侠』看到代码骂娘，我劝你善良。请不要使用如下方式命名变量：
1.拼音命名（不会英文就去下载个某道词典，翻译一下嘛。name 总比 mingzi 好辨认吧？字数还少，还能国际通用）
2.使用简单字母命名（a/b等等，别说其他人，过两天自己都不晓得写了个什么鬼）更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』
3.异想天开（不要随便拍脑袋起名，要做到见名知义。总不能一个 id 的列表，你叫个 item 吧？xxx_id_list 稍微强一些吧？）
4.不要命名冲突（最起码在一个函数内，不能重复。project 既是生产项目又是测试项目？变量不断被覆盖，奇奇怪怪的 bug 就够你喝一壶的了）
❝这种病的病根儿一般是词汇量匮乏，治疗建议某道翻译。
❞
5.查询数据库时，变量与字段名、模型类或者表名不一致（查的 Product 就不要叫 Mobiles；查的 name ，就不要叫 leader ）
2.第二坨屎-注释
为了第二天代码还认识你，请你添加注释。
1.一定要添加注释，最起码重要的逻辑部分覆盖到。
2.注释要清晰、易懂、简单明了。
3.注释不是流水账，不是每一行代码的解释，而是某一块逻辑的说明。
4.对于复杂的数据结构请举例说明。
5.每个函数的说明文档起码要有。更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』
3.第三坨屎-嵌套
1.不要里三层外三层的 if-else，逻辑判断可以有，但是一定有更加简明的表示方法。嵌套的层级太多，不仅难理解，还影响美观。
2.简单的一层 if-else ，有时三元运算符会更加方便。
3.若想你的程序执行效率高一些，就不要循环套循环。
4.无论何时何地都不要在循环里面有查询数据库的语句。也许一次访问，只需要查询几次数据库，但是用户量大时，能把你数据库搞瘫。多使用一些 bulk_create 或者 bulk_update 等等类似的批量操作方法，一次访问远比多次访问数据库效率高。
4.第四坨屎-逻辑
1.请将复杂的逻辑单独抽出来做成函数或者类，不要让你的接口内部过于复杂。否则即使有注释，也太晦涩难懂。
❝将复杂逻辑抽调后，不光能被其他地方调用，还能使你的接口清晰明了。
❞
2.实现一个功能，肯定不止一种方法，要不断的去优化，去寻找一条最快最简单的路径。
❝当然优化的前提是存在，即使用笨办法也得先实现再说。
❞
5.第五坨屎-校验
1.一定要添加必要的校验操作！一定要添加必要的校验操作！一定要添加必要的校验操作！重要的事情说三遍，想要保证程序的健壮性，永远不要相信用户的任何操作！（用户不是开发人员，一定会做出你想不到的操作。为了保证程序安全、数据安全，请添加校验）更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』
2.常用的校验有：为空校验、长度校验、规则校验、常识性校验（最起码上限不能低于下限）、业务校验、边界情况校验等。
6.第六坨屎-单元测试
1.自动化远比人工可靠。
❝不是说人工偷懒，而是重复的点点点难免会有遗漏的情况。添加单元测试，就要可靠的多。
❞
2.单元测试并不是负担，当你重构代码时，你会发现它的重要作用！
❝有单元测试做保障，测试通过就代表重构成功。不需要重复界面点点点，太浪费时间。当然前提是：你的单元测试是可靠的。
❞
3.重要的方法、逻辑，单元测试一定要覆盖到，它会保证你的程序安全上线！更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』
4.code_review 只能是看规范，看逻辑，肉眼能核对运行结果吗？提交代码先跑一遍单元测试，是否可靠的多？
❝这就体现出来自动化测试的好处了，最简单的方法，在
❞GitLab上集成单元测试，这样提交代码后自动运行单元测试，不通过肯定不会合并到master分支，保证线上环境安全。
7.第七坨屎-重用
1.将公共的代码抽调出来，做成公共模块、通用组件。「减少程序代码量」，让程序起飞。
2.重用的优点不光是省代码这么简单，如果相同的代码这也有，那也有，出错怎么办？改几遍？「便于维护」
3.将常用的数字抽出一个常数文件，其他地方调用变量的形式使用，这样维护一个常数文件比维护分散在各个角落的代码要好的多。
