函数的第一规则就是要短小，第二条规则就是要更短小。每个函数保持职责单一，并且有意识的维持在一定行数内（JVM 就强制要求每个函数要小于 8000 行…也听过每个函数尽量维持在 15 行 or 30 行 之内这样的说法..可能有点魔怔，但要点就是函数要尽量短小），这当然是最理想的情况，而现实的情况往往要糟糕一些。
在工作中，我就遇到过一些长得可怕的方法，他们或许本来保持着单纯，职责单一，但是经过业务不断的改造，需求不断的叠加，甚至是一些临时逻辑的加入，这个方法就变得越来越臃肿不堪…并且因为业务的不断发展，越来越少的人会 care 到它，以至于改造成本越来越大，甚至被遗忘在角落..
这其实是再正常不过的事情，但在多人协作的项目中，有一点需要自己来维持清醒，那就是：「一个方法就可以返回的为什么要写两个？」，关于这一点，保持自己的思考就好了..
注释要体现代码之外的东西
有一句听起来好厉害的话叫做：「代码即注释」，不知道大家是怎么看待这样一句话的，或者说是怎么看待注释的。其实反过来想，如果你的代码需要大量的注释来解释其中的逻辑，会不会是代码本身就存在一定问题？或者换个角度思考，注释是用来解释代码逻辑的吗？