结对编程感想

结对编程感想

实在是抱歉，我记错了ddl因此迟交了。真的抱歉不是故意的，希望没有扰乱助教的时间安排。

代码

本次结对编程整体代码的设计均由我完成。此前我从来没有做过这种事情，都是直接上手一通瞎写；此次加入了设计部分，主要就是为了合作和共同编码考虑。由此的确带来了很高的效率的提升。但对设计代码结构的同学要求略高，自己的思路能否被队友理解也是其中的困难之一。但不妨碍代码设计成为提升效率的有效的方法（在团队合作中）

由于是第一次合作编程，当功能差不多实现的时候我发现代码已经差到不能看了，出现了好多冗余的重复的部分，某些地方的逻辑混乱到写代码的本人都不愿意看。因此我就考虑着重构一下代码（用一些c++面向对象的特性）（虽然之前也用了类封装，但其实都只是装模作样写一下，本质的思想其实还是函数式编程）。但其实我对这些特性是一无所知的（或者知道一些，但也只是概念，从来没有动手写过）。这次尝试了一下虚函数、抽象类和类继承，令代码的可读性和规范性有了很大的提升。另外对Debug也帮助很大，后期测试时出现bug我都能很快地反应出是哪一块代码错了（甚至可以精确到哪一个语句）。

还有就是不要怕困难。我在代码重构的过程中试着写过模版类，发现也就那么回事（虽然后来我发现模版类并没有什么用就换了思路）。很多名词看着高大上，其实自己试着实现的时候也就感觉没怎么样。以后要大胆地尝试新东西。

合作

也许编码并不是结对编程考察的重点，但两个人的合作绝对算是重点了。如何拆分任务，如何交流，如何理解对方的意图和表达自己的意图，都困难重重。

首先我觉得拆分任务的前提是你对这个工程需要做哪些事情了然于胸。这需要很多的经验。由于此次的结对编程任务简单，因此对于我们大三的来说拆分任务并不是特别困难。至少我们两人之间的任务分配，根据两人能力水平而言还是很公平的。但对于我很陌生的团队任务来说，拆分任务就像是不可能完成的任务了。事实上我带着自己组做团队任务时都是瞎布置的任务，我心里是真的没有数，不知道这次给谁的任务重了，给谁的任务又轻了。

下面就是交流了。其实交流最高效的方式还是文档（读的书里好多都强调了这一点）。但还是由于这次任务不是很复杂，因此我们并没有采用这种方式。刚开始我们试着QQ或者电话交流，发现真的是很难讲到一起去，要凑在一起写代码又很难在时间上达成一致，因此碰到了好多困难，也浪费了很多时间，做了很多不必要的事儿。后来我们通过程序注释，或者把程序以伪代码（其实就是英语句子）附进代码，是提高了一些效率的。

还有就是当两个人对某件事的认识做不到一致时，一定不要线上交流而是当面交流，否则真的很难说清楚（听起来像谈恋爱一样）

对接

和UI组的对接不是我的任务，因此我很难在这里总结什么。

这里解释一下原因吧，我想用json传参和json传出表达式及其答案，然而队友觉得太复杂好难不要这样。当时我在准备GRE因此就直接让他写了，后来他使用了函数直接传参，把表达式和答案直接写入txt。我觉得好愚蠢就也没有再管。然而事实上后来setting函数出错了，我还是看了一下他的代码觉得不太行于是改（重写）了一遍。

事实上我在这里的任性毫无道理，因此也应该向队友道个歉。UI组的水平本来也就参差不齐，要是用了json而他们不会解析那就很尴尬了。（其实我也不会，我只是想尝试一下新东西）。我们需要的是好的产品（和UI组组合起来成为好的产品）因此在这里一味地追求技术并不可取。

还有就是很多bug的问题，自己跑的时候觉得自己考虑得已经很全面了，而在UI组那里一对接就出现一堆问题。也许这就是系统集成调试的作用吧，单个单元测试其实并不能考虑到方方面面，而放到整个产品的层面上看才能看出某些问题。有的bug甚至需要用户使用一段时间才能发现。