编写函数的功能

显而易见的功能

我会承认，在最长的时间里，我不知道很多想法会写在编写函数上。对我来说，创建一个函数意味着编写一块可重用的代码。这是一个简单的想法，它困扰着我，因为功能=可重用代码。

我没有结构、长度或含义的概念。随着时间的推移，随着项目的发展，事情开始看起来像长脚本。这些长函数几乎相互交织在一起，形成了一种模式。

长函数

长函数非常昂贵：

• 难以阅读和记忆
• 难以测试和调试
• 隐藏业务规则
• 难以重用并导致重复
• 改变的可能性更高
• 无法优化
• 过时的评论

设计中的长功能具有很低的内聚力，并且对系统了解太多，耦合度很高。这与软件设计的基本原理正交，软件设计的基本原理说组件应该具有很高的内聚力以及如何耦合。

单层抽象原理（SLAP）

通过计算行数很难判断函数是否长。50太长了吗？25或10呢？多小足够小？这就是SLAP发挥作用的地方。

给定段/块内的代码应处于相同的抽象级别。

因此，问题不是一个函数有多长时间，而是一个函数的抽象级别是多少？函数不应混用不同级别的抽象。对于前。执行表单验证的函数不应进行I / O调用。

根据经验法则：

函数应该只做一件事，而他们应该做得很好。—罗伯特·马丁

功能多于一件事的功能面临与长功能相同的缺点。当您开始测试代码时，该规则变得更加明显。测试执行一件事的函数非常简单，因为您不必担心所有复杂的排列和组合。

撰写方法模式

通常，当您有解释代码块的注释时，它们是函数提取的候选对象。

在方法上多次使用ExtractMethod时，原始方法将成为ComposedMethod。它由逻辑步骤组成，这些步骤读起来就像我们进行沟通的方式并隐藏了实现细节。

提取，直到你无法提取为止。提取到你倒下为止。——罗伯特·C·马丁。

TL; DR

正如肯特·贝克（Kent Beck）所说，将您的程序划分为执行一项可识别任务的函数。使函数中的所有操作都处于相同的抽象级别。这自然会导致程序具有许多小功能，每个功能只有几行。

原文链接：https://dev.to//voidmaindev/slap-your-functions