同事重命名了我所有的查询[关闭]

我不知道我是否应该很生气或什么。我单手为大型数据库构建了300多个查询，并制定了命名约定，以便以后找到它们。我办公室里没有其他人甚至不知道如何建立查询，但是昨天我来找他们都被重命名了。我现在很难找到事情，并且试图弄清楚该怎么做。

我和负责人交谈，她只是轻描淡写了整个事情。她说她重命名了它们，以便可以更轻松地找到它们。不幸的是，我是唯一一个知道如何构建，编辑和维护它们的人，而她找到它们的唯一原因就是测试查询。新的命名约定根本没有意义，我觉得我们在开发过程中倒退了一步。

我想找出的是：

1）我反应过度了吗？

2）处理此问题的最佳方法是什么？我不愿意向老板提起这件事，但是在昨天与同事交谈之后，我已经可以告诉她感觉自己做错了什么。

1. 并非如此-这是一件令人难以置信的事。

2. 您已经与她交谈过，但我们没有，但似乎您有权利从备份中还原以前的命名约定，或者如果它们在源代码管理中，则将它们还原。如果这样做，请通知您的老板和同事，并提供您的理由（您无法维持自己的工作）。

您想要做的最后一件事是在此问题上来回走动，尽管如此，因为情况似乎很艰难，但要处理它，但至少应记录在案，以防它成为不尊重行为的一部分。

您为什么不像成年人那样简单地处理它：毫无争议地坐下来，并提出一个命名方案的利弊清单，就其中一项达成共识，并通过撰写简短的描述文件使其正式化。对她的输入引起真正的兴趣，使她感到（并且被）参与。

如果这主要是一个品味问题，并且如果她是绝对必须按照自己的方式做事的那种人，那么只需庆幸您是个大个子，就放手吧。生活太短了，无法举行命名方案的小便大赛。

问题是命名方案还是您觉得自己没有得到尊重？如果是这样，也许您可​​以继续工作。如果您觉得这不值得，那您为什么还要关心她的想法呢？:)另一个选择可能是她真的觉得这没什么大不了的，如果您很好地解释自己在找东西方面遇到麻烦，也许您可​​以改回来。

1. 数据库设计包括权限（GRANT和REVOKE）。
2. 测试包括测试权限。
3. 相对而言，很少有人应该有权重命名数据库对象。
4. 您的同事不是少数几个。

“新的命名约定根本没有任何意义”听起来像是以下情况之一：

1. 她对他们应用了一些公司准则。这些通常用于确保代码至少一致，并且在最佳情况下可以帮助外围事物（例如小型自定义脚本）轻松找到代码。在这种情况下，您需要了解该规范以及为什么在您的情况下该规范“没有意义”。如果您仍然认为让所有开发人员保持原样是更好的做法，请向他们解释为什么您的方法确切地是优越的，并询问您是否可以更改规范（如果他们同意是更好的，也许可以）或在您的情况下放弃它（从长远来看不太可能且凌乱）。
2. 她当场发明了自己的标准并将其应用。如果她是新手，这更有可能，她应该解释自己的理由。您可能会学到一些东西，并且/或者如果您随后解释自己的理由，她可能会学到一些东西。

重要的一点是，它不是您的（单个）代码，如果它属于整个组并且将被整个组修改的话。对代码的任何批评都不应以编写代码的人为中心。

我和负责人交谈，她只是轻描淡写了整个事情。

然后，我毫不掩饰地告诉您：

回滚更改。

发动这场战争。您的经理应支持您并巩固您的权威。

1）不，您没有反应过度。当您问他们为什么时，有人不告诉您就更改了您的工作，并且将其清除了。那是极度不尊重和粗鲁的恕我直言。

2）您是官方DBA，还是至少是该DB的管理员？如果是这样，请改回名称，并写出有关操作方式的约定文档。另外，编写一个“用户指南”样式的文档，这样，如果有人必须进入数据库并找到可以找到的东西。

我会把这个发送给小组，不要用任何手指指着，并提供有益的提示，您很乐意坐下并带领人们逐步了解该结构的某些细微差别。

如果不是，则以团队为单位提出约定，并以团队为单位遵循约定。

附带一提，对于必须测试某些东西才能更改300多个查询名称的人来说，这似乎是幼稚的。她浪费了多少时间来做这些事情，只是为了找到东西？她不仅去寻求别人帮助，还浪费了时间，您的时间以及公司的时间。更不用说代码在她这样做时可能坏了，因此也浪费了另一个团队成员的时间。

