承包商改变代码风格

Question

我目前支持的工作应用程序最初是由一个四人小组编写的，但现在已经简化为我。我们最近有一个承包商在看到一些性能问题，而我却忙于其他事情。

虽然承包商似乎在表现方面做得很好，但他们也经历了大量的代码，取代了原有的风格，并取代了他们的个人喜好。

不幸的是，我们没有编码标准文档，只是遵守c＃一般规则的一般规则。

作为他们所做的一个例子，它包括：

 
• 几乎删除了'var'关键字的所有用途
 
• 在if语句和单行的任何地方，他们都添加了花括号
 
• 删除大部分lambda并将其替换为更详细的代码
 
• 更改方法签名，以便每个参数都在一行而不是一行

我们还实施了TDD政策，但测试覆盖范围非常低，特别是针对性能特定部分的测试覆盖范围非常低，只留下很少的文档记录，因为他们的签名评论不是特别有用，而且实际的功能变化在“调整”中消失了。

我如何与承包商讨论此事？显然，由于他们没有责任支持该项目，因此改变它并没有太大的动力，他们似乎并不特别容易接受改变。

或者我应该在合同的短期内忍受它，然后将所有内容更改回我们之前使用的代码格式？

制作社区wiki'cos在这里可能没有一个正确答案。

Answer 1

  

任何带有if语句和单行的地方，他们都添加了花括号

这一个也是唯一一个可能是有益的。

  

  
• 几乎删除了'var'关键字的所有用途
  
• 删除大部分lambda并将其替换为更详细的代码
  
• 更改方法签名，以便每个参数都在一行而不是一行
  

这些改变没什么意义。

告诉他他没有授权重新编码。你不会为这些活动浪费的时间付出代价，他们将不得不用自己的时间把东西放回去。这应该提供一个更新。

这些事情应该提前讨论。您应该清楚地说明允许哪些活动以及哪些活动不允许。不久前，还有另一个类似的问题，一个承包商将他的首字母全部放在包括数据库实体在内的代码上。这是一种不正常的自我推销，其他人的代码中没有任何地方。

P.S。也许通过做所有这些事情，你的承包商可能会人为地创造额外的工作量来为你付出更多的时间。

Answer 2

我是承包商（有时候），如果我这样做的话，我希望能以极快的速度展示门，不付款。说真的，这个人是由你雇用的，应该完全按照他的要求去做，不多也不少。并且不要担心“好” - 承包商不要期望来自敌人。

Answer 3

  

我如何与承包商讨论此事？

礼貌地解释为什么要尽量减少对源代码的更改。

或者，在登记前对代码进行代码检查：并且不允许签入您不理解/不希望/未经过测试的更改。

Answer 4

实施FxCop - 这应该是你的第一道防线。此外，如果你使用源代码控制（如果你没有实现一个ASAP），请确保使用dev标签（仅构建在已为标签标记的文件上），并且不授予他在标签上移动标签的权利。文件。通过这种方式，您可以仔细检查他的更改，并拒绝标记他的代码，直到它符合您的标准。无论他的代码是什么都不会进入QA，直到您将dev标签移动到相关修订版，所以他在那里几乎是你的怜悯。请注意，有些商店不会为他们的沙箱构建使用单个标签，他们甚至喜欢将新标签应用到沙箱中，因此您可能也倾向于这样做。

Answer 5

现在问题已经发生了，正如另一个人说的那样，这是一种毫无道理的浪费你的钱，而且这是完全不礼貌的（正如花括号那样正确）。

当然，为了帮助预防未来的问题，并且可能有助于解决这个问题，我建议你设置一个stylecop实施 - 至少他们不能不知道什么时候他们打破你的规则。

Answer 6

我想我们都知道看到编码的诱惑，我们认为“不是我做的方式”。但我们抵制它。

我会先与你的老板聊聊，然后再接受它。但首先想到的是，除非你明确要求承包商完成这项工作，否则他不会做他所聘请的事情，不管他认为他可能会增加任何好处。所以需要对此进行讨论。

接下来要想到的是，无论他们有多么善意或善意，在不与代码所有者讨论的情况下进行批量更改的人都是坏消息。他们会惹恼人们，或者更糟糕地引入你必须清理的错误和不可预见的行为。他需要直截了当地说，在未经许可的情况下做这类事情是不可接受的。

当我看到其他代码中我不喜欢的东西，这些代码非常严重以至于需要注意时，我先与代码所有者联系。即使有明显的错误，它 他们的代码和他们关于清理它的决定，而不是我的。

Answer 7

正如其他人所说，这些变化仅仅是为了编码风格。如果他在那里提高绩效，他就是在浪费时间来应对这些变化。如果他不能引用这些改变将如何改善表现，那么他的强迫症就是在提高账单。

