前言
文章以真实项目实践总结为基础,选取了结对编程中的典型场景,叙述了在敏捷交付项目中,开发者在实践结对编程时经常遇到的挑战。场景中会找到你或你身边同事的影子吗?
结对编程的十个场景
角色假设
A:Senior DEV,结对编程实践者
B:Junior DEV,刚接触结对编程
场景一:结对前的约定
A:好,那任务列表(check list)我们梳理清楚达成一致了,现在要开始编码工作了。你们之前是怎么结对编程的?
B:嗯~怎么结对编程具体指什么?
A:好吧,那不然我们一个人写45分钟,然后休息10分钟,再交换?
B:好啊,可以的。
**开始结对之前,做一些约定是较好的开始。**协商结对编程过程中如何交换角色,多久休息一次等。例一:A写 45分钟,休息15分钟,然后B写45分钟,休息15分钟;例二:TDD A写测试,B写实现,A重构,B写测试,A写实现,编码40分钟左右休息10分钟。
场景二:知识传递
A:休息时间结束,那我们开始?
B:好,该我编码了。那我们接下来要构造接口的返回值了
A:对的,我们可以新建一个文件,导出一个方法,在该方法中构建接口返回值
B:嗯,那我们现在去找一个地方放新建的文件
A:可以在 XX 目录下建这个文件
…B找到对应的目录并打开...
B:嗯。咦,这个目录已经有很多文件了,我看一下其他文件都是干什么的。
A:嗯,其实这个库有自己的模式,不然我们去看一下库的文件结构说明文档?
B:好呀,那说明文档在哪呢?
A:README文件中有入口,可以从那里点进去。
B:哦。
…查看结构说明文档...
B:所以我们在给上游发请求前如果要构建请求参数的话,可以在文件夹下面建立XXRequestParams.js文件用来构建参数,从上游接口拿到返回值后,如果要对值做一些转换的话,可以在文件夹下面建XXTransformer.js文件构建接口返回值。是吗?
A:对的,这样的话可以做到把部分功能放到单独的文件中,避免文件过大。还有一个好处是更好写测试。
**及时发现结对编程的伙伴(peer)某方面上下文的欠缺并耐心传达,帮助新人快速获得项目知识。 **当发现peer某方面的不足时,我们要意识到发展他人的机会来了。在上下文传递或知识点讲解的过程中,我们可能也会有新的发现。
场景三:Senior直接上手解决问题
A:我们需要给 state 中增加一个 XX字段
B:对,我们现在要去state文件。这个文件,好像不是加到这个state文件呀!这个文件呢?不对不对,好像也不是。
A:我们要构建的页面属于XX模块,得把state字段加在XX目录下的state文件中。
B:嗯嗯,有道理。那这个文件,嗯~好像也不对