如果我是你，我会等到你冷静下来再尝试与她交谈。如果那行不通，那就去找老板。这种牛仔般的心态最终将使整个团队陷入困境。

在数据库中随机重命名很容易导致生产环境崩溃。如果这些过程在代码中的某处被引用，则可能会导致严重的后果。您可以回滚，但是如果这样的测试人员真的不知道她在做什么，那么看到该测试人员对生产进行一些更改就没有那么远了。那可能意味着失去业务，这就是为什么您应该尝试为开发人员和测试人员实施单独的用户角色。我们与测试人员一起做，效果很好。测试人员通常会喜欢它，因为他们不必担心会破坏实时数据。

它似乎没有在其他地方涉及到，但是放在公共场所的任何源（例如查询）都应该在版本控制系统下。

然后，如果同事更改了您的命名方案，则可以轻松地恢复到您的工作方案（并查看他们的更改；如果有必要，还可以恢复到原来的状态）。您还可以将更改绑定到特定用户，这样您就可以看到谁弄乱了事情。

不要在嘴里看着礼物马。

首先，集体代码所有权-他们不应该是“您的”。

其次，如果他们已重命名，请询问有关新命名方案的理由。他们要么在使用查询-在这种情况下就是他们的要求；或者这是他们开始为您提供一些维护方面的帮助的第一步。

如果每个人都认为他们是“您的”，那么您将永远不会摆脱他们，而继续追求新事物。

我不知道是否有人问过，但是正式版本是哪个命名约定？如果您的版本是官方的，那么我会从角度说明这个问题。因此，与其说“ Person X回滚了我的所有更改”，不如说“ Person X进行了与官方命名约定相反的更改”。如果没有正式的约定，那么我建议让她知道您不欣赏未经您事先咨询而做出的更改。

无论哪种情况，我都认为发动“战争”不是答案。即使您赢了，您也输了。

这是令人震惊的行为。听起来她不后悔，因此请带走给您的老板，并提出理由撤销她的访问权限，直到可以说服她不要胡闹。

如果老板不懂技术，请用他们能理解的术语来解释。想象一下在邮局开始工作，在邮局将邮递整理到鸽子洞中，准备送达。您可以单方面决定先对鸽子孔进行分类，然后再按姓氏进行排序，而不是按当前部门分类，再对地板进行分类。短期来看，这可能会使您的生活更轻松，但您将被其他邮局工作人员谋杀。

这是不礼貌的。我会很生气。

除了设置权限以阻止随机人对其进行更改之外，您还应该解释一下，因为测试功能是她的工作，如果随机人对代码进行更改，则不能保证可靠性。

就像每个人都说的那样，即使只是出于对您的尊重，她也不应该这样做，因为您是这些查询的创建者维护者。

话虽如此，我没有看到任何人提到这样一个事实，即如果她确实重命名了您的查询，那是因为她无法理解您的命名约定。
因此，通过记录您的命名约定并确保同事可以访问文档并找到他们需要的内容，可以轻松解决此问题。

您还必须谨慎并考虑其他人如何查找和使用您的查询：如果您的命名约定不允许他们有效地完成工作，那么您可能需要维护更详尽的查询列表，标签和商定的关键字，以便其他人可以找到他们想要的东西。

我认为这里的关键是，没有人可以孤立地工作，而避免彼此脚趾踩踏的最佳方法是就共同的基本规则进行沟通和达成共识。

我会以同样的方式回应-轻描淡写了您决定将所有内容还原的决定。只需还原她的更改，并向您的同事写一封非常简短的电子邮件即可：

“暂时恢复了更改rXXXX，因为不了解它的命名约定。不过感谢您尝试。:)”

是的，你反应过度。

有一种叫做版本控制的东西，除其他外，当他们弄乱您的东西时，它通常不必击败$＃！7。只需回滚到以前的版本并锁定文件，即可让她处理愤怒。这将为您提供一个机会，您可以解释说，对具有其他人的依赖项的代码进行充分的更改而没有充分的理由并且无需先提出要求，这不仅是错误的，极其不切实际的，而且实际上是一种罪过。

当然，这假定您的命名约定比她的命名约定好，并且您实际上可以使用可靠的客观参数来备份此决定，如果不是这种情况，最明智的做法就是尽快处理更改并开始更改代码，下次尝试提出更好的命名约定。

不要把它带给老板，成熟的解决方法是直接与您的同事一起，之后您必须与她一起工作，以免它愚蠢地破坏了关系，从而容易解决争吵。