你是在正在创建一个坑还是在扩建一个坑？

　　这周的工作终于告一段落，费神的一周啊。在历史功能上开发新功能，历史代码还有bug。开发过程中心情相当的纠结。还好，最后还是把它拿下了，逻辑还算清晰，但是就是代码太多了，这个提醒我们，在编码规则中必须加一条，一个方法的代码不能超过多少行代码，每行代码不能超过多少字，每个类不能超过多少个方法。

　　其实大家都知道，作为具体业务开发，很多情况是根据业务，一般就不会做过多结构和代码优化的考虑。一切主要为具体的功能服务，这样的思路对于小模块或者说逻辑不是很多功能需求来说，似乎并没有什么错；但是长此以往，你就会发现，以这种思路做出来的功能，到最后总有几个坑留在整个项目中。不动它当然没有什么问题，但是一旦要在这个基础上做扩展，就像在原来坑的基础上做更大更深的坑一样，一发不可收拾。所以，我们在做代码规范的时候，必须做一些必要的限制和控制。这样控制可以解决方法过大，单行代码过多，代码浏览不方便。还能有意思的提醒我们的业务开发者，在遇到普通或复杂业务逻辑都必须作结构上的优化，该封装的要封装，该灵活控制的要灵活控制。这样才能让我们在整个项目未来的发展和功能的修改升级时得心应手，收放自如。

　　在我遇到的开发中遇到比较多的都是流程性的功能会出现方法过大，加之在开发过程中作为开发者的我们通常是以惯性思维来解决问题，所以方法过大就会成为必然。所以在开发之初也要考虑未来的发展，这一思路也是必不可少的。做必要的封装解耦，把不变的业务逻辑分析出来封装，把容易变的逻辑分析出来解耦，这样在做扩展的时候，就可以得心应手，不必纠结，无论是开发测试，还是从公司开发成本来说，都可以省一笔不小的数目。

　　单行代码过多，能开的比较多的一般是针对一个对象的方法的多层调用。大家一般的习惯是放在一行处理，如果分开又要新声明变量来接收然后调用后续的方法。其实大可不必这么麻烦，现在的编辑器和编译器是支持换行的，你只需要在合适的地方换行就ok。劲量让所有代码在一屏和主视线能接收的范围内以方便浏览，在这个过程中可以允许通过屏蔽下滑浏览其余代码。如果你写的代码又要让代码横向滑动又要纵向滑动才能看完，这该是多么痛苦的一件事情，你觉得呢？