好的,这件事在我目前的工作中引起了一些摩擦,我真的没想到.有组织的内部软件开发是一个新概念,我已经制定了一些编码指南的初稿.
我建议永远不要将"注释掉"的代码检入存储库.我之所以这样说的原因是存储库保存了文件的完整历史记录.如果要删除功能代码,请将其完全删除.存储库会保留您的更改,以便轻松查看更改内容.
这引起了一些摩擦,因为另一位开发商认为采取这种方式限制太多.这位开发人员希望能够注释掉他正在处理但尚未完成的一些代码.然后,此代码将永远不会被签入,然后不会保存在任何地方.我们将使用TFS,因此我建议搁置更改将是最正确的解决方案.然而,它并未被接受,因为他希望能够检查可能部署或不部署的部分更改.
我们希望最终能够充分利用持续集成并自动部署到开发Web服务器.目前没有Web服务器或数据库服务器的开发版本,但很快就会更改.
无论如何,你有什么想法？您是否认为"注释掉"代码对存储库有用？
我很想听听其他人对这个话题的看法.
编辑:为清楚起见,我们不使用私有分支.如果我们这样做,那么我会说你的私人分支做你想要的,但不要将已注释的代码与主干或任何共享分支合并.
编辑:我们没有使用私有或每个用户分支的正当理由.这不是我不同意的概念.我们还没有这样设置.也许这是最终的中间立场.现在我们使用TFS搁架.
可能有其他人有不同的经历,但在我的检查半完成代码是一个可怕的想法,期间.
以下是我学习并尝试遵循的原则:
经常入住 - 至少一次,但最好每天多次
仅签入完整功能
如果第一次和第二次冲突(例如,使功能工作需要一天以上),则任务太大 - 将其分解为较小的可完成任务.
这意味着:
注销掉的代码永远不应该签入,因为它不起作用
评论不是一种有效的档案策略,因此无论是尚未完成的代码还是已退休的代码,评论和签到都没有任何意义.
总而言之,不!如果代码还没有准备好进入下一阶段(无论哪个是你的:IntTest/QA/UAT/PreProd/Prod),它不应该提交给主干或多开发人员分支.期.
编辑:在阅读其他答案和评论之后,我会补充一点,我认为禁止评论代码并不一定是个好主意(不知道你是怎么强制执行的).我要说的是,你应该让团队中的每个人都按照我上面描述的理念购买.我工作的团队全心全意地接受它.因此,源代码控制是一个没有结果的团队成员,可以帮助我们完成工作.
那些不接受这种哲学的人通常会导致破窗,并且经常受到源控制的挫败.他们认为这充其量是一种必要的邪恶,最糟糕的是要避免; 这导致不常见的签到,这意味着变更集是巨大的,难以合并,这会使人感到沮丧,使签到的东西更加难以避免等等.这最终是一种态度,而不是真正的过程.对它提出心理障碍很容易; 很容易找到原因,为什么它不起作用,就像你很容易找到不节食的理由,如果你真的不想.但是当人们确实想要这样做并致力于改变他们的习惯时,结果就是戏剧性的.你有责任有效地出售它.
"从不"在指南中很少使用.
您的同事有一个很好的示例,说明何时检查已注释掉的代码可能是合适的:当它不完整时,如果在激活时签入,可能会破坏应用程序.
在大多数情况下,在管理良好的变更控制系统中,不需要注释掉死代码.但是,并非所有评论的代码都"死了".
为了维护历史记录,永远不应该签出注释掉的代码.这是源控制的重点.
人们在这里谈论很多理想.也许与其他所有人不同,我必须在多个项目中工作,"真实世界"偶尔会打断我的工作日.
有时,现实是,我必须签入部分完整的代码.它可能会丢失代码或签入不完整的代码.无论多么小,我都无法承担"完成"任务的费用.但是,如果没有签入所有代码,我将不会将笔记本电脑与网络断开连接.
如有必要,我将创建自己的工作分支以提交部分更改.
我留下注释掉代码的一个案例:
// This approach doesn't work // Blah, blah, blah
当这是问题的明显方法,但它包含一些微妙的缺陷.当然,存储库会拥有它,但存储库不会警告任何人不要走这条路.
强烈地,我肯定会沮丧地检查已注释掉的代码.但是,我不会绝对禁止它.有时(如果很少)将注释掉的代码检查到源代码控制中是合适的.说"永远不要那样做"太严格了.
我想我们都同意这些观点:
切勿将死代码检查到源代码管理中
永远不要将损坏的(无功能)代码检查到源代码控制中,至少永远不会检查到主干,并且很少会检查到私有分支,YMMV
如果您为了调试目的暂时注释掉某些内容或破坏某些内容,请不要检查代码,直到将代码恢复为正确的形式为止
有些人说有其他类别,例如暂时删除的代码,或者增量但不完整的改进,包括少量注释掉的代码作为下一步的文档,或者非常短(理想情况下为1行)的评论片段代码显示永远不应重新添加的内容.注释掉的代码应该总是附有一个注释,说明为什么它被注释掉(而不仅仅是删除)并给出注释掉的代码的预期生命周期.例如,"以下代码弊大于利,因此被注释掉了,但需要在发布XXX之前进行替换."
如果您提供修补程序以阻止客户流血并且您没有立即找到最终修复的机会,那么上述评论是合适的.在提供此修补程序后,注释掉的代码提醒您仍然需要修复某些内容.
我什么时候签入注释掉的代码？一个例子是当我暂时删除某些东西时,我认为很有可能在不久的将来以某种形式重新添加.已注释掉的代码可以直接提醒您这是不完整的.当然,旧版本在源代码控制中,您可以使用FIXME注释作为标记,需要更多内容.但是,有时(如果不经常)代码是更好的评论.
此外,当通过删除一行(或更少,两行)代码来修复错误时,我有时只会注释掉带有注释的行,以便永远不会重新启用该代码.这种评论清晰,直接,简洁.
雷克斯M说:1)只检查完整功能,2)[如果]任务太大 - 将其分解为较小的可完成任务.
回答:是的,这是理想的.有时,当您处理生产代码并且需要立即解决关键问题时,这两个选项都无法实现.有时为了完成一项任务,您需要在该字段中放置一段代码一段时间.当您尝试查找问题的根本原因时,对于数据收集代码更改尤其如此.
对于在更一般的问题中被询问的特定实例...只要开发人员将注释掉的代码检查到私有分支中,除了那个开发人员(也许是开发人员正在合作的人)之外,没有人会看到,它没有什么害处.但是,开发人员应该(几乎)永远不会将此类代码提供给主干或等效代码.Trunk应该始终构建并且应该始终运行.向trunk提供未完成的代码几乎总是一个非常糟糕的主意.如果您让开发人员将未完成或临时代码检入专用分支,那么您必须依赖开发人员在交付到主干之前不要忘记清除代码.
为了澄清对其他答案的评论,如果代码被注释掉并签入,我期望代码将在未注释的情况下随着代码被注释掉的时间长度而下降.显然,重构工具并不总是在重构中包含注释.几乎总是,如果我把注释掉的代码投入生产,代码就可以作为一个精致的评论,比散文更具体,需要在那里做一些事情.这不应该是一个长寿的东西.
最后,如果您可以在每个源文件中找到已注释掉的代码,那么就会出现问题.出于任何原因将注释掉的代码传递到主干应该是一种罕见的事件.如果经常发生这种情况,那么它就会变得混乱而失去价值.
我认为从来没有太强大的条件.
我倾向于注释掉,签入,运行测试,进行思考,然后在下一个版本之后删除注释.
通常,签入注释掉的代码是错误的,因为它会使那些不是原作者并且需要阅读或修改代码的人产生混淆.无论如何,原作者经常在3个月过后对代码感到困惑.
我认为代码属于公司或团队,并且您有责任让同事轻松完成任务.签入注释掉的代码而不添加关于它被保留的原因的评论等于说:
我不介意你是否最终对为什么这些东西在这里感到困惑.我的需求比你的更重要,这就是为什么我这样做了.我觉得没有必要为你或其他任何人辩护,为什么我这样做了.
对我来说,评论出来的代码通常被视为不那么体贴的同事不尊重的标志.
我完全同意不应该检查注释掉代码的原则.源代码控制系统是一个共享资源,你的同事在某种程度上将它用作他的个人便笺簿.这对其他用户来说并不是很体贴,特别是如果您订阅了代码库共享所有权的想法.
下一个看到注释掉的代码的开发人员不会知道它正在进行中.他可以自由改变吗？这是死代码吗？他不知道.
如果您的同事的更改未处于可以签入的状态,则需要完成更改,和/或学习进行更小的增量更改.
"检查可能部署或未部署的部分更改" - 可能也意味着可能会或可能不会进行测试？对于一个非常冗长的代码库来说,这是一个滑坡.
当你需要添加一个小功能或错误修复时,在接下来的3分钟内,你必须修复一个文件,你有一些半开发的代码,我说它没关系,实际需要统治战场上的实用理想.
这显示了两种思想流派的根本区别:那些只检查工作代码,他们感到满意和感觉值得保存的人,以及那些检查他们工作的人,因此修订控制可以支持他们防止数据丢失.
我将后者描述为"那些喜欢使用他们的版本控制系统作为穷人的磁带备份的人",但这会让我的手掌握在我所在的营地.:-)
我的猜测是你是"好代码"阵营,他是"工作代码"阵营.
[编辑]
从评论中,我猜对了.
就像我说的那样,我和你在一起,但是我尽可能地说这是一个少数意见,无论是在stackoverflow还是在我工作的地方.因此,我认为您不能真正将其作为唯一的运营方式纳入您的开发标准.如果你想要遵循标准,那就不是了.一个好的领导者知道的一件事是永远不要发出他们知道不会被遵循的命令.
顺便说一句:优秀的编辑将帮助保留旧版本.例如,在Emacs中,我将keep-old-versions和keep-old-versions设置为10,这样可以保留我文件的最后10次保存.您可以将其视为一种帮助您反对修订控制备份人群的方法.但是,你永远不会赢得这场争论.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
