结对编程收获

结对编程

这次项目之前我并没有了解过结对编程,在《构建之法》初次读到时,就感觉这种形式十分有趣,两个人编程既可以更好的解决编程问题,也会带来新的交流方面的问题。

我和结对搭档在清明假期的第一天早上开始讨论项目,花了一早上确定了整个项目的基本结构。这是我就体会到了结对的部分优越性,一个人的想法可能会有漏洞,不足,两个人就很难同时忽视某个问题,达成思维上的互补。单人编程时我时常会由于考虑不足,后期大量重构代码,结对编程就很难出现这种情况。

前期主要我担任驾驶员,队友担任领航员,完成程序的主要逻辑。驾驶员负责coding,领航员在一侧提供建议,或者搜索相关资料。一开始互相难免有些尴尬,毕竟被别人看着编写代码,和看别人代码,都不是程序员喜欢的事情。但是一段时间之后,熟悉了之后,也就各自进入了状态,不再是两个人编程,而是作为一个团队编写程序。领航者作为旁观者,经常能发现驾驶员代码中的一些小错误,减少后期debug的时间。在驾驶员花费时间具体实现时,领航员也可以仔细思考算法等问题,这样就很少出现卡在一个功能,需要停下来研究算法的情况,编程效率就很高。

后期,我们角色互换,完成了各种模块和接口的封装。深深感到虽然领航员不需要自己上手编写,依然需要注意力高度集中在程序上,让两人的思路统一。很多时候领航甚至比具体coding更重要。

对接

我们先学习了DLL的编译,这个过程中也走了很多弯路,生成dll之后自己测试总是不能使用,最后发现是x64和x86不能混用。在UI组处运行是,也出现了一些bug,包括QT编译器的设置,编码格式等等,增长了很多对接的经验。

因为没有统一的接口,我们尽量让接口函数简单,便于UI方面的使用,返回vector以供使用。之后我们也编写了详尽的API手册,帮助对接。一个让我感触很大的事情是,阅读一组UI同学博客时,他吐槽了Core组setting传参时很多采用传递string设置操作符,而QT直接获得的是很多bool值,这中间的转换逻辑让他感到很麻烦。这个暴露出的问题是Core组由于可能并没有学习QT只是,并不清楚QT组的具体需求,从我们的角度,传递一个string显然比一堆bool更合理,但是对于UI可能并不是这样。这体现出了对接双方看待项目角度不同,容易替对方决定一些事情,导致很多问题。要避免这种情况,需要的是充足的沟通,这位同学如果在群里公开提出这个问题,说明具体原因,或许早就可以解决。

主要的收获是交流第一,沟通能解决很多问题,而一个全面科学的文档是最高效的交流方式。

 

posted @ 2018-04-20 23:59  Mr_c233  阅读(205)  评论(2编辑  收藏  举报