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进行开发，因此我们从网络上查找了相关的编码规范：

•   C/C++：C/C++编码规范
•   Node.js：JavaScript 风格指南/编码规范（Airbnb公司版）

三、代码自审和互审

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

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

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

四、设计过程

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

wc模块的流程为：

五、关键代码分析

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

五、总结

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

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