[2019BUAA软件工程]结对编程感想

结对编程感想

写在前面

  本博客为笔者在完成软件工程结对编程任务后对于编程过程、最终得分的一些感想与经验分享。此外笔者还对于本课程的结对编程部分提出了一些建议。

Tips	Link
做业要求博客	2019年软件工程基础-结对项目做业
笔者的总结博客	[2019BUAA软件工程]结对做业

---

对结对编程过程的感想

  通过长达两周的结对编程，结合《构建之法》中对结对编程的描述以及这两周的亲身经历，笔者对于结对编程的过程有了如下的感想。

• 两人合做，更易解决问题
    在编程的过程当中，笔者两人一同遇到了许多的困难：从编程语言的使用，到算法的设计，再到代码的实现。相较于单人编程，两人同时对问题进行思考，经过讨论发现两人解决问题的漏洞，互补双方解决问题的方法，有效地解决问题。好比，在笔者同伙伴一块儿编写单词链搜索函数时对于每一个代码分支，递归调用都进行了相似一人推演一人审核的模式，有效地突破了程序中的难点。

• 相互学习，共同进步
    在进行结对编程时，每人都有一段时间负责在对方编程的过程当中在旁边进行审核。在“旁审”队友编程的过程当中，笔者从队友的编程方式吸收了许多有用的部分，好比算法实现的思路，代码编写习惯等。将这些优势融入到本身的编程中，优化了本身的编程方式。

• 同时编程，下降沟通难度
    结对编程要求两人同时在一块儿进行开发。笔者与队友在大多数时间里是按照结对编程的要求一同编程。很明显能感受到，本身很熟悉在这段时间的编写的代码，即便是对方在掌控键盘编写。在必定程度上，减小了两人阅读对方代码，询问如何使用对方代码时消耗的时间。相较之下，程序有一部分代码并非两人一块儿编写的，在使用仅由对方编写的代码时常会产生许多的疑惑，须要在沟通上花费很多的时间。

• 时间规划上存在难度
    结对开发的两人并非一直可以抽出时间一同编程。时间的碎片化也增长了两人一同使用大块时间进行编程的难度。就笔者两人而言，在这两周中基本上只有晚上有可能同时有时间结对编程。而白天经常会是一人有空而另外一人有事的状况。于是结对编程时，对于时间上的规划存在必定的难度。可是若是是在相似于公司的环境中进行结对编程，这个问题应当会减轻不少。

• 工程量较大时，进度较难推动
    结对编程和分工开发就比如单线程与多线程。当任务的工做量较大，而且各模块的开发任务能分解为并行度较高的子任务的时候，很明显进行分工“多线程”开发的效率会高一些。再基于上一条，在面对工做量较大的任务，结对编程颇有可能会在推动开发进度上出现困难。在笔者结对编程的前期，两人编程的效率是比较可观的，很快就完成了基本功能。但随之而来的测试、优化、回归测试、GUI绘制等等任务使得原本时间就不太富裕的结对编程出现的进度推动上的困难。最终笔者两人将部分任务的任务进行了分工开发，缓解结对任务的压力。

---

对最终成绩的感想

重要的不仅有代码

  实话说，对于本身最后的得分可以位于前列的事情我是十分惊喜的。咱们编写的程序在进行公共测试时的表现并不太理想，公测的最终得分在班级中应该是排在中间偏上的水准。但最终可以脱颖而出，主要靠的是博客部分的得分。在分析最终排名靠前的同窗的得分后，我发现你们在测试时的得分其实都差很少，只有少数小组在测试时取得了先当出色的成绩。这说明你们在解决问题时所采用的方法以及最终的取得效果其实都差很少。而最后拉开差距的则是博客部分的完成状况。
  在开发的过程当中，不管怎么强调代码质量的重要性都是不为过的，毕竟代码质量是一个项目的根本。但除此以外，开发的其余环节也不该当被忽视。好比说，开发中各类文档的编写。在笔者进行结对编程时完成的而总结博客就至关于从宏观角度对整个开发流程的总结和反思。笔者在进行结对编程工做的同时就已经开始了博客的撰写。每过一段时间就会对博客中的一些内容进行更新。在写博客的过程当中，笔者可以对编程的过程进行必定的反思，使得编程工做的目标更为明确。除此以外，在真正的开发流程中还有例如API文档等“中间文档”。这些文档在开发过程当中起到了润滑剂的做用，让团队中每个“齿轮”能紧密的咬合，使整个团队可以正常地运做。固然，这些文档的做用每每会体如今最终的代码质量当中。

---

对于课程的建议

• 结对编程题目的改善
    本次结对编程的题目是解决最短单词链问题，分为有单词环和无单词环两种状况。根据课程组给出的做业要求，笔者认为完成本题目的重点应当在与对算法的优化方面。在无单词环的状况，因为英文字母数量的限制，搜索的复杂度并不大，不一样搜索算法的差距不易体现。笔者在这一步分尝试采起了深度搜索和动态规划两种方法来解决问题。最终两种方法取得了相近的效果（肉眼不可见的差距）。
    在有单词环的状况，该问题至关于NP问题，而最终评测是要求程序给出肯定解。因而没法采用启发式算法解决问题，仅能经过优化肯定算法来提升性能。而这种方法带来的效益是至关有限的。固然也有个别小组采起了至关有效的优化操做，但绝大部分组的优化效果甚微（包括笔者的小组）。笔者认为该部分若改为“在最短期内给出最长的单词链”这样的评判标准的话，你们就会在这一部分有更多的操做空间。
    除此以外，笔者认为本次结对编程的题目缺乏必定的开放性。这主要体如今开发过程当中在用户体验等其余方面缺乏设计的开放性，你们除了算法的方面几乎没有操做的余地。而最后的程序评测也主要参考程序经过的测试点和性能，少了些程序其余的方面的评价。

---

写在后面

• 应课程组要求附上笔者“黄衫”照片：