WordCount结对编程

合作者:201631062602,201631062114

代码地址:https://gitee.com/Changyu-Guo/pairing_project

作业链接:https://www.cnblogs.com/yuliu10/p/9806600.html

一、PSP表格

PSP2.1

PSP阶段

预估耗时

(分钟)

实际耗时

(分钟)

·Planning

计划

20

30

Estimate

估计这个任务需要多少时间

20

30

Development

开发

670

1155

Analysis

需求分析 (包括学习新技术)

120

100

Design Spec

生成设计文档

0

0

Design Review

设计复审 (和同事审核设计文档)

0

0

Coding Standard

代码规范 (为目前的开发制定合适的规范)

20

30

Design

具体设计

50

115

Coding

具体编码

300

660

Code Review

代码复审

60

100

Test

测试(自我测试,修改代码,提交修改)

120

150

Reporting

报告

120

200

Test Report

测试报告

60

90

Size Measurement

计算工作量

30

50

Postmortem & Process Improvement Plan

事后总结, 并提出过程改进计划

30

60

合计

810

1385

二、编码规范

由于第一次作业比较简单,用的C语言完成的,在结对编程的时候,经过双方的商讨之后,我们的项目主要是使用C/C++结合node.js进行开发,因此我们从网络上查找了相关的编码规范:

三、代码自审和互审

制定了相关的代码规范后,就按照代码规范对自己的代码进行审查,由于自己很早之前就对代码规范进行过了解,因此在审查过程中并没有发现太多的问题。

进行过代码自审过后,接下来就是代码互审,由于第一作业的代码比较简单,经双方商议后我们决定对命令处理模块、字符统计模块、单词统计模块、行数统计模块进行代码互审,过程中出现的问题如下:

  • 我的代码问题:主要就是代码的耦合性太高,各个功能模块代码相互关联,并且出现多个逻辑功能出现在同一函数里面的情况,不利于接下来的结对合作,需要对相应的模块进行抽离。
  • partner代码问题:代码同样出现了耦合性过高的问题,其实就是变量及函数的命名有的不符合驼峰命名法,其他的都比较好(毕竟编译器自带代码格式化)。

四、设计过程

经过双方的商讨和对原始代码的分析过后,并考虑到要使用图形界面,决定用node.js搭建一个后端服务器,如果命令里面存在-x选项,则启动服务器,并打开相应的页面,由用户发送ajax数据,后端接受后拼接成相应的字符串后,调用wc.exe并传入命令字符串即可得到结果,如果没有,则不用打开服务器和网页,直接调用wc.exe得到相应结果即可。代码的具体流程如下:

WordCount结对编程

wc模块的流程为:

WordCount结对编程

五、关键代码分析

参见partner的博客:https://www.cnblogs.com/guochangyu/p/9804719.html

五、总结

将《构建之法》的第四章“两人合作”领悟一番之后,原本以为俩人结对编程的效率会有很大的提高,但在实践的过程中发现事情并没有那么简单。在驾驶员和领航员的之间不断轮换角色,并且都要主动参与,双方都在分析、设计还有编码上都有平等的决策权力,这是我和partner做得比较好的一方面。但是在一开始的时候,因为两人的水平的差异(我太弱了),使得开发效率太低了,这样看来结对编程的效率并不比单独开发的效率高,但是随着时间的推进,以及队友的影响力和有效的反馈,慢慢发现结对编程其实是一个相互学习、相互磨合的渐进过程。

这次项目的完成,不仅让我了解到了结对编程的使用场景、合作技巧以及如何正确的给予对方反馈,更让我看到了身边同学的优秀,明白了自己还有许多要提高的地方!

上一篇:同步、更新、下载Android Source & SDK from 国内镜像站(转载)


下一篇:[Android] repo 下载Android源码(国内镜像)