程序猿在开发中遇到的问题（复盘）

协作流程不规范
需求评审(全员) -> 需求明确后制定开发计划 -> 需求变动/调整 -> 二次需求评审 ,并及时调整开发计划 -> 开发,联调 ->自测(通过冒烟测试用例) -> 提测,修复bug -> UI 验收(开发调整) -> 产品验收(开发调整) -> 交付上线

1.通用

• 整理需求时间

• 开发/测试理解与产品需求相差较远

• 变更信息同步不及时，部分消息滞后或未接收

• UI设计稿-存在变更/缺失，评审环节准备不充分

• 文档、需求的论证、UI的评审可以提前，发现的问题也就被提前解决，开发的时候可以是确定的版本，而无需在研发阶段频繁”抖动“，减少不确定性因素对开发进度的影响

• 需求评审 产品 <==> 研发 双向答疑

• 需求在最开始没有想清楚，变更较多且规划性不强

• 项目评估

  • 自测时间缺失
  • 需求调整相关时间缺失
  • 评估缺失，需保证通过测试的冒烟测试
  • Bug复测 评估的时间较短，不可控变量偏多

• 开发客户端

  • 整理需求时间
  • 对需求理解不够透彻,有偏差
  • 功能还原度以及对需求完成度不够，不满足预期
  • 交叉维护困难，协同开发效率较低(分模块开发,尽量避免交集)
  • 代码有冗余，需要简化
  • Bug率偏高，应提高开发的严谨度和自测能力
  • 修复周期过长：SDK问题太多，添加自测环节(过冒烟用例)
  • 合理评估开发工期，预留自测环节时间，以保证UI还原度和代码质量
  • 变更信息同步不及时，部分消息滞后或未接收
  • 陌生领域没有做预研，例如SDK开发
  • 打包耗时
  • 代码冲突

• 产品

  • 跳过业务测试进入产品验收
  • 避免口头需求和需求变动，形成文档，需求变动后通知到相关责任人以及UI测试
  • 开发阶段频繁进行产品优化：需求调整/变更
  • 用例评审不够细化，后续变更/新增需求未经过新的用例评审
  • 版本规划功能难以版本切分，颗粒度不够细化

• UI : 跟产品及时跟进需求，保持需求同步,避免需求滞后UI

  • 切图返工
  • 纯色图 - IconFont
  • 渐变色 - 切图

• 测试：

  • 编写冒烟和详细测试用例并评审
  • 用例不完善
  • 状态难模拟
  • Bug描述不清晰(清楚)
  • Bug 难易程度,优先级,显示顺序

规避方案

• 开发严谨，开发时考虑代码的扩展性，尽可能抽象，封装，避免多次修改重复代码
• 对于需求变化(市场变化)，要根据需求优先级自我调整
• 产品方向,如果变化过大，则会导致重构(产品(开发)周期会过长)
• 确定好项目的deadLine，实实调整

未完，待续~