BG5BJM HAM 📡 

代码审查清单

提交者自查项

优先级	检查项
💕	通用
P1	代码有效。实现了预期功能，逻辑正确。
P1	没有重复代码。
P2	没有冗余代码。
P1	没有注释代码。
P1	循环设置了次数及恰当的终止条件。
P2	代码容易理解。
P1	所有类、变量及方法设置了合适的修饰符。
P1	没有调试代码。
P1	使用了合理的数据结构。
P1	性能可以满足大量数据（依业务场景区分是否必要）。
P2	代码易于维护。
P1	未完成的代码应标记TODO，并计划完成。
P2	代码尽可能模块化。
P1	不会发生内存泄漏。
P2	方法提前返回且不影响代码可读性。
P2	可伸缩，可支持大量用户（依业务场景区分是否必要）。
💕	编码格式
P1	代码对齐，有恰当的留白。容易识别代码块的开始与结束。
P1	遵循编码规范。
P1	遵循正确的命名约定（帕斯卡（Pascal）命名法、驼峰（CamelCase）命名法）。
P2	代码行不应过长，使用合理的换行增强可读性。尽量不需要水平滚动来查看代码。
P1	函数或类是否太大（行数过长）？函数或类是否承担了太多职责？
P2	每次提交应尽可能只修改一项功能，不要提交过多的代码，如修改多个功能建议在多个合并请求（Pull Request 或 Merge Request）中拆分。
P1	遵循团队的编码风格。
💕	安全
P1	检查所有数据输入（类型、长度、格式和范围等）并对其编码。
P1	编译时警告尽可能少，有无法消除的警告应标注说明、理由。
P1	不能隐藏异常或错误。
P1	校验无效的参数值。
P1	不能硬编码任何敏感数据。
P2	检查和编码输出值。
💕	测试
P1	代码可测试。代码应结构化，不要添加或隐藏太多的依赖项，可以兼容测试框架。
P2	有单元测试，并尽可能测试全面。
P2	单元测试是为了测试代码是否执行了预期功能。

审查员检查项

优先级	检查项
💕	设计与职责实现
P1	解决方案设计得足够好，满足设计预期。
P1	代码完成了它该做的事。
P1	解决方案或代码容易理解。
P1	接口（API）或用户界面（UI）使用直观。
P1	使用了正确的框架、接口、库和服务。
P1	没有重复代码，不允许复制粘贴代码。
P1	代码足够模块化。
P2	使用了特定语言的最佳实践，合理的设计模式。
P2	代码遵循了面向对象的设计原则：单一责任原则、开闭原则、里氏（Liskov）替换原则、接口隔离、依赖注入。
P2	代码没有非必要的编译或运行时依赖。
P2	代码抽象合理。
💕	逻辑错误和缺陷
P1	代码能处理所有预见的用户行为。
P1	代码不应任何输入或外部事件中断。
💕	错误处理和日志
P1	正确处理错误和异常。
P1	正确恰当地记录日志。
P1	没有无用的日志。
P1	校验或处理无效的参数值。
P2	用户友好的错误信息。
P2	使用第三方工具或库需要捕获它们返回的异常和错误。
💕	文档和注释
P1	接口必须有合理恰当的注释。
P1	代码必须有必要的注释。
P2	没有多余的注释或描述。
💕	测试与可测试性
P2	代码可测试。
P2	代码应对所有可能的输入进行全面测试。
P2	有足够的自动化测试（单元、集成、系统测试）
P2	代码更改能否被现有的测试覆盖？
💕	性能
P1	代码更改积极地影响性能。
💕	可读性
P1	合适的函数、方法、变量名提高代码可读性。
P1	代码位于正确的文件、文件夹、包（package）中。
P2	流程控制易理解。
P2	代码没有太多的条件语句或分支。
P1	没有不可访问的代码（dead code）。
P2	没有注释掉的代码。
💕	安全
P1	检查所有数据输入（类型、长度、格式和范围等）。
P1	对敏感用户信息（密码、公民身份号码、银行卡号等）及富文本输入编码。
P1	正确处理认证与授权。
P1	持久化之前保证用户数据安全。
P1	敏感数据（用户信息、信用卡信息）应经过恰当的加密后安全传输和存储。
P1	应校验并处理用户输入，解决安全漏洞（跨站脚本攻击、SQL注入等）
P1	没有远程代码执行漏洞。
P1	敏感信息没有硬编码在代码或注释中。