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

安卓客户端研发素养

代码质量

• 优秀代码的特质：软件可信赖，易于维护，Bug少

  • 产品需求层面：满足所有边界条件
  • 功能变更时：只需要进行较小的改动
  • 发生异常时：能够报错溯源或者自我修复
  • 运用到新的场景时：在及时没有提前遇见的情况下也能优雅的处理
  • 拥有抵御安全攻击的能力，让系统能处在安全状态下

• 代码可维护性原则

  • 统一的编码规范：命名规范，代码规范，注释规范
  • 工程结构稳定：目录清晰，模块化、组件化，依赖可控，访问权限控制
    • 可以轻松的在代码库中找到实例，重复使用其他人的代码
    • 轻松的将新的依赖添加到项目，以及迁移到新的依赖版本
    • 依赖项稳定，并且很少破坏代码
  • 优秀的方案实现（保持代码先进性）：文档，用例，可测性，代码高内聚低耦合
    • 灵活适应不同架构设计思想
    • 可以运用自动化测试手段，保障重构的正确性
    • 使用场景的用例考虑充分，大多数情况下不需要推倒重来

• 圈复杂度的概念（Cyclomatic Complexity，也称条件复杂度，是一种软件度量手段）

  • 圈复杂度 = 边数量 - 节点数量 +2
  • 圈复杂度 = 函数中的判定条件 + 1

代码评审（Code Review）

• 避免很多不符合规范的代码合入仓库，拉动整体团队成长

• CR的作用：

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

• CR关注的点

  • 代码规范：
    • 命名：是否定义的清晰准确的变量名、函数名、类名
    • 描述：CR的描述是否准确对应到功能
    • 风格：是否遵循统一的规范
    • 文档：是否同时改动了文档
  • 功能设计：
    • 设计：是否良好的设计并适用于当前系统
    • 功能：实现是否正确
    • 简洁：实现是否简洁，如果过于复杂是否有更简单的方式
    • 测试：是否包含自动化测试，可测试性如何

• 如何处理不同意见

  • 正视批评，不要因为批评而沮丧
  • 修复代码，补充注释或修复问题
  • 自我反思，花点时间考虑一下CR是否有效

重构实践

• 技术债

  • Technical Debt ：本应该采用最佳方案，但是妥协了，从而给未来带来了负担
  • 公开技术债：一开始就与利益相关方权衡技术债利弊，明确影响和解决方案，可以将所有技术债量化公示，短期和长期技术债可以区分对待大家遵循相同的编码规范
  • 消费技术债：每次迭代确定一定数量的技术债作为消费目标，无需偿还技术债的产品即将消亡，一次性的原型或者短命的产品避免使用过时的技术，旧资产和老方法充斥着安全漏洞，难以集成

• 重构：在有限范围内运用一定的方法

  • 定义：对软件内部的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本
  • Code Smell预示着即将变坏，需要用重构不断对抗Code Smell
    • 例：重复的代码、过长的方法、过大的类、过长的参数列

代码上线

• 代码需要持续得到验证才能上线
• 代码验证的方法：
  • 分支开发模式：明确的分支开发模型
  • 持续集成（Continuous Integration）：将代码频繁的继承到代码仓库中，持续集成不能消除Bug，而是让他变得容易发现和修正
  • 灰度发布：逐步扩大使用的用户群体：在不断放量中修复bug
  • AB实验：排除干扰因素，实验判断方案哪个更优