collaboration - 一个程序员应该记录另一个人的代码吗？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

12 个月前关闭。




Improve this question




我们的几位主要开发人员已经说服管理层指派一名初级开发人员为他们记录他们的代码。

他们的论点是:

您将有两个熟悉一切的程序员。

这是结对编程，有点。

它更具成本效益 = 他们将完成更多工作。

它表明他们的代码是可读和可维护的。

他们很乐意回答任何问题；所以这是一种指导形式。

然而，他们为了保持最新状态而忙碌的程序员数量似乎随着时间的推移而增加。

这是一个好主意吗？

哇!这不是我们的经验!

以下是一些事实证明很重要的澄清。

高级开发人员是反射(reflection)性的自我记录者。这是一个核心的招聘问题。他们有时需要被告知“把这个留给初级人员”。

这被视为高级人员的验证工具(我认为我们的初级人员被雇用的阈值很高)。

是的，代码应该是单一用途和自我记录的。如果后辈不能轻易评论，那就是前辈认真对待的反馈。

初级人员应将其视为重构练习，而且这种方式的工作频率比您预期的要高。特别是捕捉像 YAGNI 问题、过度范围等的东西。他们可以把他们的前辈放在十字准线中。事实上，他们发起了这种变化。 (如果他们真的开始反对，我们会撤回。前辈们非常愿意调整——他们明白，他们比任何人都更应该为后辈们的成功负责。)

难道你的前辈不想解释他们的代码吗？

我们对“每个人都拥有代码”的敏捷原则有着坚定的 promise 。我们认为这会加速这一进程。

最后，个人笔记 - 当我试图理解别人的代码时，我想做的第一件事就是在我试图理解它时重新评论它。为什么评论被视为如此繁重？

也许我们会过滤掉一些初级申请者，因为我们明确表示这就是我们的工作方式。但这不是营业额问题。 (但只有3个月。)

Answer 1

可能不是一个好主意。出于多种原因:

如果有一串小辈会在他们之后“扫荡”，那么领导编写正确代码的动力就会减少。无论是使用文档还是其他方式。我从未见过降低质量的动机没有得到答复。

如果团队领导乐于回答问题，为什么不在配对 session 中回答问题？这实际上会花费更少的时间，因为您将能够立即回答问题，而无需尝试记住您上周做了什么。

结对编程不仅仅是一个初级开发人员，无所事事地看着高级开发人员。即使是最有经验的程序员也可以向后辈学习。即使这只是因为他们长期以来的假设受到挑战。如果你有麻烦，让初级控制键盘 - 这通常会为我解决。

代码应该是“自我记录”。像 Javadoc 之类的东西近年来已经过时了，因为它几乎没有增加值(value)(它总是过时的等等)。花时间重构代码以使其易于理解更有意义。

我不相信“更有成效”的说法。如果您有 5 名前辈全速前进，而 5 名后辈跟在他们身后，那么您只有 5 名开发人员在生产代码。如果您有 10 个开发人员以 2/3 的速率运行，则您的总体容量更大(约 6 个全速开发人员)。