欢迎关注微信公众号「Swift 花园」
通俗解释 z-score ，即 z-score 是对某一原始分值进行转换，变成的一个标准分值，该标准分值可使得原来无法比较的数值变得可比。
本教程中我们还继续沿用前面教程中足球队的例子。
你在这里看到的是所谓的球员纹身占比，以纹身占身体的百分比表示。点图和标准差表明，第二队的分布比第一队的变化更大。
有时研究人员会问：一个特定的观测结果是常见还是特例。为了回答这个问题，研究人员会用 一个数与平均数的差再除以标准差 。这个数字就是我们所说的 z 分数。在这篇教程中，我将解释如何计算 z 分数，以及它们的用处。
我们先来看看第一队的分布情况。平均数是 15 ，标准差是 2.5 。为了计算 z 分数，我们使用这个公式：
这个公式不是很复杂，它告诉你如何计算感兴趣的数值。该数值与平均数之差，再除以标准差。
欢迎关注微信公众号「Swift 花园」
在前一篇教程中，我们学会通过图表概述分布。这同样适用于描述分布的中心位置，有三种主要方式，它们分别是：众数 (mode) ，中位数 (median) 和 平均数 (mean) 。
这三个 m 通常被称为集中趋势的度量。
找到众数很容易，它是出现频次最高的值。 换句话说，就是最常见的结果。
如果测量定类或定序变量，众数通常用作衡量集中趋势。
在下面这个饼图中，可以看到西班牙主要球赛中球员来自哪些大洲。
饼图使众数一目了然，是欧洲 70％ 的球员来自欧洲
这里的众数是欧洲 ，是最常出现的类别的名称，但众数不是 70％ 。这只是该特定类别的观测百分比。可能有多个众数。试想有一个足球运动员，拥有十分分裂的球迷，其中一些觉得他非常和善，而另一些则认为他非常蛮横。来给这个球员起个名，Franco Galton。
欢迎关注微信公众号「Swift 花园」
当我们向他人呈现数据时，通常需要将数据 “总结” 成各种图表的形式，例如频率表、饼图、条形图、散点图和直方图等。
如果你对足球非常感兴趣，你想知道所有细节：比如某个球员有多少进球，某个球队赢了多少场比赛或者在某场足球比赛中有多少次点球。统计学知识，将帮助你成为足球或任何其他运动的真正专家。
进球得分，赢得比赛，判罚点球，这些都可以被看作 变量 和 统计案例 。
变量 是事件或者人物的特征， 统计案例 就是那个事或那个人。
来讲得更具体一点。想象一下，你最喜欢的球队，你对足员的某些特征感兴趣：你想知道他 / 她的体重，头发颜色，年龄以及在最近的比赛中得分的总数。所有这些球员的特征都是变量，球员本身就是统计案例。
另一个例子，可能你对个别球员的特征不是那么感兴趣，而对他们所效力的球队特征感兴趣。例如，你可能想了解每个西班牙球队，以及它们所在的城市，他们队服的主色调是什么，以及球队去年有多少进球。这些特征也都是变量。但是，这里的统计案例不是个别球员，而是这些人所效力的球队。
在一项研究中，案例可以是许多不同的事物。 可以是个别球员和球队，也可以是公司，学校甚至是国家。
案例的每个特征都可以成为变量 —— 只要它符合一个基本的标准：即是变化的
这是什么意思呢？ 让我们回到示例。以球队为案例，并以团队所在的城市为变量。你关注每个西班牙球队，所以会有很多不同的城市：一支球队来自巴塞罗那，其他球队来自马德里，瓦伦西亚或塞维利亚。换句话说，城市是有变化的。
欢迎关注微信公众号「Swift 花园」
乍一看，统计学可能很吓人，但实际上，统计学并不可怕。它可以关乎很有趣的事，比如足球、潜水、巧克力，很有趣的人，比如潮人、出租车司机和婴儿。
至少有三个原因，让统计学至关重要。
我们将统计学分为两种类型： 描述统计学 和 推断统计学 。当我们谈论 描述统计学 时，我们指的是概述信息的方法。我们可以通过图表来概述信息，比如饼图或条线图或者诸如平均值，百分比或相关系数等数字。推断统计学 是仅根据有限数据案例，推断有关整体的结论。
教程会分为七个模块。前两个模块主题是描述统计学；接下来的三个模块，将介绍之后在推断统计学中用到的方法：我们会讨论 概率 ，概率分布 和 抽样分布 ；在最后的两个模块中，我们将介绍推断统计学方法， 如何估计置信区间 以及 如何进行假设检验 。
不需要额外的知识，学校里学的足够了。你需要的是对方法论和数据的兴趣，以及最重要的东西 —— 激情 ！
欢迎关注微信公众号「Swift 花园」
在软件开发时常常遇到一种场景：随着产品功能的扩展，出现了多个具备高度相似性的功能单元。这些功能单元可能有着相似的交互逻辑，提供同类的输入数据和输出数据。并且对于用户来说，它们共同处理同一个元素。举个例子，比如一款修图 app ，它包含了一组编辑功能，每个功能都作用于一张图片，处理之后的图片还可以作为其他功能的输入。作为编辑工具，在每个功能内部，还可能都需要支持撤销和重做这样的用户操作。容易想到，这些功能间存在着许多可以进行复用设计的代码。
本文基于我曾经从事的一款图像处理应用开发过程中的一次代码重构的实践所做的回顾发起，期望达到记录和分享的目的。
请先看下面这幅图：
图中的元素很少，但细心的读者可能留意到了：图中的 “ 内存图像管理 + 效果处理 ” 是一个 “ 黑盒子 ”。那么这个黑盒子是一件好事还是坏事呢？
既然我们对这种设计做了重构，那么这里重点来探讨一下它的缺点。 黑盒子的优点部分，作为思考题留给读者。
在具体业务场景下，我发现旧有设计的两个问题：