dfa*_*dfa 33 language-agnostic metrics
长期方法在某些方面是邪恶的:
如何说服你的开发人员编写简短的方法？(武器被禁止=)
来自agiledeveloper的问题
jrh*_*ath 49
请他为这些方法编写单元测试.
Dav*_*man 25
这取决于你对"短"和"长"的定义.
当我听到有人说"写简短的方法"时,我立刻反应得很厉害,因为我遇到了太多的意大利面条,他们认为理想的方法是两行长的:一行做最小的工作单位后跟一行调用另一种方法.(你说长方法是邪恶的,因为"它们很难理解"？试着走进一个项目,在这个项目中,每个琐碎的动作产生一个50深度的调用堆栈,并试图弄清楚这50个层中的哪一层是你需要改变的层...)
另一方面,如果,"短",你的意思是"自足并限于单一的概念功能",那么我就是为了它.但请记住,这不能仅通过代码行来衡量.
并且,正如tydok指出的那样,你用蜂蜜捕获的果蝇多于醋.试着告诉他们为什么你的方式很好,而不是为什么他们的方式很糟糕.如果你能做到这一点而不做任何明显的比较或参考他们或他们的做法(除非他们具体询问你的想法如何与他们正在做的事情有关),它会更好地工作.
根据我的经验,在这些情况下说服同伴的最好方法就是举例.只是找到机会向他们展示您的代码,并与他们讨论短功能与长功能的好处.最终他们会自发地意识到什么是更好的,而不需要让他们感觉"坏"的程序员.
代码评论!
我建议你试着去做一些代码评论.通过这种方式,您可以举办一些关于最佳实践的研讨会以及您的公司所遵循的格式.这增加了上下文,即短方法是一种使代码更易读,更易于理解并符合SRP的方法.
如果你试图解释好的设计而人们只是没有得到它,或者只是拒绝得到它,那就别再试试了.这不值得努力.你所能得到的只是对自己不好的代表.有些人只是无望.
基本上它归结为一些程序员并没有被开发出来.他们可以理解已经编写的代码,但是他们无法自己创建代码.
这些人应该转向支持角色,但不应允许他们处理任何新事物.支持是一个看到许多不同代码的好地方,所以也许几年后他们会看到好设计的好处.
我喜欢其他人建议的Code Reviews的想法.这些草率的程序员不仅应该审查他们自己的代码,他们还应该参与好的代码审查.这将使他们有机会看到什么是好的代码.可能他们从未见过好的代码.
为了扩展rvanider的答案,对代码执行圈复杂度分析确实引起了对大方法问题的关注; 当我离开时,让人们改变的态度仍然存在(对于大方法的动力太大).
引爆点是我们开始将圈复杂度与bug数据库联系起来.一个超过20个不是工厂的CC被保证在bug数据库中有几个条目,并且这些bug经常有"血统"(修复Bug A导致Bug B;修复Bug B导致Bug C等).我们实际上有三个CC超过100(最多275个),这些方法占我们的bug数据库中40%的情况 - "你知道,也许5000线功能不是一个好主意......"
我在那里开始的项目中更明显.目标是保持CC尽可能低(97%低于10),最终结果是我基本上停止支持的产品,因为我有20个错误不值得修复.
无错误的软件不会因为简短的方法而发生(这可能是你必须要解决的一个论点)但是修复错误非常快,并且当你使用简短的时候通常没有副作用,简洁的方法.
尽管编写单元测试可能会解决长方法,但您的公司可能不会使用单元测试.修辞只是到目前为止,很少适用于那些陷入困境的开发者; 向他们展示有关这些方法如何创造更多工作和错误软件的数字.