结对编程收获——旧的不去&新的不来

结对作业收获

首先是本次结对实验的内容概述,因为这篇博客主要是谈收获,所以关于内容的介绍我打算直接放出我们之前写好的博客链接,如下(本次作业的相关介绍与作业报告都在这里):

 

Core 第三组 结对作业——四则运算 Part1. Core代码编写

 

下面我就来谈谈这次结对编程的感受吧。

本次作业与上一次个人作业相比来看,单从难度上来说,其实并没有提高特别多。拿到题目以后,我大概和队友讨论了一下,就有了初步的构架思路。但是这次作业很关键的一部分在于,结对这个新特性上。

领航员&驾驶员

所谓结对,是要求两个人分饰领航员与驾驶员两角,其中一个负责代码的编写,另一位负责指引方向,找出错误,查阅资料的工作。说实话,我觉得这两个角色名都起得非常贴切,因为我对其有很深的感触。小时候,我经常要和我爸\我妈两个人一起开车去上兴趣班,一般就是我爸\我妈负责开车,而我往往会选择坐在副驾驶座上。我对于副驾驶位有特殊的偏爱,除了因为副驾驶座的位置更加宽敞以外,更重要的原因是我能够和开车的家人享有共同的视野,聊起天来也会更没有距离感。这样的经历多了,我似乎就无师自通了领航员这一个角色:虽然领航员不会真正拿住方向盘掌握实际的方向,但是第二双眼睛和第二个头脑,在驾驶过程中的安全保障,道路选择,以及减少驾驶员犯错误的概率这些事情上总是有着很大的加成。驾驶员由于一直握着方向盘,所以必须十分的专注,这不仅对其体能和精力是一个大考验,同时也带来一个问题:他很难分神去做别的事情,否则就可能出大问题。一个领航员,他可以帮助看路牌,看导航,指导驾驶员在哪里变道,以避免拥塞和错过出口,同时,领航员还可以通过与驾驶员聊天交流,起到缓解驾驶员巨大的压力,帮助其度过精神上的疲惫期。我爸有一句话经常挂在嘴边,大意就是一个人开车比两个人一起要危险多了,根据我的观察,确实如此。

而当我面对这个项目的时候,我对这两个角色的设置感到非常好奇,面对一个项目,所谓领航员的加成是怎么体现出来的呢?这当然只有体验过了才知道,于是,我和我的队友艾中,很早就开始了编程的行动。由于我清明节要回家,所以我一开始就和艾中说好,清明节前,我们就需要做一大部分的工作。所以,大概在布置下来作业后的两天左右,我就开始了编程的准备。

虽然已经做过一个项目了,但是,我自觉我的编程能力,仍然还没有得到太大的提升(毕竟欠的东西可以说是太多了)。但是,这个题目我自己比较有思路,而我的队友的思路并不太多(因为我以前做过类似的工作),所以一商量,我们就决定使用我的思路了。其实回过头来看,我觉得这并不是什么好事,由于只有我一个人有思路,所以到后来我发现其实我的思路导出的代码结构,只是一个相对通用,但可调整性与改动性却不好的结构,这也导致了我们后来多了很多工作量,代码也比其他组可能多了不少(增加无谓工作量)。而由于我自己,也并不是那种大牛,可以一下子选到好的架构和思路,一开始对项目的各种奇葩需求也没有认知清楚,我想这是我们在这次项目中,所遇到的第一个,也是在最高层面上的问题:我们两个在思路的布置上,讨论的时间不够多。这也造成了一个事实:可能我们的代码实现一开始比较快,但是后续的补足和叠加工作不好做,由于思路过于单一,再加上选取的思路不是那么的简洁,所以造成了一个人写的代码,另一个人需要花较长时间来理解的问题。某种程度上,可以这么说说,我们两个人的耦合程度不足,做不到如指臂使,更多的是分模块进行设计。哪怕我们两人在一起编程,但是只是有一种把项目分拆的感觉。我想,从这个角度来看,我们这一次的结对编程项目,从一开始就出了一定的问题。

设计思路

稍微谈一下我们的设计思路吧,由于我以前写过一部分后缀式表达和计算的代码,所以这个题目一出来我就想到了利用后缀式来生成式子并计算。由于第一个项目中对树的运用和生成不够熟练,我在这个项目中就想选用一种非递归的方式来写,以期提高代码效率与设计思路的合理性,以及debug时候的效率。再加上我当时对后缀式的理解就是表达式树的后序遍历,因此我对树的结构并不看好。其实,单单看选用这种方式生成式子,并没有问题,问题出在我接下来的设计思路:因为对题目的误解和自己莫名其妙的执念,我强迫自己把cal模块和gen模块分开了,也就是必须要先generate好整个式子再计算(因为我想突出后缀式计算的快速性,一个栈就能搞定),这样的思路显然是有问题的,因为到后来,这种强制的去耦合方式让我发现自己的函数模块在应对诸如整数除法和生成乘方的功能上很困难,最令人讨厌的是,要么做出大的结构改动以提升整个模块的功能扩展性,要么就只能牺牲一小部分功能,再加上一些特殊的,很不美观,很容易破坏原有的流畅结构的代码来实现那些功能。我们选择了后一种方式,而这种强行加入令人头大的代码的方式,也大大的降低了我们完成项目的效率。到后期,我已经很难找到项目刚开始的那个晚上我写代码的感觉和速度了,哪怕有领航员在,这个问题也难以解决。至于在中间冒出的接口安全性问题,以及其他的一些细节问题,相比起这个来说,给我的更多的是收获而不是阻碍,但这个大问题,成了目前我对项目的一个心病:如何选择一个好的结构来实现整个项目?首先我对项目的整体性理解不够到位,对其所需要的灵活性和健壮性理解都不足,只停留在自己的想法上,这样的设计,随着项目的规模扩大,一定会吃到很大的苦头。后来在群里,我向大佬隆晋威请教,他给我建议,叫我去看Java的设计模式,还有多重构代码,我感到确实很有必要,但是时间并不是那么多,我必须得自己想办法抽出时间,去学习这方面的知识。心里面其实也有些懊恼这门课开的时间恐怕有点晚了,要是在大一的时候来,或许会对我后两年有一个更好地指导,不过现在开始去积累,肯定也来得及。这里也希望看到这里的老师和高手们可以给我一些建议,如何能够提升自己的架构能力?

