子程序

    什么时候，进行分解函数，什么时候提炼出来一个小方法，小的方法是不是越多越好，还是应该少一些小的方法，提炼小的方法的目的是什么呢？这些个疑问在我的心里盘旋了很长一段时间，心中也隐隐约约的有了一些答案，但是一切都不明朗。

    在我认为，小的方法提炼出来的目的，无非就是两点,第一呢就是代码重用，提炼出来的代码可以给其他的代码使用，这样就可以减少代码，减少了更改的地方，也简洁的增强了代码的可读性。也是今后的代码更改，变得容易一些。第二点呢，我觉得就是为了代码的可读性。代码的长度越长理解起来就越困难，看一篇文章和看个小笑话的难度肯定是不一样的，当然了，还要看写代码的人的水平如何了，即使很小的代码，如果写的人不是很负责人的话，那么可读性也就不用提了。提炼出来一个个小方法，这样看你主方法的人就不用关心小方法里面写的是什么了，它主要看看主方法就知道你是如何实现的，你的架构如何等等。

    但是这一切都是建立在命名上面，如果你的小方法的名字起的不知所云的话，别人也不会掉用你的代码了，因为别人不知道那个代码是干什么的，还有，别人看你的主方法的时候，还是要去看你的小方法，因为看名称不知道是干什么，只能看代码。

    以前总是觉得调用各种各种各样的类，调用各种小技巧很炫，当然了，这些技巧还是要知道的。现在觉得一个代码的好坏，还是很大一部分依赖于代码的命名规则，不管是变量的还是方法的。

    ：）呵呵，有些扯远了，说的编码规则上来了，现在转回来。关于什么时候进行提炼小方法，我个人觉得就是在你需要上面两点的时候，就可以提炼小方法，也就是有重复代码（也就是需要共享代码），和整体结构不清楚的时候。

    哦，还有，小方法的另外一个好处就是重构别人的代码的时候，我一般都是先把别人的代码分解成一个个小方法，当然了，也不是乱分的，这样就能看到很多无用的代码，和很多耦合的地方。这样，一点一点的分解了复杂的代码之后，自己也明白了原来作者的意图，然后自己也把整个架构给整理出来了，这样，剩下的工作，就可以大刀阔斧的整理了，当然了，也保证测试要跟得上哦^-^.

今天看了《Code Complete》中文《代码大全》，上面也是总结了一些创建子程序的理由，很多都是与C有关的，自然我这个java爱好者所不能理解了，不过写在最后，提醒自己慢慢理解：），我觉得这本书还是不错的，至少前五章我看完了，感觉还是不错，把我以前看到的东西，林林总总的给总结了出来，至少我觉得这本书如果在我刚毕业的时候就看到的话，应该对我帮助很大的，现在只能用于巩固自己的知识了，希望后面的章节对我用处更大一些：）

   
以下是创建子程序理由概述：
· 降低复杂性
· 避免重复代码段
· 限制改动带来的影响
· 隐含顺序
· 改进性能
· 进行集中控制
· 隐含数据结构
· 隐含指针操作
· 隐含全局变量
· 促进重新使用代码段
· 计划开发一个软件族
· 改善某一代码段可读性
· 改善可移植性
· 分隔复杂操作
· 独立非标准语言函数的使用
· 简化复杂的布尔测试