如何说服您的开发人员同事编写简短的方法？

Question

长方法是邪恶的，有几个原因：

• 他们很难理解
• 他们很难改变
• 它们很难重复使用
• 它们很难测试
• 他们的凝聚力低
• 它们可能具有高耦合性
• 它们往往过于复杂

如何说服您的开发人员同事编写简短的方法？（禁止携带武器=）

问题来自 敏捷开发者

Answer 1

您列出了缺点。尝试列出通过使用简短方法您将获得的收益。具体例子。然后再尝试说服他。

Answer 2

请他为这些方法编写单元测试。

Answer 3

这取决于您对“短”和“长”的定义。

当我听到有人说“写短方法”时，我立即反应很糟糕，因为我遇到过很多认为理想的方法是两行长的人写的意大利面条：一行执行尽可能小的工作单元，然后一行调用另一个方法。（你说长方法是邪恶的，因为“它们很难理解”？尝试走进一个项目，其中每个琐碎的操作都会生成 50 个方法深度的调用堆栈，并尝试找出这 50 层中的哪一层是您需要更改的......）

另一方面，如果“短”的意思是“独立且仅限于单一概念功能”，那么我完全赞成。但请记住，这不能简单地通过代码行来衡量。

而且，正如泰多克指出的那样，用蜂蜜比用醋更能捕捉到苍蝇。尝试告诉他们为什么你的方法是好的，而不是为什么他们的方法不好。如果你可以做到这一点而不对他们或他们的实践进行任何公开的比较或参考（除非他们特别询问你的想法与他们正在做的事情有何关系），那么效果会更好。

Answer 4

我从某处读到这句话：

编写你的代码，就好像维护它的人是一个暴力精神病患者，他知道你住在哪里。

Answer 5

根据我的经验，在这些情况下说服同行的最好方法就是通过例子。只需找机会向他们展示您的代码并与他们讨论短函数与短函数的好处。长函数。最终他们会自发地意识到什么是更好的，而不需要让他们觉得自己是“坏”程序员。

Answer 6

代码审查！

我建议您尝试进行一些代码审查。这样，您就可以举办一个关于最佳实践以及您公司所遵循的格式的小型研讨会。这增加了这样的背景：短方法是一种使代码更具可读性、更容易理解并且符合 SRP 的方法。

Answer 7

如果你试图解释好的设计，但人们就是不理解，或者只是拒绝理解，那么就停止尝试。这不值得付出努力。你所得到的只是给自己带来不好的名声。有些人只是绝望。

基本上，归根结底是有些程序员不适合开发。他们可以理解已经编写的代码，但无法自己创建代码。

这些人应该被引导到支持角色，但不应该允许他们从事任何新的工作。支持是查看大量不同代码的好地方，所以也许几年后他们会看到良好设计的好处。

我确实喜欢其他人建议的代码审查的想法。这些马虎的程序员不仅应该审查自己的代码，还应该参与对好的代码的审查。这将使他们有机会了解什么是好的代码。可能他们只是从未见过好的代码。

Answer 8

为了扩展 rvanider 的答案，对代码执行圈复杂度分析确实引起了人们对大方法问题的关注；当我离开时，让人们改变的工作仍在进行中（对大方法的推动力太大）。

转折点是当我们开始将圈复杂度与错误数据库联系起来时。超过 20 个非工厂的 CC 保证在错误数据库中拥有多个条目，并且这些错误通常具有“血统”（修复错误 A 导致错误 B；修复Bug B引起的Bug C；ETC）。实际上，我们有超过 100 个（最多 275 个）的 3 个 CC，这些方法占我们 bug 数据库中案例的 40%——“你知道，也许 5000 行函数并不是一个好主意……”

这在我刚开始领导的项目中表现得更加明显。我们的目标是保持 CC 尽可能低（97% 低于 10），最终结果是我基本上停止支持这个产品，因为我的 20 个错误不值得修复。

由于方法较短（这可能是您必须解决的一个论点），因此不会出现无错误的软件，但是错误修复非常快，并且当您使用短方法时通常不会产生副作用，简洁的方法。

尽管编写单元测试可能会解决长方法的问题，但您的公司可能不使用单元测试。言辞只能到此为止，对于固步自封的开发者来说很少起作用。向他们展示这些方法如何创建更多工作和有缺陷的软件的数字。

Answer 9

