代码开发规范和常识

一、前言

第一次用这么大的标题，怪不好意思的，总结一下，我在开发代码初期遇到的常识问题和习惯问题吧。

二、正文

命名要有意义：避免使用不具意义的变量名（如 a, b, c, list），应该根据上下文选择能够表达其含义的命名。命名清晰的代码有助于后续的阅读和维护。
代码格式化：统一的代码格式对于团队协作至关重要。对你写的代码使用工具（MAC 如 IntelliJ IDEA 的 command + option + L）进行格式化，可以保持一致性，减少格式问题影响代码质量。
不要随意改动他人代码：除非你明确理解并需要修改他人的代码，否则不要随便改变。理解他人代码的逻辑是防止引入新问题的基础，后面代码出事故了，就找你兜底了。。。。，然后上面那个格式化，强调了是对选中的格式化！！！
删除未使用的类或代码：提交前，检查自己写的类和方法是否有用，如果没有使用到，应该删除掉，避免代码冗余。
避免不必要的代码逻辑变动：在提交之前，检查自己修改的代码，确保没有误改他人逻辑。工具如 IDE 中的比较视图，可以帮助快速识别差异。
git 代码比较：通过 Git 查看红色（删除的部分）和绿色（新增的部分）区域，确保自己提交的修改内容符合预期。
NPE（NullPointerException）处理：在调用对象的方法或属性时，要考虑可能的 null 情况。可以使用工具类进行 null 检查，或者利用 Optional 类型。
避免 get(0) 造成 NPE：如果操作集合时直接访问 get(0)，可能出现 NPE。建议先检查集合是否为空，或者使用更安全的方法，如 isEmpty()。
方法内的 NPE 处理：每个方法的进入点都要做 null 检查，避免因 null 引发异常。可以使用断言、Optional 或自定义的工具方法来加强鲁棒性。
工具类中的 NPE 处理：当使用工具类时，也要注意其内部是否有适当的 null 处理。例如，EmailUtils 中如果没有做好 null 检查，可能会导致后续的问题。
调用命名规范：外部调用时使用 client 比如说 openfeign，rpc，内部调用时使用 api 就是前端界面可以直接调用出发。这样有助于区分外部和内部服务调用的不同角色和职责。
异常日志记录：e.printStackTrace() 不应该用于生产环境的异常记录。应该使用 log.error() 打印更详细的日志信息，包括异常类型、堆栈信息以及相关上下文。
命名规范：遵循阿里巴巴的命名规范，动词用作布尔值命名（如 isDelete），传递参数时使用名词。这样可以让代码更符合常规的命名习惯，减少误解。
服务调用失败时处理：服务调用失败的原因可能有很多种，例如网络问题、服务器故障等。返回时尽量封装异常信息，避免暴露过多细节。
lambda 和 builder 使用：lambda 和 builder 是简化代码和提高可读性的有力工具。掌握这两种技术能够让你编写更加优雅和高效的代码。
服务间通信返回值封装：在服务调用时，返回值使用对象封装可以提高扩展性和可维护性，避免直接返回基础类型，讲人话就是使用大对象包括各种属性。
自审代码：在提交前，假装自己是 code reviewer，检查代码的正确性、规范性和可读性。这可以帮助你发现很多自己写代码时忽略的细节，重点可以看看是不是哪里填写错了，哪里填写反了，或者是是不是又改了
Maven 问题的处理：遇到 Maven 配置问题时，不要直接在其他项目中复制解决方案。应该通过 Git 回滚或查看历史记录来恢复到正确的状态，要不然一堆 change。
测试覆盖率：测试覆盖率有些是触发不了的，有可能是 “前辈” 遗留的代码，如果总是 case 走不到，可以向有经验的同事请求
测试平台：测试平台也可以进行测试，然后可能是针对不同模块不同测试环境，记得看清楚你的项目是哪个模块，部署在哪个环境
CURL：在 network 上捕获请求，右击可以复制 curl，apifox 支持导入，导入之后就可以直接模拟测试环境请求了，可以查看测试环境传的是什么参数
开源精神：学会写文档进行分享，一个好的文档是应该跨职业跨小组跨公司的。