开发人员如何在自己的工作站上工作的标准

我们只是遇到了一种情况，这种情况有时会在开发人员在项目进行中几天病倒的情况下出现。

关于他是否提交了最新版本的代码还是我们应该关注的本地计算机上是否存在一些最新问题，我们存在一些疑问，我们已经交付给客户，因此我们迫不及待他返回。

其他开发人员中的一个以他的身份登录并发现了一个混乱的工作空间，其中许多貌似是同一项目，但带有时间戳，使得不清楚哪个是“当前”（他正在对项目版本的一些原型进行原型设计，而不是他的“核心”之一）。

显然这是一个痛苦的瓶颈，但是替代方案（这似乎是每个开发人员如何在自己的计算机上工作以确保其他任何开发人员都可以用最少的精力来捡拾东西的严格标准）可能会破坏很多开发人员的个人工作流程，并导致个人效率低下。

我不是在谈论签入代码的标准，甚至不是通用的开发标准，而是在谈论开发人员在本地的工作方式，根据我的经验，这个领域通常被认为几乎完全在开发人员自己的控制之下。

那么如何处理这种情况呢？这是发生的事情之一，您必须处理，让开发人员付出的代价能够以最适合他们的方式工作？

还是您要求开发人员遵守这方面的标准-使用特定目录，命名标准，Wiki上的注释或其他内容？如果是的话，您的标准涵盖了哪些内容，它们的严格程度如何，您如何监管它们等等？

还是我还缺少其他解决方案？

