我如何说服我的团队使用较小的类/方法？

免责声明：我是新来者（这是我工作的第三天），我的大多数队友比我更有经验。

查看代码时，我会看到一些代码气味和不良的工程实践，例如：

• 命名准则有些不一致
• 可能时属性未标记为只读
• 大型类-我注意到一个实用程序类，其中包含数百个扩展方法（对于许多类型）。它超过2500行！
• 大型方法-我正在尝试重构一种150行长的方法。

后两者似乎是一个真正的问题。我想说服队友使用较小的类和方法。但是我应该这样做吗？如果是，那怎么办？

我的团队从主要团队（我们是卫星团队）中获得了导师。我应该先去找他吗？

更新：由于一些答复询问该项目，因此请知道这是一个有效的项目。恕我直言，这么大的类/方法总是不好的。

无论如何，我永远不想惹恼我的团队。这就是为什么我问-我应该这样做，如果是的话，那么我该如何轻轻地做到这一点？

更新：我决定根据公认的答案做某事：因为我是新来者，所以我以“新鲜的眼睛”看到一切，我会记下我发现的所有代码气味（位置，为什么不好，我们怎么做）更好，...），但此刻，我只是努力争取团队的尊重：写出“更好的代码”，认识人们，知道我们为什么这样做...在适当的时候，我会尝试向我的团队询问一些新的代码策略（命名准则，较小的类，较小的方法等），并在可能的情况下重构一些旧代码。它应该工作，恕我直言。

谢谢。

您可以从新的角度查看代码。做笔记以记录发现的不良做法。然后，当您与团队建立关系时，请在适当的时候抽出笔记，例如在进行重构的时候。

史蒂夫·麦康奈尔（Steve McConnell）编写的Code Complete具有大量关于您所谈论的主题的良好统计数据。我记不清所有数字，但是他谈到了随着更长的方法/类，bug的数量如何增加，调试花费的时间等等。

您可以购买这本书的副本，并向您的同伴展示一些研究内容……统计数据（尽管它们总是在说谎）倾向于说服人们。

免责声明：我是新来者（这是我工作的第三天），我团队中的大多数人都比我更有经验。

您可能想放慢脚步，倾听您的意见，并向您的团队学习，然后再提出过多的建议。也许有或没有很好的理由说明代码的结构是正确的，但是花时间聆听和学习的任何一种方法都只会有所帮助。

之后，您可能会提出的任何建议都将得到更积极的对待，并且会遇到较少的阻力。

如果您首先赢得同事的尊重，或者至少不失去尊重，您成功引入变革的机会就会大大提高。

怎么样了？“测量两次，切一次。。”是这样的。

除非您是出于彻底检查团队如何编写代码的特定意图而雇用的，否则您可能希望减轻对大修的热情。大多数有效的代码都能工作是有原因的：)不管它多么垃圾，有时进行大刀阔斧的检修，使那些令人讨厌的极端情况变得更加难看。

我认为编写较小代码的最简单方法是要求开发人员专注于单元测试。没有什么比要求测试简洁的代码了。当开发人员突然知道必须为所有数据编写测试时，它们突然对全局数据结构产生厌恶，将太多的对象传递到太多的层次，这真是令人惊讶。

我不是TDD的忠实拥护者，但我确实喜欢它迫使开发人员考虑如何编写测试的事实。而这往往就是为什么代码是更好的，而不是一些神奇的有关实际有测试。（尽管稍后进行更改时，这一确定会派上用场。）

祝你好运。

您不应该说服您的团队。作为新手，您将不会受到重视-因此会浪费时间。

相反，请继续自己编写紧凑简洁的代码。然后希望，经过一段时间和一些代码审查，一些队友可能会开始模仿您的风格。

如果没有，您的工作效率仍将更高，而您的辛勤工作最终将使您处于一个更高的位置，在这里您可以开始执行其中一些规则。

是的，一定要向所有人展示《代码完整》中的内容。

这里有一些技巧：

• 了解团队的当前状态和历史-听起来他们有一位指导者，该指导者有多少影响力？另外，导师有多新？有很长时间没有导师了吗？问题代码何时产生？批评当前团队的成员与批评一些实际上没有人记得的旧代码可能大不相同。

• 一次做一件事-不要在团队会议上将炸弹扔掉。首先从您的特定角度提出一些试探性问题。例如-“嘿，作为新手，我注意到某些实用程序类确实很大，这是有原因的吗？”

• 建议宝宝的脚步-几乎不可能立即进行全面检修，因此请弄清楚一些开始的步骤，以防万一每个人都认为这是一个好计划。

• 建议未来的预防机制-例如，该团队可以同意一个目标，即该目标永远不会增加到前几个最大的类别中，但是会在需要进一步发展时重构。

• 听取有关风险的担忧。如果这确实是传统代码，则可能存在足够多的未知数和依赖项，因此重构存在极大的风险。这可能不是避免重构的原因，但可能意味着您需要一些更好的测试策略或其他降低风险的方法，才能进行真正的返工。

• 要注意肢体语言，然后慢慢走。您在一个没有很多经验的代码库中提出了一个问题。您现在拥有一个新的窗口，您可以在其中询问一些幼稚的问题并获得有用的答案，并且可以使用这些问题来探究团队以考虑他们自己的设计选择。但这是双向的-作为新手，您还没有很多“信条”，所以要慢一点，要注意闭合的脸或姿势。如果人们开始停摆，请提出一种方法来延迟任何决定，并寻找赢得决策的方法。

