No-Brainer Functions
我承认，在最长的时间里，我不知道很多想法会写在编写函数上。 对我来说，创建一个函数意味着编写一块可重用的代码。 这是个简单的主意，功能==可重复使用的代码对我很重要。 我没有结构，长度或含义的概念。 随着时间的推移，随着项目的发展，事情开始看起来像长脚本。 这些长函数几乎相互交织在一起，形成了一种模式。
Long Functions
长函数非常昂贵：
- 难以阅读和记忆难以测试和调试隐藏业务规则难以重用并导致重复改变的可能性更高无法优化过时的评论
设计中的长功能具有很低的内聚力，并且对系统了解太多，耦合度很高。 这与软件设计的基本原理正交，软件设计的基本原理说组件应该具有很高的内聚力以及如何耦合。
Single Level of Abstraction Principle(SLAP)
通过计算行数很难判断函数是否长。 50太长了吗？ 25或10呢？ 多小足够小？ 这就是SLAP发挥作用的地方。
给定段/块内的代码应处于相同的抽象级别。
所以问题不是一个函数有多长时间，而是一个函数的抽象级别是多少？ 函数不应混用不同级别的抽象。 对于前。 执行表单验证的函数不应进行I / O调用。
根据经验法则：
函数应该只做一件事，而他们应该做得很好。 罗伯特·马丁（Robert Martin）
功能多于一件事的功能面临与长功能相同的缺点。 当您开始测试代码时，该规则变得更加明显。 测试执行一件事的函数要简单得多，因为您不必担心所有复杂的排列和组合。
Compose Method Pattern
通常，当您有解释代码块的注释时，它们是函数提取的候选对象。
When you use ExtractMethod a bunch of times on a method the original method becomes a ComposedMethod. It is composed of logical steps that read like the way we communicate and hide the implementation details.
提取，直到无法提取为止。 提取直至滴下。 罗伯特·马丁（Robert C Martin）
TL;DR
正如肯特·贝克（Kent Beck）所说，将您的程序划分为执行一项可识别任务的函数。 使函数中的所有操作都处于相同的抽象级别。 这自然会导致程序具有许多小功能，每个功能只有几行。
Øriginally posted on Hackernoon
from: https://dev.to//voidmaindev/slap-your-functions