正儿八经 - 资深技术专家

Tools for Auditing CSS（CSS检查工具）

发表于 2021-04-26 分类于前端

背景

之前关注比较多的还是js以及js扩展语言方面的检测工具，对css方面的检查工具了解较少，个人感觉css的检查确实比较难。刚好这两天看到了一篇css检查工具的文章，刚好蹩脚的翻译一下，做个记录。

就如文中作者所说，当然自身也有体会，css检查一个很大的难点就是：可以通过许多不同的方式来实现相同的样式。这已经就让CSS审核起来有些棘手。

通过之前我在团队内分享的stylelint等工具可以避免一些问题，但是其实是不够的。仍然还有一些问题时无法解决的比如：太多的颜色，排版或z-indexs。

所以作者给我们列举了一些工具，用于检查css。

开始

浏览器内的开发工具

用Chrome DevTools 的 CSS 检查工具举例。详细的可参考 Umar Hansa 的这篇文章 —Chrome一大堆发布于 2020 年的「伟大的」 DevTool 功能。
如果你喜欢手动检查 CSS 代码，我们可以使用 Inspect 工具以找出应用于特定元素的 CSS 代码。使用 “Inspect arrow”，我们甚至可以看到关于颜色、字体、大小和可访问性的那些额外的细节。

Grid 和 Flex 的检查器

DevTools 界面中有很多实用的工具，我最喜欢的是 Grid 和 Flex 检查器。要启用它们，请进入设置（DevTools 右上方的一个小齿轮图标），点击 Experiments，然后启用 CSS Grid 和 Flexbox 调试功能。虽然这个工具主要用于调试布局问题，但我有时也会用它来快速判断页面上是否使用了 CSS Grid 或 Flexbox。

CSS Overview

让我们看看一些更高级的 DevTools 功能。CSS Overview 就是其中之一。

要启用 CSS Overview 工具，进入设置，点击 Experiments，启用 CSS Overview 选项。
要打开 CSS Overview 面板，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键，输入 css overview，然后选择 Show CSS Overview。这个工具可以展现 CSS 属性的概览，比如颜色、字体、对比度问题、未使用的声明和media查询。我通常用这个工具来判断当前 CSS 代码的好坏。例如，如果有 50 种灰度色彩或过多的排版定义，就意味着样式规范没有被应用到实际，或者甚至可能不存在样式规范。

不过请注意，该工具会对应用于这个页面的样式做出概览，而不是对单个文件做出概览。

Coverage panel

Coverage Panel 工具会显示页面上使用的代码数量和百分比。要查看它，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键，键入 Coverage，选择 Show Coverage，然后点击刷新图标。
你可以在 URL 过滤器中输入 .css 以用于过滤专门显示 CSS 文件。我通常使用这个工具来了解网站的交付技术。例如，如果我看到 CSS 的覆盖率相当的高，我就可以认为 CSS 文件是为每个页面单独生成的。这可能不是关键数据，但有时它有助于了解缓存策略。

Rendering Panel

Rendering Panel 是另一个有用的工具。要打开渲染面板，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键。这次输入 “Rendering”，然后选择 “Show Rendering” 选项。这个工具有很多选项，个人觉得最好用的是：

Paint flashing — 当重绘事件发生时会显示绿色矩形。我用它来识别需要花费太多渲染时间的区域。
Layout Shift Regions — 当布局移动发生时显示蓝色矩形。为了充分利用这些选项，我通常在 “网络” 选项卡下设置 “Slow 3G” 预设。我有时会录制我的屏幕，然后放慢视频速度来寻找布局转移。
Frame Rendering Stats — 显示 GPU 和帧的实时使用情况。这个工具在识别动画卡顿和滚动问题时很方便。

这些工具会给出常规检查中没有的数据，它对于了解 CSS 代码是否具有性能以及消耗设备的能量的多少提供依据。
其他选项可能对调试问题更有利，比如模拟和禁用各种功能，强制使用 prefers-color-scheme 功能或打印媒体类型，以及禁用本地字体。

Performance Monitor

