孟雷 如何通过结对编程进行高质量的软件开发

文字内容
1. 如何通过结对编程进行高质量的 软件开发 孟雷 触宝研发总监
4. 孟雷 • 触宝研发总监 现任触宝研发总监职务,曾先后 就职于微软中国,EMC 中国, 担 任软件研发相关工作,专注于敏 捷开发与团队管理。 1
5. • 软件研发模式的演化 • 开发和测试的困境 • 结对编程与传统软件开发流程的主要区别 • 结对编程最佳实施方法 • 适用场景,成功案例 2
6. 软件研发模式的演化 • 瀑布模型 • 快速原型模型 • 螺旋模型 • 敏捷开发 • ??? 3
7. 开发和测试的困境 • 在敏捷的短周期里面实现的其实是瀑布模式 • 在强调交付速度的过程中,开发非常容易急功近利,为完成手头 的工作而在架构方面做很多的妥协和折中,从而为日后的维护升 级埋下很多隐患。 • 水平参次不齐, 很多地方写的很山寨, 后面很多问题都是给前 面的疏忽买单, 产品一直处于补丁加补丁的状态 • • 有质量的代码 review 没空做 研发过程当中的团队分工角色较多,因此从上游到下游的过程中, 会有很多沟通方面的损耗,团队管理消耗更多。 4
8. 正确的方法? • 从源头提高代码质量 • 注重代码的框架和设计, 杜绝补丁加补丁 • 建立标准化的设计模型和代码风格 • 培养功能 + 测试 + 监控 的研发理念 5
9. 关于结对编程 • 结对编程是一种敏捷软件开发的方法,两个程序员在一个 计算机上共同工作。一个人输入代码,而另一个人审查他 输入的每一行代码。输入代码的人称作驾驶员,审查代码 的人称作观察员(或导航员)-- 百度百科 6
10. 对于结对编程最简单的描述 • 两人共用一台电脑 • 一起设计, 写代码, 测试 • 没有专门的测试环节, 完成既上线 7
11. 结对编程与传统软件开发流程的主要区别 • DNA为什么是两条? 密码为什么要设两遍? • 一个缺陷的指出 > 事后几天的补救 • 非常有利于知识的传递 • 会避免很多没有明确文档的,潜规则的坑 • 每个人被强迫接触自己不熟悉的领域, 有利于全栈工程师的培养 • 代码风格,设计思想, 强一致, 不存在项目移交的风险 • 没有单点瓶颈, 不怕人员流失 8
12. 具体实施方法 • 两个人必须使用同一台电脑, 不能两台电脑, 坐在一起 • 不准带手机,写程序的人有义务监督观察者使其注意力集中 • 每半天或一天轮换一次 (驾驶员,领航员) • 每天固定时间, 中间休息 • 搭档定期更换, 但必须有梯度 • 必须开发测试都做 9
13. 结合具体流程示意图 上个正式版本 发布(周一) 开发测试 (周三) 开发测试 (周二) 每日日程表 10:00 – 10:30 站会讨论 10:30 – 12:00 结对编程 1:30 – 3:00 结对编程 3:30 – 6:00 结对编程 6:00 ~ 自由安排 观察,新需求 (周五) 代码冻结,公 测(周四) 线上crash 修复, 发 布 一个完整开发周期为一周 10
14. 必然遇到的问题 • 执行力!执行力!执行力! • 组员: 想做自己的事情, 我是不是在浪费时间? • leader 的顾虑: 影响项目进度 • 两人会有性格等各方面的问题, 会有争议,争吵 • 没有测试不放心 11
15. 必然要抓住的重点 • 确保团队成员对于业务目标以及研发流程的理解和认同 • 帮助团队成员摆脱固有的研发角色的分工 • 重点关注架构设计,模块重用 • 增强开发人员的自我测试意识 12
16. 必须付出的代价 • 组员: 很少有私人空间 • leader 需要尽可能地带大家做靠谱的事 13
17. 适用场景 • 偏极客氛围的公司或团队 • 公司规模较小,但业务形态相对来说较为稳定 • 业务需求较多,迭代较快 • 有一定逻辑复杂性,需要较好的基础架构的项目 • 人员流动较大,缺乏系统化文档 14
18. 成功案例 • 触宝电话在海量用户的前提下能够高质量地从一月一版本的 发布周期逐渐提高到一周一发布的快速迭代,同时,线上 P1级bug数量减少至原来的5%,代码架构更加合理,模块 化程度较高,团队也更加精简高效。培养了一批精通移动互 联网前后端,客户端开发的高素质研发团队。 15
19. 相关数据 16
20. 关于测试 • 没有专门的功能测试并不代表没有测试 • 跟单纯的功能性测试说再见! • 以自动化持续集成测试作为研发的基础 • 注重多平台, 性能测试, 压力测试, 耗电量测试等高 级测试, 以及测试工具和框架的研发 • 注重线上实时监控,研发,测试,监控一体化 17
21. 半年以后 • 人人都是全栈! 18