本周结对编程追加作业：记录收获。坦白说，我的收获多而杂，一时不知从何说起，以下试图从各方面简要谈谈。
一、编程能力收获
从编程能力方面，我收获的主要是类的设计思路和算法设计。在作业要求blog的指引下，我和同伴一同思考、选用类，最终决定采用我提议的方案，类中的变量名、变量数量都是由我提议和设计完成的，主要基于要求的功能的实现。变量以外，还需要设计类的函数，这就涉及到算法层面。一开始，我对于生成运算式方面非常生疏，翻了半天谭浩强红皮书，又在团队作业的小组中讨论了一阵，终于决定采用树的形式生成，辅以栈形式实现。相关函数及代码可以参考我的作业报告博客，都附有一定的注释。
除了主干程序外，还有单元测试的设计。由于运用VS单元测试框架时还比较生疏，我和同伴一起找了一些文档查阅，实现了比较基础的单元测试，但覆盖率没达到百分百。这主要是因为一些涉及全局变量、类变量的函数的单元测试函数编写方法我们没能掌握，只能使用断点debug方式代替单元测试，某种意义上做到了全覆盖。只能说单元测试之路任重而道远，在将来的团队项目中一定要好好落实真正的单元测试。
这次编程暴露出我数据结构方面的薄弱，选用完数据结构后，相关算法的编写也花了很多功夫，和同伴一起找了许多网站和资料作为参考，磕磕碰碰才最终完成，这使我对树结构、栈结构的操作和使用更加熟悉，也锻炼了我对于编程细节、逻辑严密性的把控，全方位提升了我的编程能力，但愿我能牢记这些相关知识，灵活运用在以后的学习工作中。
附图：类设计与类函数的部分截图
二、接口相关收获
之前从未将一个程序发布成dll，因而这第一次宝贵的经历自然伴随着各种困难。其一，按照网上的教程，我只能从零编写出非常基础的dll，却无法将已经编写好的cpp文件转换成dll。最终，在团队组的同学们的建议下，我和同伴终于找到了方便可行的转化方法。其实说来也简单，只要在头文件顶部添加预编译，在需要输出的函数前加上编译头即可，完全没必要像网上教程一般新建一个dll工程、预编译头等等繁杂操作。
以上就是关于接口的全部收获？当然不可能。这仅仅是开始。我们还没来得及沉浸于dll导出成功的喜悦，就被对接的UI组问翻了：为什么给的头文件里这么多内容？函数接口能不能多支持一些格式？
我们下载了群里其他组的配套头文件，发现其中仅仅含有需要输出的函数，而我们的头文件可谓无所不包：类定义，类中函数的定义，五脏俱全。于是我们恍然大悟，又设计了一个func.h文件，将需要导出的函数封装在其中，其他的信息则无需提供给UI。同时，我们改善了接口种类，原先UI需要先生成一个questionCore 类的变量，再调用变量.setting函数进行设置，再调用变量.getfile函数获得结果，非常复杂，且每个参数都需要设置；改善后，我们只提供三类setting函数，分别支持string输入、bool输入、文件输入，且自带输出，UI组只需选用其中的一个setting函数，就能直接得到结果，且对于不想设置的选项，可以输入-1、“”来取用默认值，非常方便。
这次接口的设计波折给了我很大启发：接口的设计要尽量简单化、多元化、智能化，编写的dll要力求实现“完美黑盒”，给用户提供最便捷、最舒适的体验。
附图：原先设计的接口，只提供一种类型的设置函数，且需要繁复的调用手续。
附图：改进后的设计接口，只提供三种setting方案，方便快捷，支持使用默认设置。
三、交流相关收获
结对作业的一大命题便是交流。我和队友的交流还算融洽。虽然他没有上过数据结构课，对树、栈等数据结构不太理解，但经过简单讲解以后他能很快follow上，并且提出了许多好的意见，比如筛选不合法式子的判断准则、括号添加和删除的功能等。在与队友的交流合作中，我学到了如何将自己的设计思路传达给同伴，学到了通过画图方式展示函数的架构（在队友的强烈建议下），也学到了意见出现分歧时应该如何协商解决。
除此之外，还有不同组间的交流。由于每组都要相互对接，我们与不同的UI组间基本都要打交道。第一次面对面对接时，由于我们没有说清楚功能，UI组调用方式出错导致迟迟不出结果，经过我们共同调试、发现问题，最终得以顺利对接。后来对接时，我们积极吸取了各UI组的建议，并结合群内做得比较好的UI组的接口设计作为参照，不断更新我们的对接功能，让我们的程序变得更易于使用。这些交流合作中，我学到了如何给自己的产品打广告，如何从他人的建议、示范中提升自我，如何给他人提建议，帮助他人完善功能。
附图：在与UI11组的对接中，我们发现界面的分辨率存在问题，导致显示不全，于是及时向他们反馈、建议，得到解决。
总而言之，本次结对编程给了我诸多益处，接下来的团队项目中，我一定要好好总结、做得更好。
原文地址：https://www.cnblogs.com/cgyr/p/8894234.html