Android-研发素养|青训营笔记
这是我参加「第四届青训营」笔记创作活动第九天
研发者素养
代码质量
- 具备明确的语义，代码即注释
- 阅读代码时，不需要做其他联想
- 没有泛指，能明确知道变量名，便于调试
代码可维护性规则
- 统一的编码规范：命名规范、代码格式、注释规范
- 稳定的工程结构：目录清晰、模块化、依赖可控、访问权限
- 优秀的方案实现：文档、用例、可测性、高内聚低耦合
圈复杂度的概念
代码评审
通过阅读源代码来检查代码是否符合编码规范，前置发现代码质量问题
代码质量提升
代码可读性
代码正确性
代码安全性
学习交流
经验传授
学习提升
开放的沟通氛围
关注的点
代码规范
- 命名：是否定义的清晰准确的变量名，函数名，类名
- 描述：CR的描述是否准确对应到功能
- 风格：是否遵循统一的规范
- 文档：是否同时改动了文档
功能设计
- 设计：是否有良好的设计并适用于当前系统
- 功能：实现是否正确
- 简洁：实现是否简洁，如果过于复杂是否有更简单的方式
- 测试：是否包含自动化检测
重构实践
重构的概念
- 对软件内部结构的一种调整，目的时在不改变软件可观察行为前提下，提高其可理解性，降低其修改成本
遵循重构的方法
- 封装成员变量
- 方法提取
- 一般化类型
- 将子类的函数移到父类
- 将父类的函数移到子类
- 方法更名
技术债的产生和应对
Technical Debt。本应采用最佳方案，但是拖妥协了，从而给未来带来了负担
就像是债务，先欠下了，短期得到了好处，但长期必须偿还
公开技术债
一开始就与利益相关方权衡技术债的利弊，明确影响和解决方案可以将所有的技术债量化公示，短期和长期的技术债可以区分对待大家遵循相同的编码规范
消费技术债
每次迭代确定一定数量的技术债作为消费目标无需偿还技术债的产品即将消亡，一次性的原型或者短命的产品避免使用过时的技术，旧资产和老方法充斥着安全漏洞，难以集成
代码上线
分支开发模式
持续集成概念
- Continuous Integration，CI，将代码频繁的集成到代码仓库中持续集成并不能消除Bug，而是让它变得容易发现和修正
灰度发布
- 逐步扩大使用的用户群体，1%-10%-30%-60%-100%
AB实验
- 干扰因素太多，代码直接上线无法量化收益，指标波动无法归因
