团队成员数量不均匀的结对编程？

Question

最近，我们在工作中遇到了一个问题，如果一个人自己处理一些代码，似乎其他团队成员都在看着它，然后说“哈?这很难看，难以管理，我需要重写它。”

事实上，最近，我自己不得不重新考虑前一周写的一些东西，以便能够添加我的(相关)功能。

我知道结对编程是解决这一问题的方法，但我们有一个参差不齐的团队(3名成员)。由于我们的团队目前被推得很紧，我们真的没有时间进行同行评审(尽管我们可以进行结对编程，因为我们可以在任务估计中估计这一点)

我只是好奇人们会如何建议我们在生成糟糕的代码的情况下克服这些问题。

Answer 1

当你独自工作，并且产生了你的同事认为丑陋和难以管理并且需要重写的代码时，那么你：

(a)在你再看该文件时同意该等文件，

(b)不同意？

如果(a)，那么问题是你自己，当你写代码的时候，你没有完全弄清楚你的代码。既然结对编程是唯一能让你写出像样的代码的事情，我想我会建议“奇怪的一个”应该在不涉及编写大量糟糕代码的任务上工作:错误搜索；也许写测试代码，因为这往往不那么激烈。同时，努力提高你编写更好代码的技能--也许可以对几个月前你自己的代码进行审查，并记录下哪里出了问题。

如果(b)，那么你的问题是表达你的想法的方式不兼容。按照您的标准，代码可能并不糟糕，但它是相互不可理解的，这在企业环境中意味着它是糟糕的代码。结对编程意味着你写的东西是一个折衷方案，你们中的2/3都能理解，但这并不是真正的解决方案。你们需要就你们觉得彼此的代码中最困难的地方达成一些共识，并停止这样做。你们都迫切需要从“我的两个同事会喜欢这段代码”的角度开始思考“代码质量”，而不是“我喜欢这段代码”。

无论哪种方式，您都需要致力于编写代码的目的是为了被阅读，而不是为了尽可能快地完成即时工作。就我个人而言，我通过尝试用我认为其他人可能表达和理解的方式来表达事物，而不仅仅是当时对我有意义的东西。最终，它变得习惯性。当我写代码时，我是为公众写的，就像我为公众写这篇文章一样。好吧，在我的个人项目中，是一群和我一样思考的人，而在工作中，是一群和我的同事一样思考的人。但原则是编写代码时，就好像有人正在阅读它。你是在向他们解释你自己，而不是编译器。

并不是说我的代码是世界上最好的，但我确实认为我受益于我的第一份工作是在一家拥有30多名程序员的公司，所以我看到了各种各样的思考方式。还有一些“不做什么”的例子，其中一个程序员做了其他人都不容易理解的事情，因此可以肯定地说是糟糕的。在只有3个人的情况下，不清楚2比1的意见分歧是否意味着1是变态还是合理的少数。当我做了一件事，有四五个人看了一眼，马上就会说“哦，不要那样做”，然后我开始真的相信这只是一个愚蠢的想法。

我还建议，如果你不被允许为代码审查做预算，那就说谎和作弊吧。如果你大量重写别人的代码，你实际上是在花时间审查它，你只是没有提供反馈，这是代码审查中值得的一部分。因此，在雷达下偷偷地进行审查--编写一个或三个函数，然后请同事查看它，并立即给出对他们是否有意义的反馈。一旦你完成了这项工作，就与监视器上的代码进行对话是有帮助的，但不要在人们“心流”时打断他们，也不要陷入冗长的争论中。这不是结对编程，也不是正式的代码审查，但它可能会帮助你找出你自己在做什么，这太糟糕了。

Answer 2

我很惊讶你没有时间做同行评审，但你有时间做结对编程。后者不是一个更大的时间沉没吗？

我们公司也只有三名开发人员，而且，令人惊讶的是，我们现在正被推得很紧。我敢肯定，如果我建议配对编程，我的老板会嘲笑我的，因为这会被视为一项任务的工时增加了一倍，尽管实际上这并不是它应该产生的结果。我们的同行评审从来不会超过一个小时，这是一个极端的例子。平均而言，我会说它们可能只有10分钟左右，并且每个开发人员一天只发生一到两次。

我想你应该试一试同行评审。你经常会发现有问题的人(即编写质量较低的代码的人)最终会意识到他们需要付出更多的努力，并且质量会随着时间的推移而提高。

Answer 3

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