这是我参与「第四届青训营 」笔记创作活动的第10天
课堂笔记
代码质量
1.小小的代码错误，可酿成巨大的损失
2.优秀的代码可信赖、易维护、Bug少
3.面对庞大的代码需遵循可维护性规则
4.圈复杂度作为度量工具的计算和用途
举例
遍历一个列表，返回总价格
问题：
一个什么列表？
什么的价格？
为什么要计算这个列表的价格？
- 具备明确的语义，代码即注释
- "获取购物车中所有条目的总价格”
- 阅读代码时，不需要做其他联想
- 没有泛指，能明确知道变量名，便于调试
代码评审
1.CR能前置地发现代码质量问题
2.将CR做得小点能加快评审效率
3.谦逊坦诚面对不同的评审意见
CR关注的点：
- 命名:是否定义的清晰准确的变量名、函数名、类名
- 描述: CR的描述是否准确对应到功能
- 风格:是否遵循统一-的规范
- 文档:是否同时改动了文档
- 设计:这段代码做什么?
- 功能:实现的逻辑是否与目标一致?
- 是否覆盖了全部的场景?
- 是否存在异常?
- 简洁:是否有更高性能的方式?
- 测试:可测试性?测试覆盖?
重构实践
1.代码中常有技术债，理解它，处理它
2.重构是在有限范围内运用一定的方法
重构的概念
对软件内部结构的调整，目的是在不改变软件可观察行为前提下，提高可理解性，降低修改成本
技术债的产生与应对
Technical Debt,本应采用最佳方案，但妥协了，从而给未来带来了负担。 就像是债务，先欠下了，短期得到了好处，但长期必须偿还。
代码上线
分支开发模式
持续集成概念
Continuous Integration, CI,将代码频繁的集成到代码仓库中 持续集成并不能消除Bug,而是让它变得容易发现和修正
灰度发布
逐步扩大用户群体
课后总结与反思
代码开发注意要点
- 理解圈复杂度和代码质量的重要性
- 代码评审能够前置的发现代码问题
- 重构是限定范围和方法的改造技术
- 代码需要持续得到验证才能够上线
优秀代码
- 完全满足产品需求
- 功能变更时只需进行很少改动
- 发生异常时优雅的报错，或者能自我恢复
- 新的场景能够优雅的处理，即便没有提前预见
- 受到安全攻击时系统能够处于安全状态下