在函数长度和简单性之间找到正确的结合可能很复杂。尝试应用一个指标，例如 圈复杂度 展示以当前形式维护代码的困难。没有什么比基于分支和决策计数等测试因素的非个人衡量更好的了。

Answer 10

不确定这句伟大的引言来自哪里，但是：

“调试的难度是最初编写代码的两倍。因此，如果你尽可能巧妙地编写代码，那么根据定义，你就不够聪明来调试它”

Answer 11

强迫他阅读 Steve McConnell 的《Code Complete》。假设每个优秀的开发人员都必须阅读本文。

Answer 12

让他喝醉？:-)

这个答案的重点在于这个问题：“为什么我一直在写短函数，而当我不写时我会讨厌自己？”

原因是我很难理解复杂的代码，比如长函数、维护和操作大量状态的代码，或者诸如此类的代码。许多年前，我注意到有相当多的人在处理这种复杂性方面比我做得更好。具有讽刺意味的是，可能正因为如此，我往往比他们中的许多人成为更好的程序员：我自己的局限性迫使我面对并清理此类代码。

很抱歉我无法在这里提供真正的答案，但这也许可以提供一些见解来帮助我们找到答案。

Answer 13

强迫他们阅读《干净的代码》一书，还有很多其他书，但这本是新的、好的且易于阅读的。

Answer 14

要求他们为复杂的代码编写单元测试是一个很好的途径。此人需要亲自了解在执行维护或分析时复杂性带来的债务。

我总是问我的团队的问题是：“现在是晚上 11 点，你必须阅读这段代码 - 可以吗？压力下你懂吗？你能通过电话，无需远程登录，引导他们到可以修复错误的部分吗？”如果答案是否定的，接下来的问题是“你能隔离一些复杂性吗？”

如果你得到争论作为回报，那就是失败的原因。那就扔点东西吧。

Answer 15

我会给他们 100 行代码，全部属于一种方法，然后另外 100 行代码分为几种方法，并要求他们写下每种方法的解释。

计算写这两个段落需要多长时间，然后向他们展示结果。

...确保选择需要两倍或三倍时间的代码才能了解它是否全部都在一种方法下 - Main() -

没有什么比通过实例学习更好的了。

Answer 16

短或长是可以有不同解释的术语。一个简短的是 2 行方法，而其他人会认为代码不超过 100 行的方法相当短。我认为最好声明单个方法不应同时执行多于一件事，这意味着它只应承担一项职责。也许您可以让您的开发人员同事阅读一些有关如何实践 SOLID 原则的内容。

Answer 17

我通常会向他们展示具有编写良好方法的旧项目。然后，我将逐步介绍这些方法，同时解释我们以这种方式开发它们的原因。

希望当他们放眼大局时，能够理解这背后的原因。

附：此外，此练习可以结合使用，作为旧项目的小型知识转移。

Answer 18

• 向他展示测试简短方法是多么容易。证明编写简短的方法将使他更容易、更快地为他的方法编写测试（他 是 测试这些方法，对吧？）

• 当你检查他的代码时提出它。“这个方法相当长、复杂，而且似乎在做四件不同的事情。提取方法 这里, 这里, ， 和 这里."

Answer 19

长方法通常意味着对象模型有缺陷，即一个班级有太多的责任。很可能您不希望在同一个类中只需要更多的功能（每个功能都较短），而是将这些职责正确分配给不同的类。

Answer 20

教猪唱歌是没有用的。它既浪费你的时间，又惹恼了猪。

只是比某人更出色。

当需要修复 5000 行例程中的错误时，您将拥有一个 10 行例程和一个 4990 行例程。慢慢地这样做，没有人会注意到突然的变化，除了事情开始变得更好并且慢慢地大泥球蒸发。

Answer 21

您可能想告诉他们他的记忆力可能非常好，但您没有。有些人能够比其他人处理更长的方法。如果你们俩都必须能够维护代码，那么只有在方法较小的情况下才能做到这一点。

只有在他没有优越感的情况下才这样做

[编辑] 为什么这会收集负分？

Answer 22

你可以开始重构 每一个方法 他们写入了多种方法，即使他们目前正在研究这些方法。在你的日程中分配额外的时间来“重构其他人的方法以使代码可维护”。按照你认为应该做的方式去做，并且 - 这是教育部分 - 当他们抱怨时，告诉他们如果他们第一次就做对了，你就不必重构方法。这样，你的老板就会知道你必须纠正别人的懒惰，而你的同事也会知道他们应该做出改变。

这至少是一些理论。