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

Question

长方法在某些方面是邪恶的：

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

如何说服你的开发人员编写简短的方法？ （武器被禁止=）

来自agiledeveloper的问题

Answer 1

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

Answer 2

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

当我听到有人说“写简短的方法”时，我立刻反应得很厉害，因为我遇到了太多的意大利面条，他们认为理想的方法是两行长的：一行是做最小的工作单位用一行来调用另一种方法。 （你说长方法是邪恶的，因为“它们很难理解”？试着走进一个项目，在这个项目中，每个琐碎的动作产生一个50深度的调用堆栈，并试图弄清楚这50个层中哪一层是你需要改变的层...）

另一方面，如果，“短”，你的意思是“自足并限于一个单一的概念功能”，那么我就是为了它。但请记住，这不能仅通过代码行来衡量。

而且，正如tydok指出的那样，你用蜂蜜捕获的果蝇多于醋。试着告诉他们为什么你的方式很好，而不是为什么他们的方式很糟糕。如果你能做到这一点而不做任何明显的比较或参考或他们的做法（除非他们具体询问你的想法与他们正在做的事情有什么关系），它会更好地工作。

Answer 3

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

Answer 4

我从某处读到了这句话：

写下您的代码，好像必须维护它的人是一个暴力的心理，谁知道你住在哪里。

Answer 5

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

Answer 6

代码评论！

我建议您尝试进行一些代码审查。通过这种方式，您可以举办一些关于最佳实践的研讨会以及您的公司所遵循的格式。这增加了上下文，即短方法是一种使代码更易读，更易于理解并符合SRP的方法。

Answer 7

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

引爆点是我们开始将圈复杂度与bug数据库相关联的时候。一个超过20个不是工厂的CC被保证在bug数据库中有几个条目，并且这些bug经常有“血统”（修复Bug A导致Bug B;修复Bug B导致Bug C等）。我们实际上有三个CC超过100（最多275个），这些方法占我们的bug数据库中40％的情况 - “你知道，也许5000线功能不是一个好主意......” p>

在我开始的那个项目中，这一点更为明显。目标是保持CC尽可能低（97％低于10），最终结果是我基本上停止支持的产品，因为我有20个错误不值得修复。

由于方法简短，不会发生无错误的软件（这可能是你必须要解决的问题）但是修复错误非常快，并且在你工作时通常没有副作用用简短的方法。

虽然编写单元测试可能会解决长方法问题，但贵公司可能不会使用单元测试。修辞只是到目前为止，很少适用于那些陷入困境的开发者;向他们展示有关这些方法如何创造更多工作和错误软件的数据。

Answer 8

如果你试图解释好的设计并且人们只是没有得到它，或者只是拒绝接受它，那么就停止尝试。这不值得努力。你所能得到的只是对自己不好的代表。有些人只是无望。

基本上，它归结为一些程序员并没有被开发出来。他们可以理解已经编写的代码，但是他们无法自己创建代码。

这些人应该转向支持角色，但不应允许他们处理任何新事物。支持是一个看到许多不同代码的好地方，所以也许几年后他们会看到好设计的好处。

我喜欢其他人建议的代码评论的想法。这些草率的程序员不仅应该审查他们自己的代码，他们还应该参与好的代码审查。这将使他们有机会看到什么是好的代码。可能他们从未见过好的代码。

Answer 9

不确定这句好话来自哪里，但是：

“调试的难度是首先编写代码的两倍。因此，如果您尽可能巧妙地编写代码，那么根据定义，您不够聪明，无法对其进行调试”

Answer 10

在功能长度和简单性之间找到正确的组合可能很复杂。尝试应用Cyclomatic Complexity之类的指标来证明以当前形式维护代码的难度。没有什么比基于测试因素（如分支和决策计数）的非个人测量更胜一筹了。

Answer 11

强迫他阅读Steve McConnell编写的Code Complete。假设每个优秀的开发人员都必须阅读此内容。

Answer 12

我会在1种方法下给他们100行代码，然后在几种方法之间划分另外100行代码，并要求他们写下每种方法的解释。

编写两个段落然后向其显示结果所需的时间。

...确保选择需要两到三倍的代码来理解它是否都在一个方法下 - Main（） -

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

Answer 13

短或长是可以不同方式解释的术语。一个简短的是2行方法，而其他人会认为不超过100行代码的方法非常短。 我认为最好说一个方法不应该同时做多件事，这意味着它应该只有一个责任。 也许你可以让你的开发人员阅读有关如何练习SOLID原则的内容。

Answer 14

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

我总是问我的团队的问题是：“现在是晚上11点，你必须阅读这段代码 - 你能理解吗？你在压力下了解吗？你能通过电话，没有远程登录，引导他们前往他们可以修复错误吗？“如果答案是否定的，那么后续行动就是“你能否分离一些复杂性？”

如果你得到一个论据作为回报，这是一个失败的原因。然后扔东西。

Answer 15

强迫他们阅读“清洁代码”一书，还有很多其他的，但这一本是新的，好的，易读的。

Answer 16

让他喝醉？ ： - ）

这个答案的严肃点是“为什么我一直在写短篇小说，在我不这样做时讨厌自己？”这个问题。

原因是我很难理解复杂的代码，很长的功能，维护和操纵很多状态的东西，或者那种东西。多年前我注意到，有很多人在处理这种复杂性方面明显优于我。具有讽刺意味的是，这可能是因为我倾向于比其中许多人更好的程序员：我自己的限制迫使我面对并清理那种代码。

对不起，我不能在这里提供真正的答案，但也许这可以提供一些见解，帮助我们找到答案。

Answer 17

我通常会向他们展示那些写得很好的老项目。然后，我将逐步介绍这些方法，同时解释为什么我们以这种方式开发它们的原因。

希望从更大的角度来看，他们会理解背后的原因。

PS。此外，这项练习可以作为旧项目的小型知识转移使用。

Answer 18

• 告诉他测试短方法有多容易。证明编写简短的方法会让他更轻松，更快地为他的方法编写测试（他 测试这些方法，对吗？）

• 在查看代码时提出来。 “这种方法相当漫长，复杂，似乎做了四件不同的事情。提取方法这里，这里，这里。”< / p>

Answer 19

长方法通常意味着对象模型存在缺陷，即一个类有太多责任。有可能你不想在同一个班级中只有更多的功能，每个功能都更短，但是那些责任适当地分配给了不同的类。

Answer 20

没有教老猪唱歌。这会浪费你的时间并使猪烦恼。

胜过某人。

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

Answer 21

你可能想告诉他们他可能有一个非常好的记忆，但你没有。有些人能够处理比其他人更长的方法。如果您必须能够维护代码，则只有在方法较小时才能执行此操作。

只有在没有优势复合体的情况下才能这样做

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

Answer 22

你可以开始重构他们写入多种方法的每一个方法，即使他们正在处理它们。为你的日程安排额外的时间“重构其他方法以使代码可以维护”。这样做就像你认为应该做的那样 - 并且 - 这里是教育部分 - 当他们抱怨时，告诉他们如果他们第一次做对，你就不必重构这些方法。通过这种方式，你的老板得知你必须纠正别人的懒惰，而你的同事知道他们应该让它变得与众不同。

这至少是一些理论。