我可以说作为一名经理和团队成员，对于New Guy Insights感到很高兴。我没有接受新成员给我的每条建设性评论，但如果批评被表达为诚实的关注和好奇心，而不是作为演讲，我通常愿意听。当新人可以提供洞察力，然后退后一步处理任何事情时，对新人的尊重就消失了。当您听到并接受您的决定时，很容易感到良好；当团队告诉您“不”时，就很难。您可能仍然是对的，诀窍是弄清楚下一步该怎么做...通常等待一点，在这些情况下，寻找更多信息是一个不错的下一步。

我如何说服我的团队使用较小的类/方法？

别。

给自己购买Resharper许可证并以身作则。[非常注重“ 提取方法 ”的重构。]

随着时间的流逝，其他人应该开始欣赏您的可读性更高的代码，并被说服这样做。*

• 是的-有可能不会被说服。但这仍然是您最好的选择。

IMO- 试图说服您的队友成为更好的程序员是不值得的，请读' Code Complete '，然后关注@Uncle Bob。的SOLID原则，如果尚未被说服，就可以成为更好的程序员。

切记：您不能使用逻辑来使某人脱离一个他们不使用逻辑进入第一位置的立场。

这似乎更多是管理问题，而不是技术问题。您所说的都是正确的，您的团队真正需要的是一个优秀的架构师，他可以确保每个人都适应一个设计模式并执行它，团队需要不断地，定期地重构代码。

但是，还有另一个“您将不需要它”的原则，如果存在的内容在相当长的时间内有效，无论它多么丑陋，更改它始终不是一个好主意。相反，如果您的团队需要重建整个事物或重建其中的一部分，请在执行编码之前积累不良做法和问题的文档。

一些团队不对代码进行任何形式的质量控制，因为他们不知道正确的工具。有很多工具可以帮助团队更好地编写代码。

Visual Studio具有“代码分析”功能，可能有助于命名约定。

还可以使用代码度量，例如圈复杂度。这有助于指出过于复杂的类和方法。

保留记录也是一个好主意。如果团队成员只是口头表达需要做的事情，那么人们注定会忘记。人类有非常脆弱的记忆！=）

我不会对此大声喧......程序员的开发团队就像他自己的家人...如果您指出错误，人们可能会生您的气。这种文化变化不仅需要大量的编码，而且还需要与人类保持精致的联系。

作为一名经理，我只想补充一点，我希望我的团队第一次编写好的代码。代码审查，TDD等。但是，一旦它投入生产并成功运行，您就必须提出充分的理由让我们重新使用它。

我的确遵循Bob叔叔的建议，总是留下比您发现的更好的代码。因此，如果我们有要修复的错误或小的改进，我希望我们那时可以进行一些清理。

但是，因为它代表，企业真正观看它的钱。我必须向他们说明，重构对他们有利，足以使他们腾出时间和资源。仅仅不喜欢代码的外观是不够的。

因此，如果它可行，那么您可能会讨厌它，您可能不得不放弃它。

现在，新代码有所不同。那应该是好的代码。

150行的方法...我见过10.000行代码的方法。

您可以通过外部工具解决其中两个问题：

• 命名准则有些不一致
• 在可能的情况下，属性未标记为只读

在C＃中，Resharper可以检查这两个问题。不符合您的准则的名称将被标记为错误。未标记为只读的属性也会显示为错误。FxCop也可能会有所帮助。

由于其重构，这些工具还可以帮助将巨大的方法拆分为多个较小的方法。

我不知道，如果大型类使用命名方法构造得很好，那么它们总是那么糟糕。我使用Eclipse作为IDE，因此它具有一个称为“概述”视图的东西，这是所有IDE都具有不同名称的东西，很可能提供了名称和指向类中每个方法的链接，您可以按字母顺序对其进行排序，等等。当使用它轻松导航一个大类时，它的缺点是拥有非常长的方法将是不好的，我认为这是因为，除非您碰巧真正熟悉它，否则在该方法中很难进行智能导航。我不是在倡导长类，但我认为它们在某些情况下是可管理的，不必分解为多个类。

与您的一些团队成员一起讨论这个话题，并就方法的规模征询他们的意见。您可能会惊讶地发现他们同意您的看法。您所看到的可能是先前不良做法的结果，以前的开发人员不再在公司工作，或者那部分工作很匆忙，现在他们已经雇用了一些有时间的人来重构它；）

你还是新人。通过承担具有挑战性的任务并迅速且无错误地完成任务来建立声誉。如果您在赢得同龄人的尊重之前尝试进行一些改变，那么您可能会很难接受（可能会疏远您的同事）。

如果您能找到在自己的工作中引入更好的编码习惯的方法，从而有效地证明它们如何减少开发时间并得出更可靠的解决方案，那么您甚至可能会邀请他们来了解如何实现这一目标。

除了所有其他出色的答案之外，也许您可​​以用一块石头杀死两只鸟，并进行一些代码清理，作为一个旨在对代码库有所了解的项目。您可以将其出售给您的团队/经理，以为您提供学习的机会，当他们的同事查看您的更改时，您会从他们的反馈中获得反馈，这将指导您以最佳方法解决设计不佳的问题。