团队复盘总结 | Android - 刘同学

Android 开发问题

一. 开发节奏混乱

暴露问题:

1. 着急开发导致需求理解不到位, 如: 公告列表及公告详情, 应当显示富文本, 开发时未考虑到, 直接显示了接口获取的文本, 导致显示出来格式很乱
2. 新功能开发没有优先级, 虽然还没有因此出现问题, 但是可以想到, 如果手中正实现某一功能, 用户此时要求加紧实现另一个功能, 就会出现这个功能还不完善就开始实现另一功能的情况, 最终可能两个功能的质量都不高
3. 开发完成后没有进行足够的测试, 导致第一次发布后, 出现了大面积的闪退和功能性 BUG

问题解决:

• 完善开发模型, 对开发中的每一个环节都做出规范和约束 (还未整理完毕, 整理完毕后会形成详细的文档)

  • 进行开发的必要条件是有需求文档或设计稿
  • 拿到需求后, 确保自己能理解需求
  • 涉及业务的新功能先写开发文档
  • 每个新需求实现后都及时进行测试, 出现问题能快速定位;
  • 发布前借助第三方进行兼容性测试, 用户能运行是基本要求
  • 等...

• 手中同时有多个需求时, 先和用户明确各个需求的优先级, 制定开发计划

• 开发计划包括: 开发&测试&问题处理

二. 风险意识不足

这里的 风险 指的是自己写的代码可能导致应用出现的问题

暴露问题:

1. 缺少异常处理, 如: 生意概况页缺少无网络判断, 获取不到数据时, 会出现显示异常
2. 功能稳定性差, 如: 定位功能一开始使用原生 API 进行实现, 没有考虑原生 API 获取定位的稳定性, 导致前端获取不到定位数据
3. 性能开销太大, 导致应用被系统杀死, 如: 启动页直接添加图片, 图片加载占用的内存不会自动被释放, 导致低端机型很容易运行闪退

问题解决:

• 在动手写代码前先要考虑该场景可能涉及到的异常情况, 使用注释在该场景的代码块上做简单提示
• 使用不熟悉的 API(或者第三方库) 进行开发时, 先调研其优缺点, 以及可能存在的隐患
• 善用 Android Studio 提供的性能检测工具, 将保证(或提升)应用性能也算在开发的约束内

三. 被动接受需求

六月份进行项目开发时, 需求很多, 任务很重, 我们只能赶着进度开发. 这种情况存在不合理性, 过于追求项目的开发速度就会影响到开发的质量, 没有质量的产品上线后会使我们开发更被动。 我们应当根据自己的情况, 对开发进度提出自己的看法, 确保进度在用户可接受的范围内的同时也努力保证开发的质量

与用户交流的问题

一. 回应用户反馈时态度不端正

暴露问题:

1. 用户提交 Bug 后, 没有及时告知用户解决方案
2. 用户的反馈是宝贵的资源, 处理反馈问题时不应只处理反馈问题

问题解决:

• 接收到用户反馈后, 依据反馈问题的严重性, 进行优先级处理
  • 影响用户正常看数据的问题, 包括但不限于: 闪退/数据无法显示等, 应当第一时间回复用户, 并进行修复
  • 不影响用户正常看数据的功能性问题
    • 可以用户自行解决的, 将解决方案发送给秀仪, 由秀仪反馈给用户
    • 需要代码修复的
      1. 在工作日志中记录解决状态, 告知用户我们已经在解决
      2. 记录在和 iOS 共同维护的文档中, 安排在开发计划中进行修复, 该文档 Android 和 iOS 每天进行互检

二. 被动提出解决方案

当前用户反馈的问题存在重复性, 每次回复解决方案的话效率太低. Android 端和iOS 端会维护一个问题处理的文档, 针对一些可能出现的常见问题, 在文档中给出解决方案. 和客户对接人员协助, 引导用户出现问题先进入常见问题文档进行自查, 无法解决时再联系客户对接人员, 这样既减少了客户的工作量, 也减少了我们的工作负担.

三. 没有站在用户的角度去思考

希望用户配合时, 提供给用户的配合信息太少, 导致用户还需要反问我们更多信息, 交流成本太高. 在之后与客户的交流中, 我们应当往更深一层进行思考, 考虑一下客户接收到我们的信息后会进行的下一步操作, 保持我们的思想走在客户的前面. 我们给客户的, 要比客户需要的更多!

与 Android 团队成员的协作

新同事加入团队后, 先以了解项目业务为主, 清楚项目整体框架以及用到的技术, 要求他们尽快熟悉团队的协作方式

在新项目开始时, 遵循以下标准进行协作:

• 新需求共同阅读, 对项目有一个大的了解
• 开发任务在保证完成项目的情况下, 按成员能力进行分配, 各自评估完成时间
• 项目难点一同讨论解决方案
• 开发时代码提交协作遵循 《移动端 - Git 规范》