如何说服你的开发人员编写简短的方法？
长期的方法是邪恶的几个理由：
- 他们很难理解
- 他们很难改变
- 他们很难重用
- 他们很难testing
- 他们的凝聚力低
- 他们可能有很高的耦合度
- 他们往往过于复杂
如何说服你的开发人员编写简短的方法？ （武器被禁止=）
来自敏捷开发者的问题
你列出了一些缺点。 尝试使用简短的方法列出您将获得什么。 具体的例子。 然后再试图说服他。
要求他为这些方法编写unit testing。
这取决于你的“短”和“长”的定义。
当我听到有人说“写简短的方法”时，我立即反应不佳，因为我遇到了那些认为理想方法是两行长的人写的太多意大利面条：一行做最小的工作单位，然后是一行调用另一种方法。 （你说长方法是邪恶的，因为“他们很难理解”？尝试走进一个项目，每个微不足道的动作产生一个调用堆栈50个方法，试图找出你需要改变的50个层次中的哪一个…）
另一方面，如果“短”的意思是“自成一体，局限于一个概念function”，那么我就是为了这个。 但请记住，这不能简单地通过代码行来衡量。
而且，正如tydok所指出的，你用蜂蜜比醋要更多的苍蝇。 试着告诉他们为什么你的方式是好的，而不是为什么他们的方式是坏的。 如果你能做到这一点，而不做任何明显的比较或引用他们或他们的做法（除非他们特别问你的想法如何与他们正在做的事情），它会更好地工作。
我从某个地方读到这句话：
写你的代码，就好像维护它的人是一个暴力的心理学家，谁知道你住在哪里。
根据我的经验，在这种情况下说服同行的最好方法就是举例。 只要find机会向他们展示你的代码，并与他们讨论短function与长function的好处。 最终，他们会意识到什么是自发的更好，而不需要让他们感觉“坏”的程序员。
代码评论！
我build议你尝试一些代码审查。 这样你可以有一个关于最佳实践的小研讨会，不pipe你的公司采用什么格式。 这增加了上下文，简短的方法是一种使代码更易读，更容易理解，也符合SRP的方法。
为了扩展rvanider的答案，对代码进行循环复杂性分析确实令人关注的是大的方法问题; 当我离开的时候，让人们改变的方式仍然在起作用（对于大方法来说，势头很大）。
转折点是当我们开始将环路复杂性连接到错误数据库时。 超过20个不是工厂的CC保证在错误数据库中有几个条目，并且这些错误通常有一个“血统”（修复了Bug A导致了Bug B;修复了Bug B导致了Bug C;等等）。 实际上我们有三个CC超过100个（最多275个），这些方法在我们的错误数据库中占了40％的情况 – “你知道，也许5000行function不是一个好主意……”
我在那里开始的那个项目中更加明显。 目标是尽可能降低CC（97％低于10％），最终的结果是我基本上停止了支持，因为我所拥有的20个bug是不值得修复的。
无缺陷的软件不会因为简短的方法而发生（这可能是一个你必须要解决的问题），但是修正错误的速度非常快，而且在使用简短的方法时通常没有副作用，简明的方法。
尽pipe编写unit testing可能会治愈很长的方法，但是你的公司可能不会使用unit testing。 修辞只能到目前为止，很less适用于那些陷入困境的开发者; 向他们展示这些方法是如何创造更多的工作和错误的软件的数字。
如果你试图解释好的devise，而人们只是没有得到它，或者只是拒绝得到它，那就停止尝试吧。 这是不值得的努力。 你得到的只是你自己的一个不好的代表。 有些人是绝望的。
基本上这是因为有些程序员只是没有被开发出来。 他们可以理解已经写好的代码，但是他们不能自己创build。
这些人应该被引导到一个支持angular色，但不应该被允许在任何新事物上工作。 支持是一个很好的地方，可以看到很多不同的代码，所以也许在几年后，他们会看到好的devise的好处。
我确实喜欢别人build议的代码评论的想法。 这些草率的程序员不仅应该审查他们自己的代码，他们也应该坐在良好的代码审查。 这将使他们有机会看到好的代码是什么。 可能他们从来没有见过好的代码。
在function长度和简单性之间find正确的组合可能很复杂。 尝试应用像Cyclomatic Complexity这样的度量来certificate维护代码的难度。 没有什么比基于testing因素（如分支和决策计数）的非个人测量更胜一筹。
强迫他阅读Steve McConnell的Code Complete。 说每个优秀的开发人员都必须阅读这个。
不知道这个伟大的报价来自哪里，但是：
“debugging比编写代码要困难一倍，因此，如果您尽可能巧妙地编写代码，那么从定义上讲，debugging起来不够聪明”
让他喝醉？ 🙂
这个答案的重点是这样一个问题，“为什么我一直写短的function，而当我不这样做的时候就恨自己？
原因是我很难理解复杂的代码，是长期的function，维护和操纵很多状态的东西，或者那种事情。 我注意到很多年前，在这种处理这种复杂性的方面，有相当多的人比我更好。 具有讽刺意味的是，这可能是因为我倾向于比其中许多程序员更好：我自己的局限性迫使我去面对和清理这类代码。
对不起，我不能在这里提供真正的答案，但也许这可以提供一些见解，以帮助我们得到答案。
强迫他们阅读“清洁代码”这本书，还有许多其他的，但这是一个新的，很好，一个简单的阅读。
要求他们写复杂代码的unit testing是一个很好的途径。 这个人需要亲自看看复杂性在执行维护或分析时带来的债务。
我总是问我的团队的问题是：“现在是晚上11点，你必须阅读这些代码 – 你能吗？你有压力吗？你可以通过电话，没有远程login，引导他们到他们可以修复一个错误？” 如果答案是否定的，后续的是“你能隔离一些复杂性吗？
如果你得到一个论点，这是一个失败的原因。 扔东西然后。
我会给他们100行代码全部在1方法下，然后再分成100行代码在几种方法之间，并要求他们写下每个做什么的解释。
时间多长时间写两个段落，然后显示结果。
…确保select需要两三次的代码才能理解是否全部使用了一种方法 – Main（） –
没有什么比通过实例学习更好的了。
短或长是可以不同解释的术语。 一方面是两行方法，另一方面则认为不超过100行代码的方法非常短。 我认为最好说一个方法不应该同时做多件事，这意味着它应该只有一个责任。 也许你可以让你的开发人员读一些关于如何实践SOLID原则的东西。
我通常会向他们展示那些写得很好的方法。 然后，我将通过这些方法来解释我们为什么要这样开发它们的原因。
希望看到更大的图景时，他们会理解背后的原因。
PS。 另外，这个练习还可以作为一个小型知识转移项目。
-
告诉他testing简短的方法是多么容易。 certificate写简短的方法会使他更容易和更快地为他的方法编写testing（他正在testing这些方法，对吧？）
-
当你正在检查他的代码时，把它提起来。 “这种方法相当长，很复杂，似乎在做四个不同的事情。 在这里 ， 在这里和这里提取方法。
长的方法通常意味着对象模型是有缺陷的，也就是说一个类有太多的责任。 有可能你不希望在同一个class上有更多的function，每一个function都比较短，但是那些负责的function恰当地分配给不同的class级。
没有用猪教唱歌。 浪费你的时间，烦恼猪。
只是闪闪发光的人。
当需要修复5000行程序中的错误时，您将有10行程序和4990行程序。 慢慢做，没有人注意到一个突然的变化，除了事情开始工作的更好，慢慢地，大球泥蒸发。
你可能想告诉他们，他可能有一个很好的记忆，但是你没有。 有些人能够处理比别人更长的方法。 如果两者都必须能够维护代码，那么只能在方法较小时才能完成。
只有在没有优势的情况下才能做到这一点
为什么这是收集负面的分数？
您可以开始重构他们写入多种方法的每一种方法，即使他们正在处理它们。 为您的计划分配额外的时间以“重构其他方法以使代码保持可用”。 像你认为应该做的那样做，而且 – 教育部分 – 当他们抱怨的时候，告诉他们，如果他们第一次做得对，就不必重构这些方法。 这样，你的老板知道你必须纠正别人的懒惰，而你的同事也知道他们应该改变别人的懒惰。
至less有一些理论。