另一个检查 CSS 代码性能的工具是 Performance Monitor。要启用它，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键，输入 Performance Monitor，然后选择 Show Performance Monitor 选项。我通常使用这个工具来查看与页面交互或动画发生时会触发多少次重新计算和布局。

Performance Panel

在 Performance Panel 上，我们可以详细查看页面加载过程中的所有浏览器事件。要启用性能工具，我们可以使用 ⌘ ⇧ P 或 Ctrl ⇧ P 快捷键，输入 Performance，选择 Show Performance，然后点击 “重新加载” 图标。我通常会启用 Screenshots 和 Web Vitals 选项。对我来说，最感兴趣的是First Paint、 First Contentful Paint、Layout Shifts、 Largest Contentful Paint这几个指标。

还有一个饼图显示了绘制和渲染时间。

DevTools 可能不算是一个经典的检查工具，但它可以帮助我们了解哪些 CSS 功能被使用，代码的效率，以及代码的执行情况，而这些都是 CSS 代码检查的关键所在。

在线工具

DevTools 只是用于检查css的其中一个工具，下面介绍一下其它可用来检查 CSS 代码的工具：

Specificity Visualizer

Specificity Visualizer显示代码库中 CSS 选择器的特殊性。只需访问网站并粘贴 CSS。
主图 Main Chart 会显示特定样式与样式表中的位置的关系。另外两个图表显示了特定样式的使用情况。我经常使用这个网站来寻找 “bad” 选择器。例如，如果我看到许多特定样式被标记为红色，我很容易得出结论 —— 这里的 CSS 代码可以改进得更好。在你努力改进时，保存截图以供参考是很有帮助的。

CSS Specificity Graph Generator

CSS Specificity Graph Generator是一个类似的可视化特定样式工具。它显示了一个略有不同的图表，可能会帮助你看到你的 CSS 选择器是如何按特定样式组织的。正如它在工具页面上所说的那样，”波峰是不好的，总的趋势应该是在样式表的后期有更高的特定样式”。进一步讨论这个问题会很有意思，但这不在本文的讨论范围内。然而，Harry Roberts 在他的文章 “The Specificity Graph” 中确实广泛地写到了这一点，值得一试。

CSS Stats

CSS Stats 是另一个为你的样式表提供分析和可视化的工具。事实上，Robin 在不久前写过关于它的文章，并展示了他如何使用它来审核他工作中的样式表。
你需要做的就是输入网站的 URL，然后点击 Enter。这些信息被分割成有意义的部分，包括了样式的声明数、颜色、排版、z-index 和特定样式等等。同样，你可能要把截图存储起来，以备日后参考。

Project Wallace

Project Wallace 是由 Bart Veneman 开发的，而他已经在 CSS Tricks 上介绍了这个项目。Project Wallace 的强大之处在于，它可以比较和可视化基于导入的变化。这意味着你可以看到你的 CSS 代码库以前的状态，并看到你的代码在不同状态之间的变化。我觉得这个功能相当有用，特别是当你想说服别人代码是改进过的。该工具对单个项目是免费的，并为更多项目提供付费计划。

CLI 工具

除了 DevTools 和在线工具，还有命令行界面（CLI）工具可以帮助我们检查 CSS：

Wallace

我最喜欢的 CLI 工具之一是Wallace。安装后，输入wallace，然后输入网站名称，它就会自动输出显示了你需要知道的关于网站的 CSS 代码的一切。我最喜欢看的是 !important 的使用次数，以及代码中有多少个 ID。另一个信息是顶级特定样式的数量以及有多少选择器使用它。这些可能是 “坏” 代码的危险信号。
我最喜欢这个工具的地方是，它可以从网站中提取所有的 CSS 代码 —— 不仅是外部文件，还能够包括内联代码。这就是为什么 CSS Stats 和 Wallace 的报告不匹配的原因。

csscss

csscss CLI 工具可以显示哪些规则共享相同的声明，而这对于识别重复的代码和减少编写的代码量是很有用的。在这样做之前，我会三思而后行，因为这可能是不值得的，尤其是在今天的缓存机制下。值得一提的是，csscss 需要 Ruby 运行环境。

