结对编程_结对编程的利与弊 - CSDN
精华内容
参与话题
  • 结对编程

    千次阅读 2013-03-21 22:22:13
    结对编程技术是指两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法、同一段代码或同一组测试,能编写出质量更高的代码。   简介 结对编程技术是一个非常简单和直观的概念,能达到事半功倍的...
    结对编程技术是指两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法、同一段代码或同一组测试,能编写出质量更高的代码。
     
    简介
    结对编程技术是一个非常简单和直观的概念,能达到事半功倍的工作效果。但是,人与人之间的合作不是一件简单的事情——尤其当人们都早已习惯了独自工作的时候、实施结对编程技术将给软件项目的开发工作带来好处.只是这些好处必须经过缜密的思考和计划才能真正体现出来。而另一方面,两个有经验的人可能会发现配对编程里没有什么技能的转移,但是让他们在不同的抽象层次解决同一个问题会让他们更快地找到解决方案,而且错误更少。
    两个程序员具有相同的缺点和盲点的可能性很小,所以我们当我们采用结对编程的时候会获得一个强大的解决方案。而这个解决方案恰恰是其它软件工程方法学中所没有的。
    在我们平时的编程当中,如果遇到一个非常难解决的问题(困难到对该项目产生厌烦的态度),那么你势必会希望录求帮助,无论是从信息量庞大的Internet网络里,还是从身边的技术大师里,你都会拼了老命去解决(前提是你有对计算机知识的势爱)。这个时候不妨采用结对编程试一下,其它的不说,可能感觉就不同。
     
    优势
    其实结对编程坐起来很简单也很有趣,找个水平差的不太远的程序员和自己配成一对。只用一台计算机,大家选一个人坐在键盘前面负责输入,另一个人坐在后面口述。两个人要不断的交流,频率不应低于一分钟一次。整个的设计思想由后面只动口不动手的人主导,而由操键盘的人做实现。由于人的思维速度是快于输入代码的速度的。那么观看的人可以有空闲的时间做额外的思考,观察代码写的有没有问题,结构有没有问题。
    如果程序员的经验积累足够,是很容易看出存在潜在问题的代码的,即表面上实现了功能,但实际上是一种糟糕的做法。这在XP中被称为代码坏味道,在 Martin Fowler的《重构》一书中有详细的介绍。两个有经验的程序员同时在一起工作,看起来好像浪费了一个人的时间:但实际上的效果确实完成了更高质量的代码。程序编的不那么容易出BUG,而且代码页写得更为优雅和紧凑.
    关于结对编程,发现了一些新的受益之处。首先,它可以促进参与项目的程序员自身的提高,一对程序员工作的时候,水平较低的一方会潜移默化地受水平略高的程序员影响,学到一些新的东西。而水平高的一方同样因为不断地把自己的想法说出来而整理了自己的思路。
    其次,一定时间周期地打乱配对,让参与项目的人员相互转换位置,使得维护繁杂的文档变得不那么重要。大家分组打乱后,口头的交流很容易让所有人都熟悉每个模块,这样对于公司也很有好处,项目中万一有人离开,也不至于影响到整个项目。最后,开发过程变得更为有趣,任何人的交流变得很多,大家关系更为融洽。
    另外想补充一点的是,讲解XP的书籍上都没有提到,但是实际上却存在的一点:结对编程使得程序员被迫提高了工作效率。如果单独工作,在遇到困难的时候,并不是所有人都立刻积极地去解决问题,这时或许会上网和网友聊聊天,看看无关的网站等等。有可能因为工作的打断,大半天的时间都浪费了。看起来,程序员每天都在加班,实际有效工作时间往往还打不到6个小时。而结对编程有一种相互督促的作用,在一边工作疲惫状态不好使,另一边会起一个鼓励和激发斗志的作用。
    而且两个人共用一台电脑,略带私人性质的聊天活动都会很自觉地不去进行了。结果一天下来,新实验结对编程的程序员都会喊累,神经紧绷8个小时的工作不累才怪。
    从这个角度看,严格限制结对编程的程序员不准加班是合理的,实际上,开始每天甚至不必限制8小时工作,每天这样工作6小时队项目同样是非常高效的。
    当两个人不断的互换角色,以至于最后谁也记不清哪行代码是谁敲的;团队内循环的分组以至于分不清到底那个模块该谁负责;反而大家的感觉会不错。整个项目的代码是团队共有,而不再是个人作品了。
     
    但结对的推广与实现,会遇到极大程度客观条件的挑战,一些可能遇到的问题:
    1)结对的效率,结对之后我们发现,2个人一起工作能够完成的工作可能等于分开做的70%~80%左右,

    2)结对过程中,大家都很不愿意更换结对对象,至于结对对象的更换,最好是每个任务结束之后更换结对的对象。

    3)并不是所有功能编写都适合使用结对编程,正如第一条所说,带来一定的效率问题,老板可能不乐意了。
    展开全文
  • 结对编程——完工感言

    千次阅读 2019-04-11 15:38:36
    首先,来讲一讲从个人项目到结对编程的过度,我们两个人一个使用C++写的个人项目,另一个人用的是java,我们知道,就目前阶段来看,用java实现ui远比C++要简单的多,所以值得庆幸的是我们队伍中有一个...

    引言

      回顾以前的程序开发,我们基本都是单独一个人分析需求,设计算法,编写程序到debug,通过这一次新的开发模式,两个人一起完成一个项目,虽然时间不长,但还是感觉受益良多。

    首先,来讲一讲从个人项目到结对编程的过度,我们两个人一个使用C++写的个人项目,另一个人用的是java,我们知道,就目前阶段来看,用java实现ui远比C++要简单的多,所以值得庆幸的是我们队伍中有一个人使用了java,所以从语言上来说基本没什么问题了。并且在实现个人项目的时候,就已经考虑到了用户界面,所以在结对编程实现的时候就是相对简单了许多。所以主要问题就集结在了对算式逻辑的优化和短信验证等其他模块了。


    个人项目的继承与复用

    既然结对项目是对个人项目的延申,我们先来看看有哪些是可以从个人项目中复用的。

    从需求上来看,结对编程项目和个人项目的需求大致相似,对于大部分代码我们能够很好的进行重复利用,并且因为我们已经再个人项目中超额完成了UI界面的实现,所以我们的目标就变成了对个人项目的进一步优化。

    我们的贡献与优化主要体现在以下几方面:

    1. 程序的模块重构和代码的解耦
      个人项目由于时间仓促,虽然也分了模块进行编写,但是模块之间的独立性没有很好的体现,为了做出低耦合的代码,我们决定对代码进行了重构,模块被我们分为以下几个部分;
      从大角度来讲,我们的总体模块分割可以用下图表示:
       在这里插入图片描述

    这样分化模块的好处是我们可以单独实现单个模块,而不用依此考虑,使得代码变的更加规整,并且我们在调试时只需要调试单独的一个模块,效率更高,程序的鲁棒性更加强大。

    1. UI界面的完善
      对于UI界面,内部我们也细分了单独的模块,分割大致如下:
      在这里插入图片描述
      Java实现UI的难度在于界面监听机制和组建布局都需要我们自己手写实现,我们没有依赖于QT,虽然难度和工程量很大,但是加深了我们对UI等响应机制的理解。

    2. 算术生成的创新与改进
      这也是程序的核心模块之一,关于算式生成,起初的思路是先生成小学题目,而后初中题目是在小学题目上添加根号等实现,然后高中题目同理又是基于初中题目生成。这样做的想法可能比较简单与普遍,但是这样做也带来了许多问题,比如括号意义性问题,式子是否有意义性问题,这些问题在生成题目时很难被考虑解决,并且这个最大的问题是当我们要去计算一个表达式的值时,我们要先将所有的单操作运算都计算出来后,根据后缀表达式计算四则运算的值,将算式生成与答案计算分离,委实麻烦。
      基于这些考虑,我们两个转换了一下思路,观察式子计算,我们构想这样的方法,式子是由一些列的操作符和操作数构成的,而不管初中高中还是小学,都是四则运算的演变,我们可以将每个操作数看作一个对象,这样三者的区别就在于对象的不同,二元操作符可以将两个对象合并为一个对象,于是式子的生成就可以看做对象的不断合并,那我们可以边生成式子边计算答案,基于这种想法,我们实现了这样的代码,并且惊喜的是,这样做带来了意外的好处,我们的括号意义性考虑极为简单(因为同一个对象不会连套两个括号),另外,由于我们将操作数进行了抽象,所以我们的代码实现基本只需要小学实现即可,初中和高中都是只要重写操作数生成方法即可,代码实现极为方便。
      附图:一个题目生成的完整流程(奇数行式子,偶数行答案)
      在这里插入图片描述

    3. 短信验证
      这里的也是极为波折,主要是包的导入教程不详细走了许多弯路,但都已克服。

    4. 账号注册登陆
      既然有注册功能,自然也有账号登陆过程,在登陆过程中我们的优化主要如下:
      1.对于账号不存在的,我们提示账号不存在。
      在这里插入图片描述
      2.对于账号存在而密码错误,我们提示密码错误。
      在这里插入图片描述
      3.在进行注册时,我们会检查账号是否存在,如果存在则无法注册。
      在这里插入图片描述


    结对分析

    • 结对编程的利与弊
      结对编程的好处就是可以结合两个人的思想,比如在设计算法的时候,有很多情况都是结合了两个人的思想。还有就是在编程的时候,一个人编程另一个人在旁边能够及时的发现错误,大大提高了编程的效率。两个人一起编程可以提高积极性,一个人有时候在面对很多诱惑的时候就会怠慢很多。坏处就是沟通磨合需要一定的时间,不过我们是室友,所以在沟通调节,统一思想方面就很顺利。

    • 经验和教训

    1. 合理分配任务

      不能所有的任务都抛给一个人,只有合作愉快了才能有后续的继续合作

    2. 要互相尊重
      不要在对方提出观点的时候立马就否认掉,要先分析,既然提出来肯定有亮点的地方,如果不好,哪里不好,如何改进。合作的时候能够得到同伴的肯定,能够提高积极性和自信。

    3. 需求分析很重要
      需求分析是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误,从而提高软件生产率,降低开发成本,改进软件质量。


    总结

    一个人走的更快,一群人走的更远,个人编程和结对编程就像如此,个人的项目虽然完成很快,但是两个人做的项目更加精美,到这里为止这次结对编程画上圆满的句号。
    最后,代码托管github:https://github.com/Royean/CalculationGen-Pro

    展开全文
  • 结对编程就是指两位程序员使用同一台电脑,进行编程。   我认为这是一个很好形式,这样找两个实力水平差不多的人在一起工作,稍差的人可以向优秀的人学习得以成长;而优秀的人会在不断的表达中,形成自己的编程...

    结对编程就是指两位程序员使用同一台电脑,进行编程。

     

    我认为这是一个很好形式,这样找两个实力水平差不多的人在一起工作,稍差的人可以向优秀的人学习得以成长;而优秀的人会在不断的表达中,形成自己的编程风格和思想;这样都会得到成长,并且使得代码质量得到大大的提高。

     

    结对编程,并且使得我们工作效率会大大提高,这样使得我们在工作时,不会花大量的时间来处理私人问题,使得加班也会变少,其实自认为是一种利于公司,也利于程序员本身的编程方式。还有一点,不断的更换公司的结对时,使得员工对公司的业务都很清楚,这样即使某个员工离开本项目组,对项目的影响度会大大降低。这其中,对程序员本身的素质需求非常高,每个人都需要虚心的接受别人的意见;当出现分歧时,需要恰当的时机,恰当的人去处理。

     

    国内有这个大的成本么?做项目的人,只知道尽快交互项目,谁会真正的关心代码的质量呢?主要是客户不对代码质量关心,他们关心的是业务逻辑是否实现。

     

    也许做产品的公司,会非常注意这一点。希望今后自己能有机会进入这样的公司,享受到这种编码的乐趣。

    展开全文
  • 请停止结对编程

    千次阅读 2018-08-26 14:20:02
    这是一个风和日丽的星期天下午,Ben 和 Martin 本应该在 Costa 咖啡馆喝一杯下午茶,一起聊聊周末的计划,然而 PM 的一个微信通知打乱了这一切。原来产品出现了一个bug需要紧急修复,下班之前必须要搞定。...

    这是一个风和日丽的星期天下午,Ben 和 Martin 本应该在 Costa 咖啡馆喝一杯下午茶,一起聊聊周末的计划,然而 PM 的一个微信通知打乱了这一切。原来产品出现了一个bug需要紧急修复,下班之前必须要搞定。两人收到消息疾步走回到岗位,也没了心情去喝刚泡好的咖啡,连忙打开邮箱查看问题报告。

    开始

    Ben:看来这不是一个很大的问题,就是处理一个来自于远端服务的异常。现在的情况是BFF(backend for frontends)在内部的远端服务有异常,会将异常直接返回到客户端,这样只要一个保单出了问题,前端所有的保单也都没法用了。

    Martin:那怎么解决?

    Ben:感觉可以在异常的地方加一个异常处理。这个涉及到RxJava和Java8的stream特性,我不是太熟悉,要不我们一起Pair吧

    Martin:好。

    两人喝了一口炙热的咖啡,摆好键盘鼠标,打开了IntelliJ工程。几分钟后,这个故障重现了。

    Martin:可以重现的故障通常比较好解决。我们在这里先弄个try…catch试试。 两人似乎很有信心,然而重启项目后,故障并没有按照预期停下来。

    Ben:hmm,这里为什么停不下来呢?

    Martin:可能是RxJava的延迟处理,没有正确的捕捉到。这样,你在这里再写一个逻辑,然后在这里设个断点……

    焦急

    在这个过程中,Martin只是对着屏幕指指点点,时不时看看手机、在微信上聊聊天。Ben对RxJava并不是很熟悉,他想紧紧跟随Martin的思路,然而增加多个逻辑以后,依然都不能解决问题。15分钟已经过去,Ben这时候心生怀疑,是不是哪些地方没弄对?

    Ben:我们理一下思路看看?

    Martin:恩,来吧,一起看一下代码。

    Martin领着Ben一起看了一下代码,并且一直在旁边指点Ben进行单步调试。由于RxJava的延迟特性,使得断点很难设置。而抛出异常的调用栈会出现在某些莫名其妙的地方,这让他们根本不知道把try…catch放在哪里才能奏效。

    Ben:可能是要这样,在这里加一个OnError看能不能解决。

    看似问题能够解决,其实是又一次的失败。在两人的激烈讨论中,时间过得很快,一晃眼已经是1个小时以后,咖啡早已经凉了,然而两个人完全没有心情,甚至都忘了咖啡的存在。

    Ben对Martin的解决方案越来越没有信心,两人开始重新讨论起解决方案。然而方案是越讨论越复杂,看起来想在下班前解决这个问题是不可能了,通宵是必然了。

    简化

    Zen是组里的Tech Lead,今天在忙另外一个事情。这个周五真是不得安宁,恨不得想到美国去过过昨天。

    Zen听到两个人的讨论,虽然并不了解这个问题的细节,但直觉上认为是跑偏了。马上提醒Ben和Martin:

    这不是一个很难的问题,我感觉你们想复杂了?是不是走偏了?能给我说一下你们怎么想的么?

    被Zen打断的Martin说了一下之前的解决方案,也说试过了其他的方案了,都不行。由于Zen对这个事情也不是很了解,所以只是提了一个醒:

    “Keep it simple,别把事情整复杂了。”

    两个人的讨论依然在继续,Ben有点无法跟上Martin的思路,艰难地写着代码,但每次都不对。Pair的气氛犹如冬日里冰冷的咖啡一样凝结,不知道孰是孰非。Ben已经有些不高兴,Martin则依然在一旁指指点点但并不动手。

    Zen一看表已经3点钟了,又插了一句嘴:

    Martin,既然你对这个更熟悉,你来操刀吧。你来写代码吧。

    可能由于之前的讨论过于激烈,Martin反驳Zen:

    我们在Pair啊,他对RxJava不熟悉,我应该指导他。我看着他写就可以了。

    Zen说,

    你们的解决方案是什么,给我看看。

    解释了一通以后,Zen也没有更多的想法,就让他们继续吧。但Zen建议道:

    在这个紧要的关头,我们应该改变一下Pair的方式。现在不是教授知识,而是要高效的解决问题。在这种压力的情境下,你可以直接实现自己的思路,带着别人飞就好了。

    分歧

    Martin稍微冷静了下,拿过键盘,继续开始修复问题。Ben这时候在一旁观察,也适当的休息一下,之前手忙脚乱的按F8、F9的神经也得以缓和。

    Ben:看来还是不行。我们再理一下代码吧。

    Martin:你说的这些我之前都试过,都不行,要这样才行。

    Ben:我说的是这样做的,既然我们还没讨论清楚,我们再来看一下代码吧。

    两人拿出了纸和笔,对着屏幕一边画一边讨论,然而Ben并不认可Martin的方案,说要采用另外个方案。Martin则坚持认为这是一个可行的方案,得试试。Ben拿过键盘,准备按照Martin的方案写代码,但心里面颇为不爽,一直在想说服Martin采用他的方案试试。

    怒气

    到此时,时间都已经不知不觉过去两个小时了,然而问题似乎离真相总是忽远忽近。两个人已经疲劳不堪,再加上解决方案的不一致,两人的言语中开始显露出一些怒气。

    Zen在运行测试的空档,打断了两人的对话,建议道:

    既然大家已经产生了分歧,要不然两个人分开,各自实现一个,看谁能够先实现,然后再来讨论。

    Martin对于Zen并不认同,认为Zen指责他和Ben没有Pair好。

    Zen解释道:

    其实我听出了两人意见的不统一,言语中已经有一些怒火,这样下去Pair的效率很低。首先,大家带着不爽来干活,互相质疑。更关键的是,解决问题已经用去了两个多小时,大家都比较疲惫,可以适当休息。我让你们分开的目的是让大家冷静一下,在不受打扰的情况下工作一段时间,可能会不一样。

    冷静

    Martin回到了电脑面前,按照他的思路一步一步做下去。Ben去上了个厕所,倒掉了那杯冷冰冰的咖啡,泡了杯热茶。回到电脑前专注的重新按照他的思路一步一步走下去。

    其实两个人已经接近了真相,只是这之间不停的对话把注意力消耗殆尽。两人企图达到一个统一,然而口头的对话并不能解决问题,反而暂缓了这个过程。

    10分钟后,Ben兴高采烈的说已经搞出来了一套可以运行的方案,叫Martin一同过来看看。Ben的临时解决方案比较简单好理解,但并不完美。熟悉RxJava的Martin指出了一些可以改进的地方。

    然后两人又开始了新一轮的Pair,重新将这个方案完善。有了这个基础的解决方案,两人都很高兴,是朝着一个正确的方向大步向前。

    尾声

    下午6点半,虽然比正常下班晚了半个多小时,但还好整个解决方案都正常了,交付的任务也顺利完成。

    Ben和Martin都总结道,我们应该停止结对,当:

    • 两人的思路不统一但无法说服对方时:我们可以考虑分开一阵,安静一下,各自用可运行的代码来证明思路的可行。这里只需要相对粗糙的代码即可。
    • 时间已经超过番茄时间而感到疲惫时:人的专注力是有限的,在Pair时非常累,特别是在能力方面存在较大差距的时候。在这时候我们可以试试番茄工作法,让大脑得到休息。
    • 注意力不集中或者有其他事务要处理时:在Pair的时候,彼此要尊重对方,不要玩手机、看其他无关的网页,除非事先取得别人的同意,否则就要等到停止结对、处理完事务后再继续。
    • 给大家提供一个学习交流的平台,java架构师群: 558787436

      具有1-5工作经验的,面对目前流行的技术不知从何下手,需要突破技术瓶颈的可以加群。

      在公司待久了,过得很安逸,但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加群。

      如果没有工作经验,但基础非常扎实,对java工作机制,常用设计思想,常用java开发框架掌握熟练的可以加群。

    展开全文
  • 结对编程的好处与坏处

    千次阅读 2018-01-06 14:34:25
    0关注「实验楼」,每天分享一个项目教程 结对编程的概念已经存在很长一段时间,已经有许多公司认同这种编程方式,但也有许多公司表示他们不考虑采用。正文共:1137 字 预计阅读时间:3 分钟结对编程是软件开发过程...
  • 什么是结对编程

    2019-10-05 21:05:52
    结对编程(英语:Pair programming)是一种敏捷软件开发的方法,两个程序员在一个计算机上共同工作。一个人输入代码,而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员,审查代码的人称作观察员(或导航员...
  • 结对编程 我在Menlo Innovations的夏季课程 杰玛·埃文斯 ( Gemma Evans)在Unsplash上拍摄的照片 许多程序员对结对编程持怀疑态度:敏捷软件开发技术,其中两个程序员在一个工作站上工作。 这是我经常听到...
  • 在我做咨询工作的三年半时间里,我(跟客户)谈论结对编程的时间比其他任何话题都多。一般来讲,客户的开发人员都从来没有结对过,也根本没有这个念头。而且更糟的是,那些搞商务的总觉得两个人坐在一台机器前面是...
  • 结对编程的利与弊

    2020-05-08 14:27:40
    我在Menlo Innovations的暑假课程 杰玛·埃文斯 ( Gemma Evans)在Unsplash上拍摄的照片 许多程序员对结对编程持怀疑态度:敏捷软件开发技术,其中两个程序员在一个工作站上工作。 这是我经常听到的反馈类型: “这...
  • ThoughtWorks 结对编程

    千次阅读 2017-06-04 22:08:41
    可能就是某个懒散的下午,打开电脑,不知道做什么,打开牛客看了看,随即看到结对编程,不知道是做什么的,点开看了看;页面很好,不想中国人写的; 鬼使神差的就报名了,点进去看了看,居然 还有题;而且第一道题...
  • 敏捷开发之结对编程最佳实践

    千次阅读 2011-07-12 19:29:45
    讲到结对编程,我想大家首先想到的是XP极限编程中描述的,两位程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起完成编码工作。这种编程方式为众多敏捷爱好者所向往,但实际工作中尝试...
  • (1)首先应该是结对编程的高效率了,结对编程的时候,两个人可以分开做不同的unit,也可以同时做相同的unit。在项目的一些简单的unit,一个人能够很简单的unit就可以分给不同的人去做;对于核心的unit,比如说此次...
  • 结对编程是XP极限编程的关键实践之一,也是最备受争议的,我们往往对其既肯定又否定,我们感觉它会给我们带来效率上的提高,也会感觉它会降低我们的效率。 本文因javaEye论坛的一篇帖子所起,表述了我对结队编程的...
  • 为什么许多程序员讨厌结对编程

    千次阅读 2020-04-02 00:36:00
    结对编程是国外非常盛行的一种敏捷开发方式,今天 Google 最顶级的两位程序员 Jeff Dean 和 Sanjay Ghemawat 就是结对编程世界让人颇为津津乐道的人物。不过,...
  • 1. 联系结对编程,体验敏捷开发中的两人合作; 2. 两人一组,自由组合; 3. 使用一台计算机,共同编码,完成实验要求; 4. 在工作期间,两人的角色至少切换6次; 5. 使用JAVA+ECLIPSE编程。 心得...
  • 结对编程实践

    2019-08-05 20:34:19
    一、结对编程结对编程(Pair programming)是一种敏捷软件开发的方法,两个程序员在一个计算机上共同工作。一个人输入代码,而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员,审查代码的人称作观察员...
  • 专业编程领域总是产生一些相当激烈的争论。例如关于是否以及怎样对代码作注释。我们很难平息这些争论,因为科学地论证专业编程是有难度的。我们不可能真的要求大公司用一个对照组与一个实验组两次构建同一个软件。...
  • 结对编程和面向对象编程有何异同?面向对象编程是不是没有对象就学不好?
  • 结对编程是什么? 在此模式下,一对程序员并肩作战,平等互补进行开发工作。两个程序员并排坐在一台电脑前,同对一台显示器,使用同一个键盘,同一个鼠标进行工作。一起分析,一起测试,一起设计,一起编程。 这个...
1 2 3 4 5 ... 20
收藏数 22,574
精华内容 9,029
关键字:

结对编程