最近，我们在工作中遇到了一个问题，如果一个人自己编写一些代码，其他团队成员似乎会看到它并说“嗯？这太难看了，难以管理，我需要重写”
事实上，最近，我自己不得不重新考虑前一周编写的一些内容，以便我能够添加我的(相关)功能。
我知道结对编程是实现这一目标的方法，但我们的团队参差不齐(3 名成员)。由于我们的团队目前面临着很大的压力，我们确实没有时间进行同行评审(尽管我们可以进行结对编程，因为我们可以将其估计到我们的任务估计中)
我只是好奇人们会如何建议我们通过生成不良代码来克服这些问题。
最佳答案
当您独自工作并编写出同事认为丑陋且难以管理且需要重写的代码时，您会:
(a) 当您第二次查看时同意他们的观点，
(b) 不同意？
如果是 (a)，那么问题在于您自己编写代码时并未完全阐明代码。由于结对编程是唯一能让你编写出像样的代码的方法，我想我建议“奇数”应该适用于不涉及编写大量糟糕代码的任务:寻找错误；也许编写测试代码，因为这往往不那么残酷。同时，努力提高编写更好代码的技能 - 也许对几个月前自己的代码进行审查，并记下其中的问题。
如果 (b)，那么您遇到的问题是表达想法的方式不兼容。按照您的标准，代码可能并不糟糕，但它是相互无法理解的，这在公司环境中意味着它是糟糕的代码。结对编程意味着您编写的内容是三分之二的人理解的妥协方案，但这并不是真正的解决方案。你们需要就彼此代码中最困难的部分达成一些共识，并停止这样做。你们都迫切需要开始考虑“代码质量”，即“我的两个同事会喜欢这段代码”，而不是“我喜欢这段代码”。
无论哪种方式，你们编写代码都需要为了被阅读，而不是为了尽快完成当前的工作。就我个人而言，我是通过尝试以我认为其他人可能表达和理解的方式来表达事物，而不是仅仅用当时对我有意义的方式来表达事物。最终它变成了习惯。当我编写代码时，我是为公众编写的，就像我为公众编写这篇文章一样。好的，所以在我的个人项目中，受众是和我想法一样的人，而在工作中，受众是和我同事一样思考的人。但原则是编写代码就像有人在读它一样。您是在向他们解释自己，而不是向编译器解释。
并不是说我的代码是世界上最好的，但我确实认为我受益匪浅，因为我的第一份工作是在一家拥有 30 多名程序员的公司，所以我看到了各种各样的思考事物的方式。还有一些“不该做什么”的例子，其中一个程序员做了一些其他人无法轻易理解的事情，因此可以明确地说是不好的。只有 3 个人，并不清楚 2 对 1 的意见分歧是否意味着 1 个人是怪胎还是合理的少数。当我做了某件事，四五个人看到它并立即说“哎呀，不要这样做”时，我开始真正相信这从一开始就是一个愚蠢的想法。
我还建议，如果您不被允许为代码审查预算，那就撒谎和作弊。如果您大量重写别人的代码，那么您实际上是在花时间对其进行审查，只是没有提供反馈，而反馈是代码审查中有值(value)的部分。因此，请不要在雷达下进行评论 - 编写一个或三个函数，然后请同事查看它，并就该函数对他们是否有意义向您提供即时反馈。完成后立即与显示器上的代码进行对话会有所帮助，但请尽量不要在人们“流畅”时打断他们，或者进行冗长的争论。这不是结对编程，也不是正式的代码审查，但它可能会帮助您弄清楚您自己所做的事情是多么糟糕。
关于agile - 与数量不等的团队成员进行结对编程？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1115987/