在编程的早期，系统由程序和子程序组成，后来，在Fortran和PL/1的年代，系统由程序，子程序和函数组成。如今，只有函数存活下来。
函数的规则
短小
函数的第一规则是要短小，第二规则还是要更短小。虽无法证实，但是经验告诉作者，函数就该短小。
if ,else,while语句，其中的代码块应该只有一行，该行应该是一个函数调用语句，这样不但能保持函数短小，而且块调用内的函数拥有较具说明性的名称，从而增加了文档的价值。
这也意味着函数不应该大到足以容纳嵌套结构，所以，函数的缩进层级不应该多于一层或两层。当然这样的函数易于理解。
只做一件事
新手写程序的时候，容易觉得函数只是用来重复利用代码块，只要有重复性的东西都提取的函数中，其实不仅仅这样。
函数应该做一件事，做好这件事，只做这一件事。
要判断函数是否不止做了一件事，还有一个方法，就是看能否再拆出一个函数。
每个函数一个抽象层级
要确保函数只做一件事，函数中的语句都要在同一个抽象层级上。函数中混杂不同的抽象层级，往往令人迷惑，读者可能无法判断某个表达式是基础概念还是细节。更恶劣的是，一旦细节与基础概念混杂，更多的细节就会在函数中纠结起来。
自顶向下读程序，每个函数后面跟着位于下一抽象层级的函数。
看图，理解每个函数的逻辑层级关系。我们自己写的函数能理为如此清晰的思路就够了。
函数参数
最理想的参数量是零个，其实是一个，再次是二，应该尽量避免三个及以上的参数。
如果函数需要两个，三个，或三个以上的参数，就说明其中一些参数该封装为类了。
从测试的角度来看，要编写能确保参数的各种组合运行正常的测试用例，是多么的困难。如果没有参数，就很简单，只有一个参数，也不太困难，有两个参数，问题就麻烦多了。如果参数多于两个，测试覆盖的可能性值的组合令人生畏。
标识函数
最好不要像函数传入bool类型的值，这样做，方法签名立刻变得复杂起来，大声宣布函数不止做一件事，标识为true会这样做，标识为false会那样做。
滚动屏幕，看到render(Boolen isSuite)，应该将函数一分为二: renderForSuite()和renderForSingleTest()
分隔指令与询问
函数要么做什么事，要么回答做什么事，但两者不可得兼。函数应该修改某对象的状态，或者返回改对象的有关信息，两样常干常会导致混乱。
含糊不清的语句：这是判断某个属性是否为为某个值，还是给属性设置某个值呢？
public boolen set(String attribute,String value)
修改方案，把指令分隔开来，防止混淆的发生
if (attributesExists("userName")){
setAttribute("userName","aihe")
}
抽离try/catch代码块
try/catch会把程序弄的丑陋不堪，搞乱了代码结构，把错误与正常流程混为一谈。最好把tray和catch的主体部分抽离出来，另外形成函数。
//只处理错误，无需关心其它的
public void delete(Page page){
try{
deletePageAndAllReferences(page);
}
catch(Exception e ){
logError(e)
}
}
//只处理逻辑，无需关心错误
public void deletePageAndAllReferences(Page page) throw Exception{
....
}
结构化编程
结构化编程规则：
每个函数，函数中的代码块都应该只有一个入口，一个出口。遵循这些规则，意味着每个函数中只该由一个return语句，循环中不能有break货continue语句。
结构化编程的目标和规范可以遵守，但偶尔出现的return语句没有多大坏处，但是尽量遵守规则。
书小结
每个系统都是使用某种领域特定语言搭建，而这种语言是程序员设计来描述那个系统的。函数是语言的动词，类是名词。
大师级程序员把系统当做故事来写，而不是当做程序来写。他们使用编程语言提供的工具构建一种更为丰富且更具有表达力的语言，用来讲那个故事。
最后
仔细品味开发的精髓，代码整洁之道，获益良多。
