如何说服您的开发伙伴编写简短的方法?

要求他们为这些方法编写单元测试。

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

当我听到有人说“写简短的方法”时,我立即做出了糟糕的反应,因为我遇到了太多意大利面,这些人认为理想的方法是两行:一行完成尽可能小的工作单元,然后一行调用另一种方法。(你说长方法是邪恶的,因为“它们很难理解”?试着走进一个项目,在这个项目中,每一个琐碎的操作都会生成一个50个方法深的调用堆栈,并试图找出这50层中哪一层是你需要更改的…)

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

你列了一个缺点清单。试着用简短的方法列出你将获得的东西。具体例子。然后再试着说服他。

我从某处读到这句话:

编写你的代码,就好像必须维护代码的人是一个暴力的疯子,他知道你住在哪里。

代码审查!

我建议您尝试进行一些代码检查。这样,你就可以有一个关于最佳实践的小研讨会,以及你的公司所遵循的任何格式。这就增加了一个上下文,即短方法是一种使代码更可读、更容易理解并符合SRP的方法。

如果你试图解释好的设计,而人们只是不理解,或者只是拒绝接受,那么停止尝试。这不值得努力。你只会得到一个坏名声。有些人就是没有希望。

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

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

我确实喜欢别人建议的代码审查的想法。这些草率的程序员不仅应该审查自己的代码,还应该参与好代码的审查。这将使他们有机会了解什么是好代码。可能他们从来没有见过好的代码。

为了扩展rvanider的答案,对代码执行圈复杂度分析确实奇迹般地引起了对大型方法问题的注意;当我离开时,让人们改变仍然在进行中(对大方法的动力太大)。

转折点是当我们开始将圈复杂度链接到bug数据库时。超过20个非工厂的CC保证在bug数据库中有多个条目,并且这些bug通常有“血统”(修复bug A导致的bug B;修复bug B导致的bug C;等等)。事实上,我们有三个CC超过100(最多275),这些方法在我们的bug数据库中占了40%-“你知道,也许5000行函数不是一个好主意…”

这一点在我在那里开始时领导的项目中更为明显。目标是将CC保持在尽可能低的水平(97%在10%以下),最终结果是我基本上停止支持一个产品,因为我有20个bug不值得修复。

没有Bug的软件不会因为简短的方法而出现(这可能是您必须解决的一个问题),但是当您使用简短的方法时,Bug修复非常迅速,并且通常没有副作用。

尽管编写单元测试可能会解决长方法的问题,但您的公司可能不使用单元测试。花言巧语只会走到这一步,很少对那些固执己见的开发者起作用;向他们展示这些方法如何创造更多的工作和有缺陷的软件。

在函数长度和简单性之间找到合适的结合可能很复杂。尝试应用一个度量,例如 Cyclomatic Complexity 演示以当前形式维护代码的难度。没有什么比基于测试因素(如分支和决策计数)的非个人测量更好的了。

不确定这句名言来自何方,但:

调试的难度是一开始编写代码的两倍。因此,如果您尽可能巧妙地编写代码,根据定义,您还不够聪明,无法调试它

强迫他阅读史蒂夫·麦康奈尔完成的代码。说每一个优秀的开发人员都必须阅读这篇文章。

这个答案的关键是一个问题,“为什么我总是写短函数,而当我不写的时候却恨我自己?”

原因是我很难理解复杂的代码,比如长函数,维护和操作大量状态的东西,或者诸如此类的东西。很多年前,我注意到有相当多的人比我更擅长处理这种复杂的问题。具有讽刺意味的是,可能正是因为这样,我才比他们中的许多人更善于编程:我自己的局限性迫使我面对并清理这类代码。

很抱歉,我不能在这里提供一个真正的答案,但也许这可以提供一些见解,帮助我们找到答案。

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

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

我经常问我的团队的问题是:“现在是晚上11点,你必须阅读这段代码-你能吗?你能在压力下理解吗?你能通过电话,不远程登录,引导他们到他们可以修复错误的部分吗?”如果答案是否定的,接下来的问题是“你能分离出一些复杂性吗?”

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

写两个段落并向他们展示结果所需的时间。

没有什么比以身作则更好的了。

短或长是可以有不同解释的术语。首先是一个2行的方法,而其他一些人会认为代码不超过100行的方法非常短。 也许您可以让您的开发伙伴阅读一些关于如何实践坚实原则的内容。

希望从更大的角度来看,他们能够理解这背后的原因。

• 向他展示测试短方法是多么容易。证明编写简短的方法将使他更容易、更快地为自己的方法编写测试(他说) 测试这些方法,对吗?)

• 当你检查他的代码时,把它提出来。“这种方法相当长、复杂,似乎有四种不同的作用 在这里 , 在这里 和 在这里 ."

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

教猪唱歌是没有用的。它浪费你的时间,惹恼猪。

只是比别人更耀眼。

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

你可能想告诉他们他可能有很好的记忆力,但你没有。有些人能够处理比其他人更长的方法。如果你们都必须能够维护代码,那么只有在方法更小的情况下才能完成。

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

[编辑] 为什么这是收集负面分数?

你可以开始重构 每一种方法 他们编写了多种方法,即使他们目前正在使用这些方法。为“重构他人的方法以使代码可维护”的日程安排分配额外的时间。像你认为应该做的那样去做,然后——这是教育性的部分——当他们抱怨时,告诉他们如果他们第一次就把方法做对了,你就不必重构方法。这样,你的老板就知道你必须纠正别人的懒散,而你的同事也知道他们应该改变现状。

这至少是一些理论。