结对编程感想
写在前面
本博客为笔者在完成软件工程结对编程任务后对于编程过程、最终得分的一些感想与经验分享。此外笔者还对于本课程的结对编程部分提出了一些建议。
| Tips | Link |
|---|---|
| 作业要求博客 | 2019年软件工程基础-结对项目作业 |
| 笔者的总结博客 | [2019BUAA软件工程]结对作业 |
对结对编程过程的感想
经过长达两周的结对编程，结合《构建之法》中对结对编程的描述以及这两周的亲身经历，笔者对于结对编程的过程有了以下的感想。
-
两人合作，更易解决问题
在编程的过程中，笔者两人一同遇到了许多的困难：从编程语言的使用，到算法的设计，再到代码的实现。相较于单人编程，两人同时对问题进行思考，通过讨论发现两人解决问题的漏洞，互补双方解决问题的方法，有效地解决问题。比如，在笔者同伙伴一起编写单词链搜索函数时对于每个代码分支，递归调用都进行了类似一人推演一人审核的模式，有效地突破了程序中的难点。 -
相互学习，共同进步
在进行结对编程时，每人都有一段时间负责在对方编程的过程中在旁边进行审核。在“旁审”队友编程的过程中，笔者从队友的编程方式吸取了许多有用的部分，比如算法实现的思路，代码编写习惯等。将这些优点融入到自己的编程中，优化了自己的编程方式。 -
同时编程，降低沟通难度
结对编程要求两人同时在一起进行开发。笔者与队友在大多数时间里是按照结对编程的要求一同编程。很明显能感觉到，自己很熟悉在这段时间的编写的代码，即使是对方在掌控键盘编写。在一定程度上，减少了两人阅读对方代码，询问如何使用对方代码时消耗的时间。相较之下，程序有一部分代码并不是两人一起编写的，在使用仅由对方编写的代码时常会产生许多的疑惑，需要在沟通上花费不少的时间。 -
时间规划上存在难度
结对开发的两人并不是一直能够抽出时间一同编程。时间的碎片化也增加了两人一同使用大块时间进行编程的难度。就笔者两人而言，在这两周中基本上只有晚上有可能同时有时间结对编程。而白天常常会是一人有空而另一人有事的情况。因而结对编程时，对于时间上的规划存在一定的难度。但是如果是在类似于公司的环境中进行结对编程，这个问题应当会减轻很多。 -
工程量较大时，进度较难推进
结对编程和分工开发就好比单线程与多线程。当任务的工作量较大，并且各模块的开发任务能分解为并行度较高的子任务的时候，很明显进行分工“多线程”开发的效率会高一些。再基于上一条，在面对工作量较大的任务，结对编程很有可能会在推进开发进度上出现困难。在笔者结对编程的前期，两人编程的效率是比较可观的，很快就完成了基本功能。但随之而来的测试、优化、回归测试、GUI绘制等等任务使得本来时间就不太富裕的结对编程出现的进度推进上的困难。最终笔者两人将部分任务的任务进行了分工开发，缓解结对任务的压力。
对最终成绩的感想
重要的不只有代码
实话说，对于自己最后的得分能够位于前列的事情我是十分惊喜的。我们编写的程序在进行公共测试时的表现并不太理想，公测的最终得分在班级中应该是排在中间偏上的水准。但最终能够脱颖而出，主要靠的是博客部分的得分。在分析最终排名靠前的同学的得分后，我发现大家在测试时的得分其实都差不多，只有少数小组在测试时取得了先当出色的成绩。这说明大家在解决问题时所采用的方法以及最终的取得效果其实都差不多。而最后拉开差距的则是博客部分的完成情况。
在开发的过程中，无论怎么强调代码质量的重要性都是不为过的，毕竟代码质量是一个项目的根本。但除此之外，开发的其他环节也不应当被忽视。比如说，开发中各种文档的编写。在笔者进行结对编程时完成的而总结博客就相当于从宏观角度对整个开发流程的总结和反思。笔者在进行结对编程工作的同时就已经开始了博客的撰写。每过一段时间就会对博客中的一些内容进行更新。在写博客的过程中，笔者能够对编程的过程进行一定的反思，使得编程工作的目标更为明确。除此之外，在真正的开发流程中还有例如API文档等“中间文档”。这些文档在开发过程中起到了润滑剂的作用，让团队中每一个“齿轮”能紧密的咬合，使整个团队能够正常地运作。当然，这些文档的作用往往会体现在最终的代码质量当中。
对于课程的建议
- 结对编程题目的改善
本次结对编程的题目是解决最短单词链问题，分为有单词环和无单词环两种情况。根据课程组给出的作业要求，笔者认为完成本题目的重点应当在与对算法的优化方面。在无单词环的情况，由于英文字母数量的限制，搜索的复杂度并不大，不同搜索算法的差距不易体现。笔者在这一步分尝试采取了深度搜索和动态规划两种方法来解决问题。最终两种方法取得了相近的效果（肉眼不可见的差距）。
在有单词环的情况，该问题相当于NP问题，而最终评测是要求程序给出确定解。于是无法采用启发式算法解决问题，仅能通过优化确定算法来提高性能。而这种方法带来的效益是相当有限的。当然也有个别小组采取了相当有效的优化操作，但绝大部分组的优化效果甚微（包括笔者的小组）。笔者认为该部分若改成“在最短时间内给出最长的单词链”这样的评判标准的话，大家就会在这一部分有更多的操作空间。
除此之外，笔者认为本次结对编程的题目缺少一定的开放性。这主要体现在开发过程中在用户体验等其他方面缺少设计的开放性，大家除了算法的方面几乎没有操作的余地。而最后的程序评测也主要参考程序通过的测试点和性能，少了些程序其他的方面的评价。
写在后面
- 应课程组要求附上笔者“黄衫”照片：