[[为了争辩，假设无法与开发人员联系以讨论他在这里所做的事情-即使他能够知道并描述内存中哪个工作区也不会变得简单无瑕，有时人们真的可以我们无法与您联系，希望提供一种解决所有可能情况的解决方案。]

编辑：我知道通过某人的工作站是不好的形式（尽管这是一个有趣的问题，而且可能是主题外的问题，确切说明为什么如此），而且我当然不是在寻找无限的访问权限。按照标准的思路进行更多思考，在该标准中，将其代码目录设置为只读共享-无法更改，看不到其他内容，依此类推。

“ 如果不在源代码管理中，则它不存在。 ”

这是我的职业教条中为数不多的几件事之一。由于以下原因：

1. 即使工作站是公司财产，我们也要面对现实-某个不成文的规则是程序员自己的工作站就是他/她的城堡。我对工作场所文化感到不安，在这里，任何人都可以例行登录并通过它。
2. 每个人都有自己的流程（也如您所说）。试图强迫所有开发人员以某种方式组织自己的本地工作区可能会违背其特定的工作方式，并中断其流程并降低其效率。
3. 源代码管理中没有的东西是半熟的代码。如果准备发布的是完全烘焙的代码，则应在源代码控制中。再次回到重点...
4. “如果不在源代码管理中，则它不存在。”

减轻希望在人们的工作站上查看代码的问题的一种可能方法是，养成定期签到的文化。我曾经在一家公司工作过-即使没有官方授权-总是在周末检查所有东西是一种自豪感。在维护和发布候选阶段中，CR项被故意细化以允许进行小的，清晰可见的更改，并进行定期检入来跟踪它们。

此外，拥有一切你去度假前检查是强制性的。

TL; DR版本：通过人的工作站来步枪是不好的形式。与其尝试培养一种易于通过人们的工作站来找到我们想要的东西的文化，不如培养一种明智地使用源代码控制和定期检入的文化。在项目的关键阶段，甚至可能进行超常规签入，以及执行细粒度的任务。

而不是针对开发人员如何组织其工作站实施标准，而是实施一种在每天结束时检入所有工作的标准。如果仍未完成，则签入可能会到分支机构。

这样，任何人都不需要访问其他开发人员的工作站。

我可以想象该政策会遇到一些反对，但是与您执行有关工作站的组织的规则相比，我的期望与之相比没有什么。

我会告诉你一个事实，对于有人要登录到我的机器并浏览我的东西，我感到不安。当然，这是公司的设备和财产，但这简直是一件坏事。

上一次我离开一个周末时，这些家伙用数据库和源代码控制重新配置了服务器，由于某种原因，我觉得有必要登录到我的计算机上并为新设置重新配置系统。

太糟糕了，他们不知道自己在做什么，他们抹掉了我过去两个月一直在研究的原型。

如果适当的沟通到位，就不会发生。那也是您所需要的。去找那个开发者，找出事情的状态。更好的是，请人们在休假前要求他们提供报告，以便您做出明智的决定，是否需要他们的任何东西。

但是请不要与人们的工作站混为一谈。

PS：我们确实有目录结构的约定，但其主要存在的原因是历史/配置的混合-将其放在其他任何地方都不会编译。

几个月前，我正在做一个相当大的项目，不得不突然离开工作，因为我发现我被送进医院了。我没有时间检查项目的最新代码。

幸运的是，这是惯例（尽管不是“必需”）将代码存储在其中/var/www/ourdomain.com以模仿生产。有了这样一种合理且易于遵循的约定，同事很容易登录到我的计算机并检索我的最新更改。

我认为一些约定是好的。虽然我同意鲍比说的话

“如果不在源代码管理中，则它不存在。”

另外，对任何程序员工作区来说，有用的补充可能是前托架热插拔SATA驱动器，该驱动器上可以存储所有源和开发项目。这样，如果确实出现了此类问题，则员工无需登录开发人员工作站即可轻松检索项目的新源代码更改。

问题的第一部分清楚地确定了团队内部的沟通问题。您是否尝试过每日站立训练？

当您说标准太严格时，可能会导致效率低下，我对此表示同意。标准必须由团队来定义，涉及每个人。

就您而言，我会在有关的开发人员重返工作后等待几天。然后组织一次会议讨论这些标准。

为了避免任何心理障碍和抵制，请不要命名您看到的人或特定事物。保持一般性，这里的目标是从所有人（包括您认为应该改善其工作方式的开发人员）中获取意见。那家伙可能也会把您的组织看作一团糟。

在会议期间，提出问题并明确询问团队如何改善情况。

（整个）团队决定要做什么。

该用户可能正遭受缺少适当工具的困扰。特别是，使用分布式版本控制系统对他来说将不再需要处于不同状态的不同代码目录。他本可以将所有内容保留在分支机构中，并且更加快乐。

不过，最重要的是，我不希望在如何组织自己的工作站上强制执行标准。我目前正在回避我的部门在IDE上的标准化工作（我的老板真的希望我们在Eclipse中工作，因为这是他使用的并且很了解，即使IMO并不是我工作的最佳工具）。

让开发人员做任何让他们感到舒服的事情。舒适的开发人员比不舒适的开发人员更有生产力。而且，如果某人的生产力不足，并且您怀疑他们在本地使用这些工具摸索，那是培训的机会，而不是制定新规则的好时机。

在我以前的工作场所，我们有一个系统，使错误跟踪中的每个任务在源代码管理中都有其自己的分支。据了解，在大多数情况下，一个开发人员会压缩一个错误/任务，因此允许将损坏的代码检查到源代码管理中。

一旦代码处于在开发分支上稳定的状态，就完成了一个基础调整，将代码从要集成的分支中拖入。一旦测试了合并，就只是将代码提交给集成分支的一种情况-由于您已经在分支上完成了合并，因此不需要合并。

这样，您可以避免开发人员担心提交已损坏的代码的问题，并且可以开始应用社交策略，使之在晚上离开办公室之前签入代码变得超级容易接受-既安全又好用。

在这种特殊情况下，请打电话给家里的人，要明确表示您不怀疑他生病了，但是您需要让其他人继续他的工作，并询问最新的资料在哪里以及处于什么状态。

然后，您需要考虑从这里做什么。如果问题是人们很少进行检入，请考虑使用分布式源代码控制系统，该系统可以使人们在分支机构中工作而不会互相干扰。

如果问题是您不喜欢开发人员在其计算机上具有多个工作区，请克服它。工作风格是个人的，只要他们能很好地与源存储库的规则配合工作，就应该基本上不使用他们的系统。我个人经常为不同的项目签出新副本，并且偶尔会清理一次。

如果问题是您不知道开发人员在做什么，那么问题是政治上的，而不是技术上的，您需要更改管理风格。请记住，开发人员是技术娴熟的人员，很少喜欢微管理，因此您必须委托。否则，您将把最熟练的人员推开。

因此，我建议鼓励使用更好的方法来使用公共源存储库-说人们在分支机构中工作很好，并且只要他们每天将其本地副本同步到主存储库，就可以让他们频繁地提交（因为他们将始终在分支机构中进行开发工作，而不会影响其他部门）。

那么如何处理这种情况呢？

您可以使用支持个人不稳定分支并维护频繁提交的源代码控制系统来解决此问题。解决了整个问题后，不必提交。只要您从源代码管理中受益，它就应该出现。一天的结束是应该进行提交的多个时间点之一，这样您就可以查看所做的更改，将其备份并向您自己或他人解释。

还是您要求开发人员遵守这方面的标准-使用特定目录，命名标准，Wiki上的注释或其他内容？

我们有一个庞大的环境配置文档，它表示约定，而不是标准。标准适用于生产代码和环境。但是，我们已经开发了许多开发工具来支持这些约定，并且大多数开发人员并未花费任何精力来反抗这一趋势。