长方法之恶在于以下几点：
- 它们难以理解
- 它们难以更改
- 它们难以重用
- 它们难以测试
- 它们的内聚性低
- 它们可能有高耦合度
- 它们往往过于复杂
如何说服你的同事编写短小的方法？（禁止使用武器 =)
问题来自敏捷开发者
如何说服你的同事开发者写短小的方法？
34
- dfa
1
好问题...我也在想同样的事情 :) - Rashmi Pandit
22个回答
50
请让他们为这些方法编写单元测试。
- jrharshath
4
1非常好的建议。这会让他们三思而后行 ;) - OregonGhost
8没有询问。要么说出来，要么不说。 - Kris
2好的，更正一下：“告诉他为这些方法编写单元测试。” :) - jrharshath
2请保持礼貌。如果你表现得像个混蛋，他不会听你的话，你唯一能做到的就是惹恼他。除非你是他的老板，否则就保持冷静吧。 - gillonba
26
那要看你对“短”和“长”的定义。
当我听到有人说“编写简短的方法”时，我会立刻反感，因为我遇到过太多由认为理想方法只有两行长的人编写的意大利面条式代码：一行执行最小可能的工作单位，然后一行调用另一个方法。（你说长方法不好理解？试着走进一个每个琐碎操作都生成50层方法调用堆栈的项目，并试图弄清楚哪一层是需要更改的...）
另一方面，如果你所谓的“短”，指的是“自包含且限于单一概念函数”，那我完全支持。但请记住，这不能仅通过代码行数来衡量。
此外，正如tydok所指出的，用蜜糖比用醋更能吸引人。试着告诉他们为什么你的方式是好的，而不是告诉他们为什么他们的方式不好。如果你能做到这一点，而不做任何明显的比较或提到他们或他们的做法（除非他们特别问你的想法如何与他们正在做的事情相关），那效果会更好。
- Dave Sherohman
5
1我同意。大量的调用堆栈肯定应该进入讨论。 - Mr. Shickadance
“short”不就是适合在一个屏幕上显示的吗？但是，有时我会使用Consolas字体，在监视器旋转90度的情况下以极小的尺寸进行编程... :)
无论如何，单元测试最好定义了什么是“短”的方法。如果您不能轻松地为某个方法编写单元测试，那么它就太长了;) - OregonGhost
1短和长是一种“我看得出来”的东西。当我看到一个有400行代码和McCabe指数超过40的方法时，那就属于“长”的范畴了。 - Adam Jaskiewicz
1抱歉，但是用蜜糖比用醋并不能吸引更多的苍蝇... http://xkcd.com/357/ - Kurru
@Kurru：实际上我是用苹果醋观察到这一点的，而不是意大利黑醋，但是没错。第一次看到女友的母亲拿出一盘醋作为捕蝇器时，我感到非常惊讶... - Dave Sherohman
24
你已经列出了缺点清单。试着列出使用简短方法可以获得什么。给出具体的例子。然后再次尝试说服他。
- Nick Dandoulakis
15
我从某处读到了这句话：
编写代码时，要像维护它的人是一个暴力精神病患者，他知道你住在哪里。
- JonoW
1
1很可能你是对的。没有太多的人能够避免维护自己的代码 :) - Esteban Küber
7
根据我的经验，说服同行的最好方式是以身作则。只需找到机会展示你的代码，并与他们讨论短函数和长函数的优点。最终，他们会自然而然地意识到什么更好，而不需要让他们感觉自己是“糟糕”的程序员。
- UncleZeiv
2
1你的意思是通过举例教他们如何识别代码中的坏味道吗 :) - jrharshath
1如果在和他们相处一段时间后，你让他们意识到长函数更好了呢？ :D - Emiliano
7
代码审查！
建议您尝试进行一些代码审查，这样您可以开展一个小型讲习班，分享最佳实践以及公司所遵循的格式规范。通过这种方式，可以更好地理解短方法是如何使代码更易读、更易理解，并且符合单一职责原则。
- willcodejavaforfood
1
从某个网络漫画中：代码质量唯一可靠的度量标准是在代码审查期间每分钟 WTF 的数量。 - jrharshath
5
如果你尝试解释什么是优秀的设计，但人们不理解或者拒绝理解，那么请停止尝试。这样做不值得。你只会给自己带来坏名声。有些人就是没有救了。
基本上，有些程序员并不适合开发工作。他们可以理解已经编写好的代码，但无法独立创建它。
这些人应该被引导到支持角色中，但不应被允许参与任何新项目。支持是一个很好的地方，可以接触到各种各样的代码，也许几年后，他们会意识到优秀设计的好处。
我喜欢另一个人提出的代码审查的想法。这些松散的程序员不仅应该检查自己的代码，还应该参加优秀代码的评审。这将给他们一个机会去了解什么是好的代码。也许他们从未见过好的代码。
基本上，有些程序员并不适合开发工作。他们可以理解已经编写好的代码，但无法独立创建它。
这些人应该被引导到支持角色中，但不应被允许参与任何新项目。支持是一个很好的地方，可以接触到各种各样的代码，也许几年后，他们会意识到优秀设计的好处。
我喜欢另一个人提出的代码审查的想法。这些松散的程序员不仅应该检查自己的代码，还应该参加优秀代码的评审。这将给他们一个机会去了解什么是好的代码。也许他们从未见过好的代码。
- Clayton
5
为了进一步解释rvanider的回答，对代码进行圈复杂度分析对于引起大型方法问题的关注非常有帮助；当我离开时，让人们改变仍在进行中（对大型方法的势头太强了）。
转折点是我们开始将圈复杂度与漏洞数据库链接起来。超过20的圈复杂度不是工厂，肯定会在漏洞数据库中有几个条目，而且这些漏洞通常有“血统”（修复Bug A导致Bug B；修复Bug B导致Bug C等）。我们实际上有三个圈复杂度超过100（最大为275），这些方法占我们漏洞数据库案例的40%——“你知道，也许那个5000行函数不是一个好主意……”
当我开始领导项目时，这一点更加明显。目标是尽可能保持圈复杂度低（97%低于10），最终结果是我基本上停止支持产品，因为我只有20个漏洞不值得修复。
没有Bug的软件不会因为短小的方法而发生，但是当您使用简短、简洁的方法时，Bug修复非常快速，而且往往没有副作用（这可能是您需要解决的论点）。
虽然编写单元测试可能会治愈长时间的方法，但您的公司可能不使用单元测试。花言巧语只能走那么远，并且很少对那些固执己见的开发人员起作用；向他们展示这些方法如何创建更多工作和错误软件的数字。
转折点是我们开始将圈复杂度与漏洞数据库链接起来。超过20的圈复杂度不是工厂，肯定会在漏洞数据库中有几个条目，而且这些漏洞通常有“血统”（修复Bug A导致Bug B；修复Bug B导致Bug C等）。我们实际上有三个圈复杂度超过100（最大为275），这些方法占我们漏洞数据库案例的40%——“你知道，也许那个5000行函数不是一个好主意……”
当我开始领导项目时，这一点更加明显。目标是尽可能保持圈复杂度低（97%低于10），最终结果是我基本上停止支持产品，因为我只有20个漏洞不值得修复。
没有Bug的软件不会因为短小的方法而发生，但是当您使用简短、简洁的方法时，Bug修复非常快速，而且往往没有副作用（这可能是您需要解决的论点）。
虽然编写单元测试可能会治愈长时间的方法，但您的公司可能不使用单元测试。花言巧语只能走那么远，并且很少对那些固执己见的开发人员起作用；向他们展示这些方法如何创建更多工作和错误软件的数字。
- Austin Salonen
4
找到功能长度和简单性之间的正确平衡可能很复杂。尝试应用度量标准，如圈复杂度，以展示在其当前形式下维护代码的难度。没有什么比基于测试因素（如分支和决策计数）的非个人化测量更好了。
- Ryan VanIderstine
4
不确定这句伟大的名言出自哪里，但是：
“调试比一开始编写代码难两倍。因此，如果你尽可能聪明地编写代码，那么按照定义，你就不够聪明去调试它。”
- David Plumpton
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接