我为我们团队的高效而感到自豪。
触宝研发总监 孟雷如是说。
《如何通过结对编程进行高质量的软件开发》的学习笔记。
了解结对编程的概念，是否符合我们的团队，具体改如何实施。
软件研发模式的演化
- 瀑布模型
- 快速原型模型
- 螺旋模型
- 敏捷开发
- ？？？
开发和测试的困境
- 困难
- 在敏捷的短周期里面实现的其实是瀑布模式
- 在强调交付速度的过程中，开发飞擦画那个容易急功近利，为完成手头的工作而在架构方面做很多的妥协和折中，从而为日后的维护升级买下很多隐患。
- 水平参差不齐，很多地方写的很山寨，后面很多问题都是给前面的疏忽买单，产品一直处于不定加不定的状态
- 有质量的code review没空做
- 代码量大了，没空仔细review
- 研发过程当中的团队分工角色较多，因此从上游到下游的过程中，会有很多沟通方面的损耗，团队管理消耗更多。
- 正确的方法
- 从源头提高代码质量
- 注重代码的框架和设计，杜绝补丁加补丁
- 建立标准化的设计模型和代码风格
- 培养功能 + 测试 + 监控
- 关于结对编程
- 两人共用一台电脑
- 一起设计，写代码，测试
- 没有专门的测试环节，完成即上线
结对编程与传统软件开发流程的主要区别
- 利于只是的传递
- 避免没有明确文档的潜规则的坑
- 强迫接触不熟悉的领域，有利于培养全栈
- 代码风格，设计思想，强一致，不存在项目移交的风险
- 没有单点瓶颈，不怕人员流失
结对编程最佳实施方法
- 两个人必须使用同一台电脑，不能两台点啊弄，坐在一起
- 不准带手机，写程序的人有义务监督观察者使其注意力集中
- 每半天或者一天轮换一次（驾驶员、领航员）
- 固定时间，中间休息
- 搭档定期更换，但必须有梯度
- 必须开发测试都做
使用场景，成功案例
- 周日程
- 周一 发布上一个正式版本
- 周二 开发测试
- 周三 开发测试
- 周四 代码冻结，公测
- 周五 观察，新需求
- 天日程
- 10:00 - 10:30 站会讨论
- 10:30 - 12:00 结对编程
- 1:30 - 3:00 结对编程
- 3:30 - 6:00 结对编程
- 必须遇到的问题
- 执行力！执行力！执行力！
- 组员：想做自己的事情，我是不是在浪费时间？
- Leader的顾虑：影响项目进度
- 两人会有性格等各方面的问题，会有争议，争吵；Leader介入参与讨论
- 没有测试不放心
- 必然要抓住的重点
- 确保团队成员对于业务目标以及研发流程的理解和认同
- 帮助团队成员摆脱固有的研发角色的分工
- 重点关注架构设计，模块重用
- 增强开发人员的自我测试意识
- 必须付出的代价
- 组员：很少有私人控件
- leader：需要尽可能的带大家做靠谱的事
- 适用场景
- 偏极客分为的公司或团队
- 公司规模较小，但业务形态相对来说比较稳定
- 业务需求较多，迭代较快
- 有一定逻辑复杂性，需要较好的基础架构的项目
- 人员流动较大，缺乏系统化文档
- 相关数据
- 线上Crash率下降
- 完成任务数 / 人 先降后升
- 关于测试
- 美欧专门的功能测试不代表没有测试
- 跟单纯的功能测试说再见！
- 以自动化持续继承测试作为研发的基础
- 注重多平台，性能测试，压力测试，耗电量测试等高级测试，以及测试工具和框架的研发
- 注重线上实时监控，研发，测试，监控一体化