结对编程

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

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

前期主要我担任驾驶员，队友担任领航员，完成程序的主要逻辑。驾驶员负责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可能并不是这样。这体现出了对接双方看待项目角度不同，容易替对方决定一些事情，导致很多问题。要避免这种情况，需要的是充足的沟通，这位同学如果在群里公开提出这个问题，说明具体原因，或许早就可以解决。

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