2012.3.30 微博热报：大方法、基础 vs 库

关于代码中对方法的定义，有很多规则，其中一条就是要限制一个方法中代码的行数。这条规则也会根据具体使用的语言和项目不同而有所区别。日前， XiaoshenW 的一条微博中提到了“毛少”在西安电子科技大学的讲座，其中说到：在 ThoughtWorks 代码超过 15 行就视为＂大方法＂。从而引起了大家对“大方法”的定义以及一个方法中应该有多少行代码展开了广泛讨论：

onedear ：超过 15 行就属于大方法，那大方法要怎么对待呢？// @老赵: 我问了好多次了，谁能给我一个示例项目看看啊？

真谛 LOL ：对对对，易维护是真，我司。。。那个破项目使用 django 已经被修改到惨不忍睹，后来。。我试着分了一下。。现在产品再来小变动，分分钟解决问题啊！

1000copy ： 15 行也好，50 行也好，并非本质，本质是设置一个信号，在这个值超过的时候，提醒自己和团队是否有必要处理。一个较大团队，如果简单说要做到“可读”是不易于操作的，而有一个共同认可的行数信号比较实用。可以自动化，可以提醒；我发现超过这个行数的几乎都有调优的空间，并且不小。具体项目的缺乏是一个硬伤，现实工作中，没有人为了这个单一的理念全面贯彻下去而做一个项目，做项目除了代码的可维护性外，还需要考虑很要因素，其中有些比可读性还重要。做了也一样要被质疑。也有一些现实问题，就是公司项目全面成功且实际投入使用行数限定的，拿出来有政策风险。有些人确实是比较无聊。比如行数的概念还是语句的概念；比如行数没有指明列数；你明明知道人家不是这个意思，都是同行，至于搞这些飞机嘛。实话说有点幼稚和耍弄小聪明。

压力很大同志：我一般的底线是一屏，不是竖着那种 // @刘鑫 -MarchLiu : 很难想像一个实用的项目里没有超过 15 行的方法，我给自已的标准是读起来舒服就行，一个逻辑嵌套十几二十层方法，会比写五十行代码更蛋疼。 // @bnu_chenshuo : 标准随便你定，能不能举一两个符合你自己定的标准的项目给大家学习学习？

赖晨东：方法大小不应该以行数来定的。而是以“职责（功能）”来定的。保持【一个方法只干一件事】并保持【同一方法的代码在同一抽象级别上】，方法就长（行数多）不起来。现实中看到的那先几百上千行的方法绝大多都违反了上述两个原则。

高翌翔：不管别人信不信，反正俺是信了！行数多寡靠得是功力，不妨从 25 > 20 > 15 > 10 > 5 依次递减，就像从幼儿园到博士后一样；而细粒度方法是程序设计的追求之一，不仅代码重用性好、更易维护，最重要的是，这是对问题域加深认知的过程，正如科学家不断探究分子、原子、夸克等更小粒子的过程相仿！

关于高手和菜鸟之间的区别，有很多种说法,蛙蛙王子也在微博上说出了自己的想法：我觉得现在高手和菜鸟最大的区别是高手会用的库多，而不是高手底层好，基础硬，当你研究 epoll 时，高手都精通 libevent 了，当你费心思考虑组织 js 代码时，高手都熟练使用 backbone 和 seajs 了，花时间补基础，自己写基础组件，不如学现成库有成效。不过大家也都说出了自己的想法:

宝玉 xp ：我一直觉得高手在于擅于用已知知识和学习新知识去快速实现或解决问题，而不在于他会多少知识点。

TKei_ ：相当实际有效做法，但还是觉得想要理解得透彻，基础和底层是必须的，当然，如果是要做框架或者库的开发者，底层是相当重要了

蛙蛙王子：回复 @宝玉 xp : 太虚了这种说法，设么都不会也能做到这点，高手的积累还是很多的

aste22 ：也不完全。装配脑袋 RednaxelaFX 即便见识不够广，但人家的基本功那可是非同寻常的，他们更是高手

李欢的大猪窝：实际上，公司里需要精通底层的人几个就够了，需要精通框架的人多

袁凯 1860yk ：不敢苟同！创造者比使用者有价值

推荐微博： XiaoshenW

简介：能做到精致就不要停留在 good enough 上；精神洁癖；持续改进。