这是我参与「第四届青训营」笔记创作活动的第13天

课程主要内容

• 代码质量
• 代码评审
• 重构实践
• 代码上线

代码质量

优秀代码的特质

具备明确的语义，代码即注释。 阅读代码时，不需要做其他联想。 没有泛指，能明确知道变量名，便于调试。

产品需求： 完全满足

功能变更： 只需要进行较小的改动

发生异常： 优雅的报错，或者能自我恢复

新的场景： 优雅的处理，即便没有提前预见

安全攻击： 系统能够处于安全状态下

软件可信赖，易于维护，Bug比较少

代码可维护性规则

统一的编码规范： 命名规范、代码格式、注释规范……

强制所有编程相关的命名严禁使用拼音与英文混合的方式

稳定的工程结构： 目录清晰、模块化、组件化、依赖可控、访问权限……

可轻松在代码库中找到示例，重复使用其他人的代码

可以轻松地将新的依赖项添加到其项目，以及迁移到新的依赖项版本

依赖项稳定，并且很少破坏代码

优秀的方案实现： 文档、用例、可测性、高内聚低耦合……

灵活适度应用不同架构设计思想，譬如: Binder IPC通信、loC/SPI解耦

可以运用自动化测试手段，保障重构的正确性

使用场景的用例考虑充分，大多数情况下不需要推倒重来

圈复杂度的概念

圈复杂度： Cyclomatic Complexity，也称条件复杂度，是一种软件度量手段。

圈复杂度 = num(edges) - num(nodes)+ 2

圈复杂度 = 判定条件数+1

圈复杂度	代码状况	可测性	维护成本
1~10	清晰	高	低
10～20	复杂	中	中
20~30	非常复杂	低	高
>30	不可读	不可测	不可测

建议圈复杂度控制在15以下

小结

小小的代码错误，可酿成巨大的损失 优秀的代码可信赖、易维护、Bug少 面对庞大的代码需遵循可维护性规则 圈复杂度作为度量工具的计算和用途

代码评审

CR的目标

通过阅读源代码来检查代码是否符合编码规范，前置发现代码质量问题

代码质量提升

• 代码可读性
• 代码正确性
• 代码安全性 学习交流
• 经验传授
• 学习提升
• 开放的沟通氛围

CR的形式

• 发出邀请
• 结对编程
• 团队定期

CR关注的点

代码规范

• 命名：是否定义的清晰准确的变量名、函数名、类名
• 描述：CR的描述是否准确对应到功能
• 风格：是否遵循统一的规范
• 文档：是否同时改动了文档

功能设计

• 设计：是否良好的设计并适用于当前系统
• 功能：实现是否正确
• 简洁：实现是否简洁，如果过于复杂是否有更简单的方式
• 测试：是否包含自动化测试

小CR的好处

审查更快，更彻底，更容易合入代码，如果被拒绝，可以快速返工

如何处理不同意见

正视批评

对事不对人，不要因为批评而沮丧

修复代码

第—反应是澄清代码，补充注释或者修复问题

自我反思

花点时间，考虑一下评论是否有效

小结

CR能前置地发现代码质量问题

将CR做得小点能加快评审效率

谦逊坦诚面对不同的评审意见

后记

通过本次课程，理解了圈复杂度和代码质量的重要性，以及代码评审能够前置的发现代码问题。