其他有用的工具

Color Sorter — 先按色调，再按饱和度对 CSS 颜色进行排序。
CSS Analyzer — 对一串 CSS 进行分析。
constyble — 这是一个基于 CSS Analyzer 的 CSS 复杂性分析器。
Extract CSS Now — 从一个网页中获取所有 CSS。
Get CSS — 从一个网页中获取所有的 CSS。
uCSS — 抓取网站以识别未使用的 CSS。

结语

CSS在我们周围无处不在，我们需要将其视为每个项目的头等公民。如果您的CSS井井有条且编写精良，那么您将花费更少的时间调试它，而将更多的时间用于开发新功能。在理想的世界中，我们会训练每个人都编写出色的CSS，但这需要时间。

今天是开始关心CSS代码的日子。

我知道审核CSS对每个人都不会很有趣。但是，如果您针对这些工具中的任何一个运行代码，并尝试甚至改善CSS代码库的一部分，那么这篇文章就完成了它的工作。

最近，我越来越多地考虑CSS代码，并且试图使更多的开发人员更加尊重CSS代码。我甚至开始了一个新项目css-auditors.com，该项目专门用于审核CSS。

gatsby

发表于 2021-03-19 分类于前端

esbuild

发表于 2021-03-19 分类于前端

度量DevOps四个关键指标

发表于 2021-03-01 分类于工作

交代

最近看了篇Google出的关于DevOps的文章《度量DevOps四个关键指标》，在这儿做个记录。google翻译+蹩脚的自我理解，莫吐槽，将就看。

开始

通过六年的研究，DevOps研究与评估（DORA）团队确定了四个关键指标，这些指标指示了软件开发团队的绩效：

部署频率 - 成功发布产品的频率。
变更前置时间 - 变更从提交到发布所需要的时间
变更失败率 - 发布失败次数在部署中的占比
恢复服务的时间 - 从生产故障中恢复需要多长时间

变更的部署频率和变更前置时间可以衡量速度，变更失败率和恢复服务的时间可以衡量稳定性。通过衡量这些价值，并不断进行迭代来改进它们，团队可以取得更好的业务成果。

然后说了一下google cloud的做法。后面跟google cloud提供的服务有关的就不翻译文字了。

指标计算

本节讨论如何将DORA度量标准转换为系统级计算。DORA团队所做的原始研究是对真实的人进行调查，而不是收集系统数据并将指标存储到性能级别中，如下所示：

部署频率

1	一个组织成功地部署到生产环境的百分比。

部署频率是最容易收集的指标，因为它只需要一个表。但是，频率存储也是要计算的棘手元素之一。显示每日部署数量或每周获取平均部署数量将很简单明了，但指标是部署频率，而不是数量。

在“Four Keys”脚本中，当每周至少进行一次成功部署的中位数天数等于或大于三时，“部署频率”将落入“每日”时段。简而言之，要想部署频率值为“每日一次”，则必须在大多数工作日进行部署。同样，如果大多数部署都是一星期一次，则将是每周一次，然后是每月一次，依此类推。

接下来，则需要考虑是基于哪些原因及资源构成了成功的生产部署。您是否包括仅占5％流量的部署？80％？默认情况下，仪表板包括任何成功部署到任何级别的流量。

变更前置时间

1	一次提交进入生产环境所花费的时间。

“变更前置时间”度量标准需要两个重要的数据：何时发生提交和何时进行部署。这意味着对于每个部署，需要维护对应的更改的列表。使用部署表中的更改列表，每次数据的重新加入时同时获取相应的时间戳，用于计算中位数。

变更失败率

1	用于生产环境部署失败的百分比

变更失败率取决于两件事：尝试了多少次部署，多少次导致生产部署失败？

恢复服务的时间

“组织从生产故障中恢复需要多长时间”

要测量恢复服务的时间，您需要知道事件的创建时间和解决时间。还需要知道何时发生故障以及何时部署解决了该故障。与上一个指标类似，此数据可以来自任何故障管理系统。

