我们的一些主要开发人员已经寻求管理层指派一名初级开发人员为他们记录他们的代码.
他们的论点是:
然而,为了保持最新状态,他们保持忙碌的程序员数量似乎随着时间的推移而增加.
这是一个好主意吗？
哇!这不是我们的经验!
以下是一些重要的澄清说明.
高级开发人员是反身自我记录员.这是一个核心招聘问题.他们有时需要被告知"为初级人员留下这个".
这是作为高级家伙的验证工具(我们的初级人员被聘用,我认为相当高的标准清除).
是的,代码应该是单一目的和自我记录.如果初级人员不能轻易评论,这是老年人认真对待的反馈.
期望青少年将其视为重构练习,并且它的工作方式比您预期的更频繁.特别是捕捉YAGNI问题,范围过大等问题.他们将老年人放入十字准线.事实上,他们起源于这种变化.(如果他们真的开始反对,我们会支持它.老年人非常愿意调整 - 他们明白他们比其他任何人都更有责任成功.)
难道你的资深人士不想解释他们的代码吗？
我们坚定地致力于"每个人都拥有代码"的敏捷原则.我们认为这会加速这一进程.
最后,个人笔记 - 当我试图理解别人的代码时,我想要做的第一件事就是在我试图理解它时重新评论它.为什么评论被视为如此繁重？
也许我们过滤掉一些初级申请人,因为我们明确说明这是我们的工作方式.但这不是营业额问题.(但这只是3个月.)
leo*_*onm 13
可能不是这么好的主意.出于多种原因:
如果有一串青少年将在他们之后"拖把",那么导致编写正确代码的动机就会减少.与文档或其他方式一样.我从未见过降低质量的动机没有答案.
如果团队负责人乐于回答问题,为什么不在配对会议中回答问题呢？它实际上将花费更少的时间,因为你将能够在那里回答问题然后,而不必尝试记住你上周做了什么.
结对编程不仅仅是一个坐在老人面前闲聊的初级开发人员.即使是最有经验的程序员也可以向青少年学习.即使只是因为他们的长期假设受到挑战.如果你遇到麻烦,让大三学生掌控键盘 - 这通常会为我解决.
代码应该是"自我记录".像Javadoc这样的东西近年来已经不再流行,因为它增加了很少的价值(它总是过时等等).花时间重构代码使其易于理解更有意义.
我不买"更富有成效"的论点.如果你有5名高年级学生全速前进,5名大三学生在他们身后扫荡,你只有5名开发者生成代码.如果你有10个开发者以2/3的速度运行,那么你的整体容量会更大(~6个全速开发).
| 归档时间： |
|
| 查看次数： |
615 次 |
| 最近记录： |