最近重新在读《clean code》，读到第三章函数，里面列举出了很多编写函数的准则，比如：

1. 短小

2. 只做一件事

3. 函数最好不要有参数

...

第一次读的时候，会把这些准则记下来，就像学生时代去记课本一样，自从看了一些批判性思维书籍之后，会带着一些问题来看待这些原则，比如：

1. 短小（多长的函数算短小，为什么函数需要短小）

2. 只做一件事 （什么叫一件事，比如是吃饭算一件事，还是点菜，下单，吃饭，结账各算一件事，为什么只做一件事）

3. 函数最好不要有参数（为什么不要带参数）

...

有了问题之后会在书中寻找答案，寻找作者的论据，发现其实作者很多准则是依据经验总结得出，无法得出条条框框的原因，这个时候就无法去相信作者的结论，但是可以去思考作者的理由，或者是是什么样原则推导出这些准则出来的。

前些天看了一篇文章中也提到，平时像GOF这些设计模式是术，而面向对象的思维才是道，有了道之后在遇到设计决策的时候会心中有数，也就是无招胜有招。

从函数的这些准则以及作者不成文的理由中看出编写的原则只有一个：便于阅读与理解

比如如果一个警察需要去了解一个嫌疑人一天内做了什么，可能是需要嫌疑人先做个简短的描叙：

早上去吃早饭，然后剪头，去上网，吃午饭...

然后如果对感兴趣的事情详细了解。

嫌疑人的一天就是一个函数，吃早饭、剪头、上网、吃午饭等等就很短小，而不是一开始就把所有的细节全盘说出。

如果嫌疑人在吃早饭的过程中去一趟银行，这个信息对警察比较有用，但是隐含在了吃早饭中，这就类似于一个函数做了多件事，并不是不可以，但是很难用一个简短的词语进行概括（函数名），也就给阅读者带来了困难。

等等其它的准则都是基于这个原则来进行，因此在自己设计函数时，可以参考既有的设计准则，也可以自创一些其它的方式以及对现有的准则进行改良，只有便于阅读即可。

附上部分常用准则：

1. 只做一件事

2. 同一抽象层

3. 无副作用