仪表板

这个就不多说了。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

数字化

发表于 2021-02-05 分类于杂记

看到DXCon一篇文章，做个记录

怎么理解数字化转型？

优化是通过把你的服务线上化，减少摩擦，提供更好的服务体验。

那数字化转型真正转的应该是什么？

数字化转型，最终转的是客户价值的创造。

通过数字化智能化的方式，使原来没有办法传递的价值，现在可以传递出去。最终的目的是创造一种模式，不管是商业模式，还是运营模式，使得能够颠覆原来没办法做到的事情，或者是原来很难做到的事情。通过数字化来达成原来不可能达成的价值创造的一种方式，最终的核心应该是要创造价值。

通过数字化来达成原来不可能达成的价值创造的一种方式，就是数字化最终的目的应该是要创造价值。

最后来句废话

我从参加工作开始几乎都是在ToB行业，刚好有两家公司就是干数字化转型的，我一开始的理解不过是从纸质媒介转到网络媒介，从线下到线上，实操经验告诉我，最终看的还是为用户创造了哪些价值，实用为主的客户你跟他扯概念鸟用没有。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

pnpm

发表于 2021-01-13 分类于工作

背景

因为最近遇到一个包多版本依赖的问题，遂研究研究npm包管理…

结果发现了这个宝藏**pnpm**

https://zhuanlan.zhihu.com/p/137535779

PNPM

pnpm使用内容可寻址文件系统将磁盘上所有模块目录中的所有文件存储在磁盘上。

使用pnpm，lodash将存储在可寻址内容的存储中，因此：

如果您依赖lodash的不同版本，则仅将不同的文件添加到存储中。如果lodash有100个文件，而新版本仅对其中一个文件进行了更改，则pnpm update将仅向存储添加1个新文件。

所有文件都保存在磁盘上的单个位置。安装软件包时，它们的文件从该单个位置链接，不占用额外的磁盘空间。使用硬链接或ref链接（写时复制）执行链接。

结果，您在磁盘上节省了数GB的空间，并且安装速度大大提高了！如果您想了解有关pnpm创建的唯一node_modules结构以及为什么它可以在Node.js生态系统中正常工作的更多详细信息，请阅读这篇小文章：平坦的node_modules不是唯一的方法。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

PO和研发免干架沟通指南(1)

发表于 2020-12-29 分类于工作

新产品线跑了一段时间了，这两天团队复盘了一哈，其中谈到了产品和研发沟通问题。

简单记录一下

梳理了这么一个公式

我做了xx设计(实现)

1.xx
2.xx
3.xx
能达到xx效果

1.xx
2.xx
3.xx

point来了，我分割一下
它的限制是什么

1.xx
2.xx
3.xx

导致达不到xx效果
1.xx
2.xx

切记

所以说做东西别上来先傲娇吧啦吧啦说一通，报喜不报忧，后面只会任由PO摩擦。

问题解法咋聊(1)

发表于 2020-12-19 分类于工作

背景

因为团队内部经常会有问题复盘以及技术故事讨论等活动，怎么让这个讨论是有营养且找到根因，保证最终能落到具体的行动项上面。我觉得这是一门很大的学问。

不信你留心观察你参加相关会议或者讨论，你会发现弄了半天问题好像解了又好像没解，过程可能还会伴有撕逼和甩锅…，有句古语说得好：我在旁边坐，锅从天上来。

那咋聊呢

Point 1 描述问题

描述问题，切忌采用下结论的思维和话语，比如：我认为、我觉得…。

我们是为了解问题的，所以你只需要言简意赅的把问题说清楚，这个时候你是一个莫得感情的机器。

怎么言简意赅呢?

站在第三视角陈述：只说现象不说结论，时间、环境、人物、操作过程、发生的现象、造成什么影响…。

如果有必要还可以进行一个动作：过程还原

直接叙述工作过程，有问题的环节或阶段，什么人，做了什么事，当时是怎么考虑的，在这个动作后结果是什么。

