你只是看起来很努力_我的方法在这方面看起来很大吗？

你只是看起来很努力

以下Java方法的大小是多少？

public Collection getDescription() {SystemLibrary systemLib = registry.get(SystemLibrary.class);Analysis analysis = systemLib.getCurrentAnalysis(registry);return getDescription(analysis);}

这个不起眼的方法查找某种系统库，检索Analysis并返回对该Analysis的描述。

但是你会说它有多大？您会说这是三行代码吗？如果是这样，您会说以下行为等效的方法长2行代码吗？而且因为它更短会更好吗？

public Collection getDescription() {Analysis analysis = registry.get(SystemLibrary.class).getCurrentAnalysis(registry);return getDescription(analysis);}

还是您会说上述两个变体的大小相同，因为两者本质上都调用了相同的方法？或者它们的大小相同，因为无论格式如何，它们都有三个职责。还是因为他们只承担一项责任：返回分析说明？

方法大小的混乱会产生并产生影响。之所以会出现这种情况，是因为项目一开始就无法达成衡量规模的目标单位。它们之所以重要，是因为保持小的方法是SIPT结构原则的最基础，对于这些原则，存在降低成本的客观证据。

值得考虑的一种非直观的大小量度是该方法编译到的字节码量。等待！在终止该浏览器并将其永久卸载之前，请考虑…

当然，很少有Java程序员会知道或关心上述方法编译为35个字节（确实如此）。但是使用字节码具有绝对的双重优势（它完全是客观的（程序员无需再为方法长度为2或3行而费解），脚本和解析器可以自动连续地获取信息。

也没有永远的程序员必须学会如何在他们的头上做任何事情的可笑的编译Java。

假设您的项目同意将方法大小限制为50个字节。 Deborah很快-在几分钟之内-按照她的传统测量线标准，发现50字节大约是5行代码。因此，她将自己的方法保持4行代码长，并且该项目的规模目标从来不必敲门。（请在此处查看您是否可以在一分钟内发展这项技能。）

另一方面，Danny根据他的编程风格发现50字节是6行代码，因此将其方法保持5行长。只要两者都满足在每次检入时解析已编译代码的脚本（和相关的自动武器），项目经理就可以安然入睡，知道质量（至少对于此特定代码属性而言）是安全的。

当然，有时方法会反映出他们的主人，并开始在腰部隆起。当方法大小开始增加时，您的项目解释统计信息所依据的策略就变得至关重要。

实际项目了解小型方法的重要性以及具有一定灵活性的信任程序员的重要性。实际项目不要求所有方法都小，而仅要求它们平均较小，并且，更重要的是，该平均值不会无限上升。

假设一个项目决定平均方法的长度必须小于50个字节。然后，如果平均方法大小徘徊在47个字节长，则该项目可能允许团队进行稍大的更改，从而使平均长度达到48个字节。（尽管有些程序员对永不感到骄傲，无论其平均大小如何，都永远不会增加其平均大小。）

但是该项目将不允许任何团队将这个数字拖到50字节或更长时间。

你疯了！

您认为50个字节（例如5行代码）太小了吗？您认为任何大型Java软件项目都不可能拥有如此小的平均方法大小吗？

您的项目使用Jenkins吗？ Jenkins的15,089个方法的平均长度仅为29个字节。这大约是三行代码。

实际上，现代项目将阈值保持在较低水平几乎没有问题。表1列出了流行的Java程序及其字节码平均方法大小的列表。

程序	平均方法大小（字节）	程序	平均方法大小（字节）
净额	20	ActiveMQ经纪人	32
JUnit的	23	弹簧	40
骆驼	27	Log4J	40
詹金斯	29	Tomcat（土狼）	44
Spoiklin Soice	29	卡桑德拉	53
Struts	30	Lucene	55
FitNesse	31	动物园管理员	55
Maven	35	卡塔琳娜	57