我想说，“我感谢您对编码风格的更改，但让我们专注于导致速度减慢的代码区域的非样式更改。”

Answer 8

如果承包商在未经授权的情况下批量重新格式化代码，我会给他一次而且只有一次更改，以便按照自己的方式 - 并在他自己的时间。“

除了其他人提出的有效点之外，还要考虑这导致的版本控制噩梦。这里添加了几行代码，这里改变了几行，你现在在源代码管理数据库中有了这个“裂痕”，所以在这个承包商的“改进”之前和之后版本之间的任何比较都将毫无意义。

让承包商退出他的所有更改。今天。在他自己的时间。

Answer 9

我的经历非常普遍，人们无法拒绝做出“改进”，突然间你发现你已经为你不想要的东西付了账。有时候我确信这是为了获得更多付费工作而刻意完成的，但大多数情况下我认为这是一个开发人员进行侧面跟踪而无法处理留下“错误”代码的问题。 这可能需要一些战斗，但你基本上必须重申“不要改变任何你不被要求工作的东西”。根据他的个性，你可能只需要好好问一下，或者让某人更高强迫他。

Answer 10

首先，正如其他人所说的那样。你付账单了。他不是雇员。他的工作是做你要求他做的事，只做你要求他做的事，否则你可以告诉他门。永远记住这一点。你在开船，而不是他。你可以尝试不付钱给他，但如果你有合法的合同就很难做到，并且没有任何关于按原样离开代码的内容。但是，你可以随时让他离开。

其次，如果你不能让他停下来并且你不能摆脱他，你可以告诉他，如果他打算改变风格，那么他应该在一次检查中做所有的风格改变-in绝对没有代码更改。这允许您从可以扩展的基本代码集向前移动以查看代码更改。

第三，让他解释他所做出的改变的理由。删除var没有性能优势。

第四，这可能会吸引很多，但是你总是使用ReSharper将代码恢复到你接受的风格之后。这是更多的工作，你仍然有borked差异，但哦，哦。 lambdas更难，这就是你应该真正了解他的情况。

第五，要把你的观点推回原点，强迫他退出他所做的每一个改变，只重新实现代码更改，而不是样式更改。当他无法自己解决时，应该睁开眼睛看他所造成的混乱。

最后，你可能只是咬紧牙关并付钱给他重新开始。是的，它很糟糕，但是因为你犯了不监管他的错误，没有事先说出你想要的东西，以及他不允许做什么......你将支付最终的价格。您既可以付钱给他，也可以付钱让别人去做，付钱给你，或者和它一起生活（并支付borked差异的价格）。无论如何削减它，都会花费你的钱。

Answer 11

好吧，闻起来就像一个解决方案广泛的代码重新格式化给我，可以通过像Resharper这样的工具中的设置自动/强制执行。我认为这是非常不礼貌的，并会要求他不要按“根据我的个人品味重新格式化所有代码”按钮。

Answer 12

为了避免首先出现这种情况，请引入代码审查，特别是对于任何可能不了解您的标准的新开发人员。

我非常喜欢使用git，功能分支和支持拉取请求的服务（github或bitbucket）。 TFS并不是真的能胜任，但幸运的是Visual Studio现在支持git。在合并到master之前进行代码检查可确保它不会出现问题。如果你是偏执狂，你甚至不需要给承包商写入你的主存储库的访问权。

Answer 13

替代观点：

你做了两个陈述：“虽然承包商似乎在表现上做得很好”并且“他们也经历了大量的代码，取代了先前存在的风格和他们的个人偏好。”

这提出了许多问题，例如：每当您能够在短时间内“闯入”承包商并获得性能增强时。这表明首先应用程序中存在非常严重的缺陷。无论何时您需要引入承包商来“修复性能”，这都是代码编写得很糟糕或需要高端专业知识的非常复杂问题的标志。

下一篇：当你抱怨他们已经改变了代码风格，即使你没有任何陈述的代码风格，你只是在毫无意义地争论你的mojo比别人的mojo更好。也许你应该问这个人为什么他们做了一些看似语法化的修改，以便你有一个完整的画面。

我正在查看这篇文章的长篇单侧答案，并想知道对方发生了什么。人们将情绪从中消除并客观地看待它。令人惊讶的是，有多少人会通过一个漂亮的算法解决方案来解决一个复杂的问题只是为了注意到变量命名约定已经从驼峰案例改为pascal案例。我通常通过发现无关紧要的缺陷，将这种反应归结为自我价值的理由。

我要问的关键问题是：新格式化的代码是否使应用程序的可读性降低。如果你有预算限制，为什么你没有明确表示你想要非常具体的修复，没有别的。如果你想保持一种特定的编码风格，为什么不明确说明呢？