Point 2 根因分析

描述之后这个时候可以说说自己的看法了：描述最终定位到的直接原因是什么

有个模板可参考

1.技术根因分析

引入环节：

产品设计是否有问题？

需求分析是否有问题？

设计环节是否有问题？

代码编写是否有问题？

其他？
流出环节：

各评审环节是否有遗漏？

是否进行研发自测？

测试场景、测试用例是否覆盖全？

是否进行了系统测试？

其他？
确定关键根因是什么：

如果有多个根因在逻辑层次上相同，则取关键的原因，根因应该是具体的、客观的、在目前组织能力下可被改进的。

2.管理根因分析

流程/制度原因：
组织因素：
执行原因：

【帮助】流程/制度方面：考虑组织管理上是否有合适的流程、指导书、管理Checklist；

组织因素方面：考虑人员分配、个人技能、培训、组织环境等原因；

执行方面：考虑计划、监控、沟通方面的原因。

这个活动一定要有被随便蹂躏的那种奔放和豁达！！！

Point 3 纠正、预防措施

分析完了之后，一定要有落地的行动项。

根本原因	措施类型	措施内容	责任人	预定完成日期
技术根因：例如，XX特性，在大规格、灵活配置等方面需求设计不充分	纠正措施	例如：对XX特性组织进行重新设计，刷新XX方案	Jack Ma	2020/11/1
	预防措施	例如：更新××技术规范、工具、checklist等等	Pony Ma	2020/11/1

敏捷

发表于 2020-12-17 分类于工作

背景

前前后后经历了几个公司敏捷的做法，有些些感悟，在此表一表。

开始

首先咱们说一下为啥需要敏捷，因为敏捷的业务目标是更早的交付价值以及更灵活的应对变化。我认为这是之所以那么多公司或者团队想要实践敏捷的最大原因之一。

让我知道敏捷的公司，那是在14年我进了一家主打3D数字建模的公司，我的直接领导是公司敏捷的推崇者，当时两个研发团队也是按照敏捷走的，但是敏捷到底是个啥？当时老大给了我一本书让我自己去悟。书名好像是《Scrum敏捷软件开发》。之后大体有了个了解，至少对站会、用户故事、backlog、sprint、SM、PO等词有个概念。

那时候觉得挺新鲜因为在此之前我只知道瀑布模式。在这家公司时我对敏捷印象是最深的，因为我经历了新旧之间的碰撞，不仅是思想上的还有实操上的。因为公司还有个管评审的年长型主管A大，他刚好更偏向于瀑布模式。

正文

chapter 1 ：

先交代一些往事，当时的我，迷茫的一逼，感觉写代码不适合我，我想要转产品，当然我说的产品不是UE性质那种产品哈，我说的是正儿八经的那种产品经理，“那种”指的是：从0到1打造适合用户且用户要买单的那种产品的产品经理。

刚好我的leader就有个类似经历的人，他曾经因为在上海的一个研究所交付的产品令客户不满意，他去呆了3个月，硬生生从0到1重新根据需求设计产品，最终成功交付，当时研究所的人对他的评价是，他比我更懂我得工作。不然为啥他被现在的公司拉去当了副总？你品一品他当时只是一个研发岗。

我虽然面试的是开发岗，刚好当时负责面试的人有事出去了，他刚好遇到了就说先跟他聊一聊，当我告诉他有意向走产品的时候，由于聊的很好，他果断把我留下来当他的助手了。所以我入职是没有经过技术面试的…。

入职的title是产品助理，前期主要干的事就是看书，用Latex写公司宣传文档和摸鱼，后期就让我跟项目，主要是做项目需求。

由于我们的客户多是各种工厂所以通常位置都比较偏僻，想去泡个脚都要摩托转公交再转出租的节奏。

犹记得当时把我一个人丢到工厂的时候，那种无助…工厂里的人通常都比较务实比较直接。被怼的体无完肤到和颜悦色，中间也就是几顿酒的事….故事太多以后写小说再用。

