文章目录
1. 注释2. 代码抽取、封装3. 业务相关4. 结果校验5. 调试6. 提交代码7. 及时总结8. 向同事学习
1. 注释
业务代码必须要写好注释。变量的命名也需要考虑规范，尽量和业务名相关，这样也算是一种注释，让人看得清楚。纯逻辑代码注明该块代码的作用是什么，入参、返回值的注释。一头(入参)、一尾(返回值)、一大概(功能)，让他人拿到就能用，不用想怎么实现的，应用为先。
2. 代码抽取、封装
使用两次及以上的代码块，即可考虑封装成函数，抽取复用的代码，提出入参为变量。涉及到对某个字段或者特定数据等进行多种操作时，考虑写成类的形式。某业务的操作涉及的数据和逻辑功能较多且复杂，考虑将业务操作和数据分离。
3. 业务相关
写代码前一定要考虑好业务需求，评估需要实现的业务；理清业务之间的关系，业务中也分轻重，并不是所有的业务都是需要立即去实现的。使用思维导图梳理业务，将业务走一遍，再思考每一步怎么用代码实现。磨刀不误砍柴工，明确需求、思路更重要，代码只是实现的手段。
4. 结果校验
写测试脚本，校验是必不可少的一环，有的字段配置下发后，是否成功未知，测试未知，需要通过重新获取来验证，常常使用assert来判断。结果数据的展示，使用 f 语法来展示数据（比%s、.foramt()更清晰），在pytest+Allure 中使用allure.attach(数据，‘描述信息’)
5. 调试
遇到bug，重复运行两遍不如debug一遍，调试最能发现问题所在。调试技巧需要不断地提升，提高调试的能力。
6. 提交代码
提交代码前先自己检查一遍，将调试的代码删除，比如使用main函数调试的代码，将没用到的变量、导包、无用的注释删除， 再使用 Ctrl+Alt+L 将代码格式化后符合PEP8规范。每次提交的信息，都应该简明扼要地描述当前提交的代码。每天记得更新项目代码，避免在开发新的脚本过程中落后master太多，也便于提交代码时合入、减少冲突。
7. 及时总结
每写一项业务、一个脚本，及时记录自己在其中遇到的问题，有哪些教训可以总结哪些东西。有的业务只有在用自动化覆盖时才去了解，一旦了解后就记录该块的业务知识、注意点，业务这种东西一旦学习了，以后就只要花很少时间就能拿起来。
8. 向同事学习
同事写的代码总有值得学习的地方，学他人之长，补己之短。对于别人写的不好的地方，思考是否有优化的空间。刚开始可以学习模仿别人写代码，慢慢地试着优化代码。
