结对编程#3

结对项目实践反思

针对前面两个阶段中出现的问题，分析问题的特征、产生的根源和对质量的影响程度；

• 第一阶段的作业较为简单，架构以及所实现的功能都不是非常复杂，在和队友一起浏览指导书并且迅速分配任务后就开始埋头编码了，分头行动的效率还是挺高的，因此产生问题的部分是代码合并期间，有以下几个问题。

  • 可读性。分头行动产生的代码可以说不算是结对编程的成果，除了大致的框架一致外，队友之间的代码风格差异很大，导致在合并选手工作时，由于一定程度的强迫症和对oo代码风格进行传承的执念进行了大规模的重构，除了基本的命名、空格符合规范外，对一些方法也进行了修改，（或许）降低了耦合度，代码风格不同导致的代码可读性较差问题只需要找到合适的标准进行规范即可，问题产生的根源还是队友之间对代码风格没有提前的商量，这也表明这个问题很容易被忽视，当修改完毕后代码的可读性明显增强，质量也有所提高。

  • 需求分析工作不足，bug太多导致测试时间较长。在进行代码合并时由于进行了重构，导致原先处理的细节以及实现的功能被ljj同学懵懵懂懂地忽略了，在合并之后接踵而至的便是bug的修复，而bug实在是太多了，例如需要补充对.、..、/、file/云云特殊情况的处理，在lxy同学精准的测试下逐个击破。产生这么多细节上的问题，产生的根源是对指导书的理解不够清晰，在结对编程的过程中，我们解决问题的方式是等待问题的出现，再经过讨论去达成一致，这样的方式造成我们在遇到极其简单的问题时也花费了一部分精力来讨论，而这是没有必要且降低效率的。

• 第二阶段的作业架构突然复杂了起来，不仅要修改第一阶段遗留的原子性问题，还增加了令人摸不着头脑的链接文件，我们在任务分配完毕后，花了很多时间在指导书的分析上，在issue区还未成长的时候，ljj同学一度处于

  标签：编码,结对,ljj,代码,编程,bug
  来源： https://www.cnblogs.com/nya0/p/14638418.html