说这些是怎么个意思呢？其实没啥意思，就是说说一些背景，任何事物都是有联系的，你再细品。

chapter 2：

接上，在工厂第一次差不多进一个月，工作内容就是梳理各个环节各个干系人的需求，并整理成文档。

感觉终于告一段落之后，速度赶回北京。然后就是评审，这个时候问题就来了，我老大觉得现有的需求可以开始准备进入研发了，遇到需求问题再澄清就行，但是评审主管就不干了，说你这需求文档需要细化的地方还有挺多，不能进入研发，所以评审没过。会后两位大佬分别拉我谈了一次，一个觉得需求不够完整（瀑布），一个觉得需求已经够了（敏捷）。那为什么双方没有达成一致呢，在我看来当时我老大推崇的敏捷没有玩好，比如A提的一点，研发是敏捷了节奏都挺快，交付周期也缩短了，但是交付结果不太好，老有返工，导致一个项目迟迟不能最终验收，这就是A不赞同的根本原因，因为连客户想要什么都没有完全搞清楚。

对应到敏捷里的内容就是，在检视和调整两块没有足够重视。也就是下面的几个会议没有开好：

Sprint 计划会议
每日 Scrum 站会
Sprint 评审会议
Sprint 回顾会议

我理解以上四个会议就是每个迭代里防止走偏的措施，但最后还是走偏了。

chapter 3：

现公司一进来就是敏捷，但是大多数时间也是走的不顺，有段时间还专门找了教练带着跑了几个月，效果也是一般般。

当时我想了想可能原因有下面几方面：

公司是家传统意义上的软件公司，前面都是瀑布模式，虽然是新产品线但是也有很多老员工，所以不管从公司还是从人来说，这个转变是需要时间且需要强有力的刺激，很明显是时间给够了但是刺激不够。我们都知道有刺激才会有反应。
大家对敏捷的理解参差不齐，很多朋友是随波逐流，且最致命的是这类朋友基本上都认为自己是懂敏捷的，但是真的懂吗，大概率不是的或者只停留在字面上的理解（我其实也是一知半解）。

敏捷应用其实在我看来是一系列的动作的组合，该套组合需是不断优化且需要组织严格遵守的，组合好之后，把该组合套在软件的开发周期里，然后一遍一遍的重复重复再重复。

另外很多人的误解是，敏捷就不用写任何文档了，在我看来不是的，必要的文档还是需要的比如设计文档。

前段时间公司大佬给够了刺激，比如重新梳理组织架构、丰富了工具、完善了开发/评审流程（必要的设计文档等）、强制执行双周迭代、双周演示会等等，我的感受是团队的流转效率是有提高的。

小结

我理解的敏捷其实是门大学问，不是只有简单的一些关键词，比如还有“以赋能和信任个人为中心的文化”这类的理念内容，持续学习中。

所以其实我没啥发言权，不过随便说说，也没谁管得着，反正是我自己的博客….。

从我的经历来看，敏捷是个好东西，但是落地也确实不容易，除了敏捷本身就代表一种变革（动作大）以外，它本身也涉及到很多关于人的因素，比如人的思维、习惯、团队文化等，但是如果因为对敏捷应用的不成功，就觉得敏捷不好用，并怀疑它的价值，不可取哈。

另外敏捷只是解决问题的一种方式，也不要把它捧得太高。

任何方法或者工具都有它所适用的上下文。

我认为敏捷是解决问题的一种方式，技术越来越多成为变现的一种手段。那当然你会问谁先行呢？思维观念要变，同时也需要给搭配上不同的手段，谁先谁后并不是主要矛盾。— DXcon

敏捷的价值观

摘自<说透敏捷>

个体和交互胜过过程和工具。
可以工作的软件胜过面面俱到的文档。
客户合作胜过合同谈判。
响应变化胜过遵循计划。
虽然右项有价值，但我们更重视左项。

一个公司或者团队要应用敏捷，不代表要全套接收，有可能只需要敏捷里的某块就可以，不信谣不传谣。