过程中的喜与忧

好吧,还是回到结对的项目上来。然而,由于两个人以前就认识,而且都是辩论队的队友,也一起打过比赛,一起经历过成功与失败(仔细一想好像大都还真是失败),所以配合也都比较默契了。由于一开始我的思路比较流畅,所以一开始的生成和计算模块都主要由我来做驾驶员。不得不说的是,自己真正做驾驶员的时候,跟以前自己为爸爸或者妈妈做领航员的时候感觉完全不一样了。当你一个人面对这样一个项目的时候,你的效率一定会存在一个巨大的波动,你对这个项目的控制程度,一定会随着代码量的增加而慢慢减少,我觉得这应该是一个真理,就算是大佬,也应该是在代码量不算很大的时候,他都有能力handle这样,但是这种控制程度,操作效率都必然是降低的。所以每当自己陷入思路的瓶颈的时候,就会希望有一个人能够一下子帮自己解决难关,或者至少能够分担一下这些压力和负面的情绪。令人开心的是,艾中做领航员做的很好,基本上每次我这边出线了错误,他都能很快指出来,能够给我提供一些基本正确的思路。这也在某种程度上加快了我们编程的效率。可以说,在清明前一天,我们就已经完成了比较基本的功能。

不过事情总是不那么令人开心的,由于我们两个在清明节都有事,所以基本上都没有做什么工作,这里又让我学到一个道理,一个项目最好一定要做到每天维护,不然的话,就好像我的一个游泳特长生同学和我说的道理:一天不下水,可以废了十天的训练。等到清明回来,我们两个重新拾起项目的时候,我们的效率明显的下降了。不过归功于结对的良好配合,我们两个人的效率并没有下降太多,配合的默契很大程度上保证了我们编程速度的下限。同时,由于沟通比较顺畅,我们两个人分别负责的函数模块的对接也完成的很轻松。

大概在周五的晚上,我们就已经把基本功能完成,也把dll封装好了,于是我们就开始找人对接。这里面仍然不得不提的是,由于没有经验,我们一开始没有选用dll项目+dll测试工程的方式来编写代码,而是采用了普通的控制台项目来编写代码,后果就是光是想办法把工程一直到dll平台上就花费了我一个晚上的时间,着实令人捶胸顿足。 这也给我一个教训,就是面对新东西时,赶快用起来比一直拖着不弄弄别的重要太多了。。。。。

很快我们就找到了可以对接的UI组的同学,很高兴的是,这组的同学也是辩论队的学弟,又是当面对接,所以配合也很愉快。虽然由于他们的qt一开始不太支持隐式调用,所以对接花费了一些时间,但是总体上来说,对接比较顺利,而且在这个过程中,我们把接口的安全性全部优化了一遍,至此,我们的项目可以说基本完成了,接下来要做的就是根据UI组的反馈来找bug,把我们的功能完善了。

由于前面的编程过程中,我和队友已经花费了很大功夫检测各种各样的bug,因此,虽然接下来几天的测试中,UI组给我们反馈过不少bug,但是这都是建立在对接非常迅速和安全的基础上的,而且由于我和艾中的配合很默契,所以我们基本上每一次改bug的速度都非常快,跟我们对接了的7、8个UI组基本上给予了我们一致的好评,这里面,更是有3~4个UI组,最后用我们的core来进行了最后的封装,作为最后的程序(之一)提交到了网上,这也是令我们组很自豪的地方,可以说努力总算没有白费。

总结——项目做完,问题仍在

但是,这次的项目,让我自己看到了进一步努力的空间。为什么同样是一个项目,我的代码量,要比别人大很多?为什么到后期,我对项目的控制能力越来越差了?为什么,我选择的代码结构会有可修改性差的问题?这些问题,似乎都是我前进路上重大的绊脚石,如果我只是做完了这个项目,却没有想办法去解决这些问题,那么我的提高,肯定是不够的。目前,我没有太好的思路,该如何去解决这些问题,只能多读书,多学习,多向老师去请教。现在我把他写出来,也是希望各位老师可以看到这些问题,我想,在高手的指导下,我的努力会更有方向。我希望通过这次作业我可以学到更多,这也是在这短短的一学期的课程中,我觉得我能做的最重要的事了。之所以把题目取成旧的不去,新的不来,也是希望在之后的学习里,我可以用新的知识,更棒的想法去覆盖掉我之前那些不足的知识。

那么,这次的总结就到这里吧,没有图片,没有代码,有的只是一颗想要一直进步的心。

2018.4.20

 

posted @ 2018-04-20 17:25  Zucks  阅读(158)  评论(3编辑  收藏  举报