与不均匀的团队成员配对编程?[关闭]

当你一个人工作,产生你的同事觉得丑陋和难以管理的代码,需要重写时,你会:

(a)第二次看的时候同意他们,

(b)不同意?

如果(a),那么问题是你自己写代码的时候没有完全澄清你的代码。因为结对编程是唯一能让你写出像样代码的东西,我想我会建议“奇怪的一个”应该在不涉及编写长段坏代码的任务上工作:bug搜索;也许编写测试代码,因为这样做往往不那么疯狂。同时,努力提高编写更好代码的技能——也许几个月前对自己的代码进行审查,并记下它出了什么问题。

如果(b),那么你所面临的问题就是表达你想法的方式不兼容。按照您的标准,代码可能并不坏,但它是相互不可理解的,在公司环境中这意味着它是坏代码。配对编程意味着你写的是一个折衷方案,三分之二的人理解,但这不是真正的解决方案。你需要就彼此的代码中最困难的部分达成一些共识,然后停止这样做。你们都迫切需要从“我的两个同事会喜欢这个代码”开始思考“代码质量”,而不是“我喜欢这个代码”。

不管怎样,你们都需要努力编写代码 为了被人阅读 而不是为了尽快完成工作。就我个人而言,我通过尝试用我认为其他人可能表达和理解的方式来表达事情,而不仅仅是用当时对我有意义的方式。最终它变成习惯。当我写代码的时候,我为公众写代码,就像我为公众写这篇文章一样。好吧,所以在我的个人项目中,是一群和我一样思考的人,而在工作中,是一群和我的同事一样思考的人。但原则是编写代码,就好像有人在读代码一样。你在向他们解释你自己,而不是编译器。

不是说我的代码是世界上最好的,但我认为我的第一份工作是在一家有30多名程序员的公司里,所以我看到了很多思考问题的方法。还有一些“不做什么”的例子,其中一个程序员做了一些 没有人 否则很容易理解,因此可以肯定地说是坏的。对于只有3个人的人来说,2:1的意见分歧是否意味着1是一个怪胎还是一个合理的少数人还不清楚。当我做了某件事,四五个人都能看一眼,立刻说“哎,别这样做”,然后我开始真的相信这只是一个愚蠢的想法。

我还建议,如果不允许你为代码审查做预算,那就撒谎和作弊。如果你正在大量编写别人的代码,你实际上是在花时间来审查它,你只是没有提供反馈,这是代码审查中值得一提的部分。所以,偷偷地把评论放在雷达下面——写一个或三个函数,然后让一个同事看一下它,并立即给你反馈是否对他们有意义。一旦你完成了对话,用监视器上的代码进行对话是有帮助的,但是不要试图在人们“流动”时打断他们,或者进入冗长的争论中。这不是结对编程,也不是正式的代码审查,但它可能会帮助您找出自己在做什么,这太糟糕了。

我很惊讶你没有时间做同行评审,但是你有时间做配对编程。后者不是更大的时间沉淀吗?

我们公司也只有三个开发人员,令人惊讶的是,我们目前正受到大力推动。如果我建议用配对编程,我肯定我的老板会嘲笑我,因为这会被视为一项任务的工时翻倍,即使在实践中,这不是它应该产生的结果。我们的同行评议从不超过一小时,这是一个极端的情况。平均来说,我会说它们大概有10分钟左右,而且,对于每个开发人员来说,一天只发生一到两次。

在我看来,你应该尝试一下同行评议。你经常发现冒犯的人(即编写低质量代码的人)最终意识到他们需要付出更多的努力,并且质量会随着时间的推移而提高。

如果您有三个开发人员,并且每个人都认为其他代码不好,那么您迫切需要同行评审。

所以:

• 你被推得很厉害
• 你的代码质量不好

你认为这两个可能有关联吗?答案是确定时间表。

三人同时配对。

建立一些编码标准。

使用dunce cap来破坏构建的开发人员。

每天召开站立会议,沟通进展情况。

也可以一周两次尝试同行评论,比如周二和周五。

结对编程不必每天都是有效的。我已经看到了每周一起工作一两个小时的好结果。一种方法是将A&B配对一段时间,然后A&C,然后A&B…中间有很多个人时间。

这也很大程度上取决于团队成员的性格和化学反应。三者中的两个可能在一起工作得非常好,你希望从中受益。

你还是应该配对。设置训练,例如每周1天,并轮流进行。这应该能让你的经理高兴,提高代码的质量,改善沟通。如果对成对编码和单独编码中发生的错误数量保持度量,则应该开始查看benfit并将其显示给经理,

这花费了X个工时,但平均节省了Y的缺陷修复时间。此外,土块是清洁的,将花费较少的时间来改变,然后下次我们触摸它。

从那里你将有硬统计,你可以开始编码更多。

基本上你的故事和我的一样。

1. 没时间做事。
2. 错误会发生。
3. 急着修(花更多时间)
4. 转到1

你需要停止腐烂。

1. 代码审查
2. 启用Stylecop,它将强制您编写可读、标准化和可管理的代码。

我们使用代码审查。另外还有一些单一的任务:更改图表,安装一些东西…