真正的敏捷应该是Be Agile而不是Do Agile。在我们强调/争执xx方法论，xx实践的时候，我们往往在做敏捷，而不是真正的敏捷了。

多说一句

团队，除了学会传统”规划、组织、领导、控制 “的管理方式之外，还需要”激励、授权、支持、交流 “，这实际上意味着，领导者(特别是CEO)把资源分配采取分布式，而不是集中制(集中在自己手里)。这对团队/组织/公司，在应对复杂、即时、阶层式问题时的灵活度、适应度增加很多。

coolshell软件公司的两种管理方式

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

AHA

发表于 2020-12-01 分类于编程

[Collin Armstrong](https://unsplash.com/@brazofuerte)

背景

干研发的有个高频词语：抽象，这个词语可应用于各种场景，我今天聊的是代码抽象，在此篇就比较low逼的理解成代码复用吧，不然感觉有点虚。

为啥记录这个呢还是源于近段时间遇到的一些矛盾，重复代码该不该都抽出来，在这之前我会毫不犹豫的说应该，包括现在团队里也几乎是这样的声音，但是是不是就一定对呢？现在我觉得这个观点是不对的，因为我发现有些代码抽出来之后反倒变得越来越不可掌控。

所以我在思考克制抽象是不是也应该提出来。为了验证这个思考，遂搜了搜，别说还真有那么些大佬早就提出了这个观点。

AHA

AHA (读作”Aha!” ):Avoid Hasty Abstractions（避免草率的抽象）

读了几篇文章特别感动，尤其是Sandi Metz的 The Wrong Abstraction，特别有共鸣。

核心观点就是

宁愿复制而不是错误的抽象

具体的支撑克制抽象内容，这几篇文章说的很清楚了，我就不再来一遍了。

我就给个现实的例子

/**
 * 获取某个CI模型数据 v1.0
 * @param {object} code 模型code
 * @returns {object}  格式化之后的模型对象
 */
export const getCi = async (code) => {
  const meta = await request.post('/api/v1/model/ci/getCi', { code });
  // 绑定数据字典
  meta.attributes = meta.attributes.map((item) => {
    const attr = { ...item };
    if (attr.changeValue === 'dict') {
      if (!DICT.get(attr.code)) {
        rlog.error(`找不到 ${attr.code} 对应的数据字典`);
      } else {
        attr.dict = DICT.get(attr.code).items;
      }
    }
    return attr;
  });
  return meta;
};

/**
 * 获取某个CI模型数据  v2.0
 * @param {object} code 模型code
 * @param {boolean} userVisibleFilter 是否按照模型的userVisible过滤，发现页面不过滤
 * @returns {object}  格式化之后的模型对象
 */
export const getCi = async (code, userVisibleFilter = true) => {
  const meta = await request.post('/api/v1/model/ci/getCi', { code });
  // 获取过滤userVisible=true的属性(用户可见)
  const { attributes } = meta;
  const visibleAttributes = userVisibleFilter
    ? attributes.filter((item) => item.userVisible)
    : attributes;
  // 属性绑定数据字典
  meta.attributes = visibleAttributes.map((item) => {
    const attr = { ...item };
    if (attr.changeValue === 'dict') {
      if (!DICT.get(attr.code)) {
        console.error(`找不到 ${attr.code} 对应的数据字典`);
      } else {
        attr.dict = DICT.get(attr.code).items;
      }
    }
    return attr;
  });
  return meta;
};


/**
 *
 * 获取某个CI模型数据 
 * @param {object} code 模型code
 * @param {boolean} userVisibleFilter 是否按照模型的userVisible过滤，发现页面不过滤
 * @param {boolean} dict 是否需要绑定数据字典
 * @returns {object} 格式化之后的模型对象
 */
export const getCi = async (code, userVisibleFilter = true, dict = true) => {
  const { meta, visibleAttributes } = await formatMeta(code, userVisibleFilter);

  if (!dict) {
    meta.attributes = visibleAttributes;
    return meta;
  }

  // 属性绑定数据字典
  return bindDict(meta, visibleAttributes);
};

/**
 *
 * 获取某个CI模型数据  v3.0
 * @param {object} code 模型code
 * @param {boolean} userVisibleFilter 是否按照模型的userVisible过滤，发现页面不过滤
 * @param {boolean} dict 是否需要绑定数据字典
 * @returns {object}  格式化之后的模型对象
 */
export const getCi = async (code, userVisibleFilter = true, dict = true) => {
  const meta = await formatVisibleAttributes(code, userVisibleFilter);
  if (!dict) {
    // 属性绑定数据字典
    return bindDict(meta);
  }
  return meta;
};

/**
 *
 * 获取某个CI模型数据  v4.0
 * @param {object} code 模型code
 * @param {boolean} userVisibleFilter 是否按照模型的userVisible过滤，发现页面不过滤
 * @param {boolean} dict 是否需要绑定数据字典
 */
export const getCi = async (code, userVisibleFilter = true, dict = true) => {
  const meta = await formatVisibleAttributes(code, userVisibleFilter);
  // 属性绑定数据字典
  if (dict) {
    try {
      // 用户自建属性（数据字典）
      const userDict = await getUserDicts(code);
      return bindDict(meta, userDict);
    } catch (error) {
      rlog.error(error);
      return meta;
    }
  }
  return meta;
};

/**
 * 过滤可见属性
 * @param {string} code
 * @param {boolean} userVisibleFilter
 * @returns {object}  只包含可见属性的模型对象
 */
async function formatVisibleAttributes(code, userVisibleFilter) {
  const meta = await request.post('/api/v1/model/getCi', { code });
  if (meta) {
    let { attributes } = meta;
    if (!attributes) {
      return meta;
    }
    // 适配后端，使属性正序
    attributes = attributes.reverse();
    // 获取过滤userVisible=true的属性(用户可见)
    if (userVisibleFilter) {
      meta.attributes = attributes.filter(
        (item) => item.userVisible === 'true'
      );
    }
    return meta;
  }
  return meta;
}

如上所示

总共经历了至少4次的改动，逻辑变得越来越复杂，因为需要适配多种场景，本来我一开始抽出来，理由很简单，因为该api是一个获取底层数据的api，大多数前端的功能都需要调用该api，且都是需要有数据字典的，因为要正确的展示数据，所以我抽了一个方法。

这个时候还是很美好的，不过后续就像 The Wrong Abstraction里写的一样，各个使用方或找我或自己对该方法进行了扩展，这方法那是叫惨不忍睹啊，就这还是我重构之后的样子，没重构之前更丑。

那有人就问了，为什么就扩展了呢？

个人风格问题，该方法之前满足我得需求现在不满足了，所以我要改它，这样最简单，我可不管其它模块需不需要这个逻辑。

我也知道可能在上面加不太合适，因为加的扩展逻辑不是所有模块都需要的，但是也不是我一个人需要的，比如A、B、C、D…，A、B都需要，那为了不重复写代码，在原有方法上扩展我觉得也还行。

…

后来当我发现的时候，我就在群里发出了一个共识。

这类公共的api原则上不加个性化的扩展但是可加通用性（不影响整体数据结构且没有业务逻辑，比如：对原始数据进行数据筛选（eg:可见、不可见））的扩展，且加的时候需要与该api的最初作者对齐。

如果要扩展个性化，请自行copy一份代码再修改。

我的理由是如果再这么搞那我就不维护了爱咋咋滴………………..当然前面是意淫的咱们是一个team，和为贵。

真正的理由是维护成本会越来越高且与当初抽象的意义渐行渐远。

可能我给的例子不够有足够力量的说服力，但是我还是觉得，抽象不一定就一定时好的必须的，有些时候我们得反过来想想，任何事情都有两面性。虽然咱没有能力提出牛逼得理论和观点，但是我们可以基于大佬们提出得理论和观点，做些反思、验证…。

有句话不是说吗：站在巨人的肩膀上。这句话我理解不是说巨人的肩膀才稳，而是说能看得更远。

You Know

Duplication is far cheaper than the wrong abstraction

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。