签入“注释掉"代码 [英] Checking in of "commented out" code

问题描述

好的，这里有一些事情在我目前的工作中引起了一些摩擦，我真的没想到会这样.组织内部软件开发在这里是一个新概念，我已经起草了一些编码指南的初稿.

Ok, here is something that has caused some friction at my current job and I really didn't expect it to. Organized in house software development is a new concept here and I have drawn up a first draft of some coding guidelines.

我建议永远不要将注释掉"的代码签入存储库.我这么说的原因是存储库维护了文件的完整历史记录.如果您要删除功能代码，则将其完全删除.存储库会保留您的更改，因此可以轻松查看更改的内容.

I have proposed that "commented out" code should never be checked into the repository. The reason I have stated this is that the repository maintains a full history of the files. If you are removing the functional code then remove it altogether. The repository keeps your changes so it is easy to see what was changed.

这引起了一些摩擦，因为另一位开发人员认为采用这条路线过于严格.该开发人员希望能够注释掉他正在处理但不完整的一些代码.这段代码之前永远不会被签入，也不会保存在任何地方.我们将使用 TFS，所以我建议搁置更改将是最正确的解决方案.然而，它没有被接受，因为他希望能够签入可能部署或可能未部署的部分更改.

This has caused some friction in that another developer believes that taking this route is too restrictive. This developer would like to be able to comment out some code that he is working on but is incomplete. This code then would never have been checked in before and then not saved anywhere. We are going to be using TFS so I suggested that shelving the changes would be the most correct solution. It was not accepted however because he would like to be able to checkin partial changes that may or may not be deployed.

我们希望最终能够充分利用持续集成并自动部署到开发 Web 服务器.目前没有网络服务器或数据库服务器的开发版本，但很快就会改变.

We want to eventually get to a point where we are taking full advantage of Continuous Integration and automatically deploying to a development web server. Currently there is no development version of web servers or database servers but that will all be changed soon.

无论如何，你有什么想法?您认为注释掉"的代码放在存储库中有用吗?

Anyway, what are your thoughts? Do you believe that "commented out" code is useful to have in the repository?

我很想听听其他人对这个话题的看法.

I'm very interested to hear from others on this topic.

为清楚起见，我们不使用私有分支.如果我们这样做了，我会说用你的私有分支做你想做的事，但永远不要将注释掉的代码与主干或任何共享分支合并.

For clarity sake, we don't use private branches. If we did then I'd say do what you want with your private branch but don't ever merge commented out code with the trunk or any shared branches.

我们没有正当理由不使用私有或按用户分支.这不是我不同意的概念.我们只是还没有那样设置.也许这就是最终的中间立场.目前我们使用 TFS 搁置.

There is no valid reason we don't use private or per user branches. It's not a concept I disagree with. We just haven't set it up that way yet. Perhaps that is the eventual middle ground. For now we use TFS shelving.

推荐答案

可能还有其他人有不同的经历，但在我看来，检查半完成的代码是一个可怕的想法，句号.

There may be others with different experiences, but in mine checking in half-finished code is a horrible idea, period.

以下是我学习并尝试遵循的原则:

Here are the principles I have learned and try to follow:

• 经常入住 - 至少一次，但最好每天多次
• 只签入完整的功能
• 如果第一次和第二次发生冲突(例如，使功能发挥作用需要一天以上的时间)，则任务太大 - 将其分解为较小的可完成任务.

这意味着:

• 不应签入注释掉的代码，因为它不起作用
• 评论不是有效的归档策略，因此无论是尚未完成的代码还是已退役的代码，评论和签入都没有任何意义.

总之，不！如果代码尚未准备好进入下一阶段(以适合您的阶段为准:IntTest/QA/UAT/PreProd/Prod)，则不应将其提交到主干或多开发人员分支.期间.

So in summary, NO! If the code is not ready to go to the next stage (whichever that is for you: IntTest/QA/UAT/PreProd/Prod), it should not be committed to a trunk or multi-developer branch. Period.

在阅读其他答案和评论后，我要补充一点，我认为禁止评论代码不一定是个好主意(不知道你会如何强制执行).我要说的是，您应该让团队中的每个人都认同我上面描述的理念.我工作的团队全心全意地拥抱它.因此，源代码控制是一个无摩擦的团队成员，可以帮助我们完成工作.

After reading the other answers and comments, I'll add that I don't think it's necessarily a good idea to ban commented code (not sure how you'd enforce that anyway). What I will say is that you should get everyone on your team to buy in to the philosophy I described above. The team I work on embraces it wholeheartedly. As a result, source control is a frictonless team-member, one that helps us get our job done.

不接受这种哲学的人通常会导致破窗 并且经常因源代码控制而感到沮丧.他们最多将其视为一种必要的罪恶，而在最坏的情况下则应避免这种罪恶；这会导致不频繁的签入，这意味着变更集巨大且难以合并，这加剧了挫败感，使签入变得更加需要避免，等等.这归根结底是一种态度问题，而不是真正的过程问题.很容易对它设置心理障碍；很容易找到它不起作用的原因，就像如果你真的不想节食，很容易找到不节食的理由.但是当人们确实想做并且致力于改变他们的习惯时，结果是戏剧性的.有效销售产品的责任在于您.

People who don't embrace that philosophy usually cause broken windows and are often frustrated by source control. They see it as a necessary evil at best, and something to avoid at worst; which leads to infrequent checkins, which means changesets are huge and hard to merge, which compounds frustration, makes checkins something to avoid even more, etc. This is ultimately an attitude thing, not really a process thing. It's easy to put up mental barriers against it; it's easy to find reasons why it won't work, just like it's easy to find reasons not to diet if you don't really want to. But when people do want to do it and are committed to changing their habits, the results are dramatic. The burden is on you to sell it effectively.

这篇关于签入“注释掉"代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！