不是所有人都适合当程序员_是否适合所有人?

不是所有人都适合当程序员

结对编程是共享知识的好方法。 但是每个开发人员都不一样,配对是否对每个人都有效?

配对有助于团队规范其知识-一个人知道的东西,其他人都可以通过配对学习:键盘快捷键,技术,做法,第三方库以及正在使用的源代码的详细信息。这提高了平均水平团队,并停止知识孤岛。

配对也有助于纪律处分:当有人坐在你旁边,确实代表你的良心时,很难说不需要单元测试。 当坐在您旁边的人控制了键盘以阻止您针对源代码犯下战争罪行时,仅执行快速而肮脏的hack来执行下一个任务也要困难得多。

大多数团队所面临的最大问题基本上是沟通中的一种:详细协调开发团队的活动很困难。 理想情况下,每个开发人员都应该知道整个团队中正在发生的一切,但这显然不切实际。 相反,我们必须划定界限,以便更轻松地对整个系统进行推理,而不必了解整个系统的详细程度。 我将创建一个API,一些边界层,然后我们每个人都在自己的一边工作。 我将创建服务,然后整理用户界面。 我将整理网络协议,然后整理应用程序层。 您必须引入架构边界以简化通信和协调。 您的体系结构会立即反映出构建该体系结构的开发人员之间的关系。

在成对的团队中,这些界限可能会更柔和。 它们仍然会发生,但是边界变得更柔和,因为当成对旋转时,您会看到任何边界的两侧,因此它不会成为您不知道且无法更改的黑匣子。 有一天,我正在编写用户界面代码,第二天,我正在编写提供该代码的服务层。 这就是您发现不一致之处和机会来修复体系结构并利用双方的实现细节。 否则,这种交流很难。 连续的轮换轮换意味着您可以接近每个开发人员广泛了解的无处不在的理想。

但是,说实话:配对并不适合所有人。 我和一些擅长配对的人一起工作,很高兴与他们合作。 当您指出他们的想法的致命缺陷时,没有任何问题可以解释他们的思维过程并且没有自我挫败的人。 发现您失去思路的人,然后找到您离开的地方。

良好的配对非常社交 。 配对的团队听起来很吵 。 当您开始配对时,这可能是最难的事情之一:我似乎整日都在争论交谈 。 我们什么时候开始写一些该死的代码 ? 但这只是凸显了实际上在源代码中键入的工作很少。 一天中的大部分时间都在寻找做出哪些更改以及在何处进行更改。 一行代码可能需要花费数小时的争论才能找到正确的位置。

但是编程往往会吸引比其他人不那么社交的人-让我们面对现实,我们是一个非常反社会的人群:我整天都在与工作于1和0的机器进行协商。 对我而言,不是人类交流的细微差别,它要么编译要么不编译。 我不必协商或尝试淘汰编译器。 我不必处理“那些日子之一”的编译器(嗯,我这么说,有时我发誓……)。 我不必将编译器放到一边,因为它的猫死了,所以提供了令人安慰的字眼。 我不必担心会损害编译器的感觉,因为我已经犯了100次相同的错误:“是的,我当然在听您说话,不,我不仅在无视您。 亲爱的,我当然重视您的意见。 但是说真的,这绝对是TFoo的IList!”

因此,在您遇到的各种各样的程序员中,有些人性格外向,这些人都乐于在一群人中共同开发软件,而这些社交性和人性化的方面也就不足为奇了。 以及那些内向的角色,他们喜欢为解决恶魔般的问题制定优雅的解决方案,从而解决了安静,私密,智力上的挑战。

如此配对:任何团队最终都会混在一起。 性格外向的人倾向于配对,而性格内向的人倾向于更难寻求避免。 这并不一定是教育或说服力的问题,好处是相对无形的,内向的开发人员可能会发现整个过程比单独工作有趣。 听起来有些陈词滥调:但是快乐的开发人员是富有成效的开发人员。 做任何让您的同龄人不高兴的事情是没有意义的。 所有团队都需要同意规则。 例如,有些人喜欢在开放式办公室里吃真正有臭味的食物。 优秀的团队倾向于就此类行为达成共识。 每个人都同意,为个人付出些微牺牲对团队和谐至关重要。

但是,如何解决配对带来的意见分歧? 作为团队的决定,配对有点全有或全无。 我们要么同意对所有东西进行配对,所以就没有代码所有权,有规律地轮换并且我们彼此学习。 要么我们不这样做,我们每个人都要为自己的统治负责。 我们不能同意那些想要配对的人会进入配对室,以免打扰其他所有人。

一种选择是仅要求团队中的每个人都必须喜欢配对。 我对你一无所知:雇用好人很难 。 我要做的最后一件事是开始排除那些本来可以生产的人。 是不是会好一些,至少已经有人在做什么 ,即使他们没有配对?

另一种选择是强迫开发人员结对,即使他们发现困难或不舒服。 但这真的会产生生产力吗? 建立怨恨和不满情绪不会建立一支高绩效的团队。 当然,另一个极端也很可能引起不安:如果您停止所有配对,那么那些想要配对的人会感到不满和不快乐。

那中间立场呢? 您是否可以建立一个团队,其中有人配对,而另一些人则独自工作? 康韦定律似乎不可避免地会发挥作用:软件的结构将反映团队的结构。 自己工作的开发人员和正在配对的开发人员之间很难有重叠。 出于完全相同的原因,一组单独的开发人员很难同时在同一代码区域上重叠:您必须引入一些体系结构边界以简化协调。

这意味着您最终仍然会遇到一系列孤岛,其中一些孤岛由单个开发人员拥有,有些则由一组开发人员拥有。 这会给您最大的妥协吗? 还是两全其美?

您的经验是什么? 你尝试了什么? 什么有效,什么无效?

翻译自: https://www.javacodegeeks.com/2014/08/is-pairing-for-everybody.html

不是所有人都适合当程序员

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值