结对编程总章 - 结束也是新的开始

本文主要是介绍结对编程总章 - 结束也是新的开始，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

结对项目实践反思

问题分析-L同学

结对编程时出现的问题主要集中在第二阶段，其主要特征为两人的交流不够深入。由于第二阶段的任务量较大，会涉及到许多细节，时常出现两人对需求的理解不同的情况。然而平时能够抽出共同的空闲时间结对编程的时间又不多，当一个人的实现思路出现问题时另一个人也不能及时指出，这直接导致最终程序质量不高。这样以来结对编程的优势被弱化，因为两个人相互交流而碰撞出的思路必然比一人独自思考更全面。

需求分析实践体会-L同学

需求分析是结对作业最重要的一环，因为其直接决定程序的架构设计。结对作业的需求主要来源于指导书和Issue。最开始应当通读指导书，不能放过每一个细节，对容易忽略的或发生改变的需求最好另行记录。同时这部分分析以两人面对面进行最佳，因为这时的交流是最高效的。不过这往往无法完全解决需求分析的问题，在此之后每当遇到对需求的理解不清晰的情况时应当再细读指导书或Issue、与伙伴交流等。

在第二阶段的结对作业中，cp指令中需要覆盖文件时，覆盖后最终应当以dstName保存，而我们却以srcName保存，还是因为在需求分析时没有仔细考虑导致出现bug。

架构设计实践体会-L同学

需求分析之后就要进行架构设计。架构设计时两人的交流要最好有实质性的记录，比如生成设计文档或直接在代码里设计接口和注释，然后两个人共同对架构设计进行审核。审核越谨慎，编程实现时走的弯路越少。此外，为了方便两人对代码的理解，代码编写前应当制定合适的代码规范，比如分支对应的注释、属性要设置为private等。

第二阶段要在第一阶段的基础上进行迭代，在修改架构时遇到两个主要问题：文件系统和用户系统之间的交互；软硬链接带来的路径寻址问题。前者我们新建一个交互类并采用单例模式用于两个系统之间的信息交换；后者我们利用递归对路径进行解析并返回对应文件或目录类的引用。不过由于各个指令的要求不同，比如有的要求路径末尾是文件，不能有/，而有的既可以是文件也可以是目录，我们在递归时没有充分考虑不同指令的需求，导致程序没有正确抛出异常。现在想来，我们在架构设计时过于仓促，对实体的抽象程度还不够，也没有充分利用多态等面向对象的特性，使得最终的架构不够清晰，还有待改进。

结对过程实践体会-L同学

结对过程中的交流与工作的进度与质量直接挂钩，第二阶段工作的复杂性让我们充分意识到这一点。我们由于中途沟通的失误，工作的进度较慢，最终也是压线提交，同时质量也存在问题。当压力巨大时，任何一方都不能失去耐心，要保证平稳的心态，冷静分析当前的问题。第二阶段的代码编写过程中我们有一次由于沟通不到位，在一个晚上的结对后没有什么实质性的成果，同时又因为临近DDL，双方搞得都不愉快。不过在回到寝室后我们各自都认真了反思，在简短的沟通后各自集中寻找问题解决，最终加班加点完成了任务。

此外在具体编码之后，代码的复审和测试也是一项必不可少的工作。复审可以检查代码规范、清除无用代码；做好测试不仅有利于对各种分支进行覆盖，还有利于进行回归测试，良好的测试能初步保证代码的质量。不过这也是一项繁重的工作，需要两个人配合着进行。

结对项目建议-L同学

1. 版本管理：版本管理自然使用Git，不过建议两人同时对代码进行编辑时，编辑部分不要相交，这样在提交时更省事。

2. 项目实施：项目实施应当做好时间规划，何时做需求分析，何时做架构设计等（可参考下方表格）。有了明确的时间规划，在结对时就有更清晰的目标，对项目进度也有促进作用。

   阶段	开始时间	结束时间
   需求分析
   架构设计
   具体编码
   代码复审
   代码测试

CI体验感想-Z同学

如上图，我们的结对项目一共进行了92次commit，很难想象倘若缺少CI这样一个自动化持续集成工具，该如何进行频繁的迭代式开发测试。
唯一想吐槽Gitlab-CI的是，既然有完善的Terminal界面，如果能开放输入接口让用户能直接在终端进行部分操作，能简化很多工作。每次修改完脚本后都需要重新提交+漫长的等待时间 属实有点难熬。

结对编程感想

1 结对的总体感受-Z同学

由于我们二人的选修课时段恰好互补，作息时间也很不吻合(究极夜猫子的我背大锅)，所以很难做到像书上那样全过程线下面对面双人结对编程，因此我们采取的方式是，在每次新任务指导书出来的当天下午/晚上，在新北-1楼面

这篇关于结对编程总章 - 结束也是新的开始的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！