Notes

词是决定的化石

一个项目为什么会有一套自己的词

先说两个具体的选择:

  • 它把部署前那道自检叫闸门,不叫"检查"。
  • 它把照片的原文件叫原片,不叫"源图"或"原始图片"。

这些不是文风偏好。"检查"可以是建议,"闸门"只能是障碍 —— 不通过就过不去;"原片"强调的是"这是不可再生那一份" —— 母图丢了能重转,原片丢了就没了。

所以一个项目长出自己的词,通常意味着它在某些地方做过非此即彼的决定。词是决定的化石。

下面的字典是从仓库里数出来的:README、docs、工具源码、随笔,一共约 36.8 万字语料。先列词,再谈这些词的三种来历,最后老实说三处词在漂的地方。

一、四组区分:每一组都是一处设计

字典之前先看四组。一个项目的结构,往往就藏在"它坚持区分哪两个词"里。

① 源 / 原片 / 母图 / 档位

源     data/ 里的纯文本(photos.json、poems.md、posts/*.md)
原片   data/photos/ 里那张未经处理的原始照片(唯一不可再生的)
母图   由原片转出的工作副本,长边压到设定尺寸
档位   从母图生成的各宽度版本(480 / 900 / 1200 / 1800),给 srcset 用

四个词对应四个阶段。混淆任意两个,就会出两类事故:把母图当原片(丢数据),或者把档位当母图(画质越转越低)。

② 提交 / 发布 / 上线 / 部署

提交  写进 git
发布  整条流程:构建 → 闸门 → 提交 → 上传 → 部署
上线  "让它在线上生效"的日常说法(口语,不是流程节点)
部署  把产物送到服务器并切换(deploy.sh,8 步)

这四个词在别处常被混用成"发一下"。这里必须分开,因为它们失败的后果不同:提交失败,线上没变;部署失败,可能线上是半截。

③ 备份 / 快照 / 回滚点 / 云盘

备份    把东西存到别处(动作)
快照    每日打包的那一份,保留 20 个,粒度是天
回滚点  部署前自动打包的"当时线上那一版",保留 8 个,粒度是"每次发布"
云盘    服务器上那块持久化磁盘(/mnt/cloud)

快照和回滚点不是一回事:一个按天,一个按次;一个用于"回到某天",一个用于"撤销刚才那次发布"。这个区分救过场 —— 部署顺序里"保存回滚点"排在"发布"之前,反过来就是一场事故。

④ 生成物 / 产物 —— 这一组没有区分。见第四节。

二、字典

按主题分五组。(自) 表示项目自造或在本项目里被赋予特定含义,(借) 表示借用日常词汇。

A. 内容与数据

词释义
原片data/photos/ 里那张未经处理的原始照片。唯一不可再生的东西(自)
母图由原片转出的工作副本,后续所有档位从它生成(自)
档位同一张照片的不同宽度版本(480 / 900 / 1200 / 1800),供 srcset 选择(自)
out照片的网站 id:英文小写连字符,同时是生成物的文件名前缀(自)
src原片文件名,即 data/photos/ 里那个(自)
映射原片 ↔ out ↔ 生成物的对应关系,由 data/photos.json 定义(自)
对照表data/manifest.json:机器可读的全站对照,不发布(自)
精选首页那 17 张;顺序由 featuredRank 决定,与摄影页顺序无关(自)
封面首页首屏大图的源片与参数(data/hero.json)(自)
器材机身与镜头清单(data/gear.json);用来校验"机身 + 焦距"是否有镜头对得上(自)
诗文data/poems.md 里的内容,45 首,格式不严格(自)
随笔data/posts/*.md,13 篇(含本篇),头部带 JSON 元信息(自)

B. 构建与检查

词释义
生成物由 data/ 重建出来的文件:页面、图片、脚本里的数据、sitemap。与"源"相对(自)
闸门部署前那道会失败的自检:生成物与源不一致就拒绝发布,连服务器都不连(自)
幂等什么都没改时重建一遍,工作区应保持干净(借)
逐字节验收"改对了"的判据是产物 cmp 相同,不是"看起来一样"(自)
保留注释写回 JSON 时保住手写的 $comment 键与键序(递归合并)(自)
后台自检构建的第 1 步:跑后台的 10 项单元测试(自)
探针一套界面检查。黑盒:只看界面上有没有、点了会不会变(自)
测试面给探针用的内部出口:前端 window.__ADMIN__、后端 /api/debug(自)
体检hsd-healthcheck:站点可达、证书、磁盘、备份完整性,最后给一行结论(借:把机器的检查叫成人的体检)

C. 发布与运维

词释义
提交写进 git。发布流程里排在部署之前,所以仓库记录的就是线上那一份(借)
发布整条流程:构建 → 闸门 → 提交 → 上传 → 部署(自)
上线"让它在线上生效"的日常说法。口语,不是流程节点(借)
部署把产物送到服务器并切换(deploy.sh,8 步)(借)
线上 / 本地对外可达的那一份 / 这台机器上的那一份(借)
回滚点部署前自动打包的"当时线上那一版",保留 8 个(自)
快照每日备份,保留 20 个,粒度是天(借)
云盘服务器上那块持久化磁盘(/mnt/cloud)(借)
不可逆删照片、回滚、覆盖线上:这类动作要额外护栏(借)
护栏加在不可逆动作前的拦截:查封面、查引用、要原样输入(自)

D. 后台与工具

词释义
标签页后台的 10 个功能页(借)
脏 / 脏标记有未保存的改动。角标一个点,顶栏写"有未保存改动"(借)
待提交工作区里还没进 git 的改动。发布前必须摊开给人看(自)
任务锁一次只跑一个任务;跑着的时候写操作一律 409(自)
原样输入不是"确认吗",而是"把名字或版本号打出来"(自)
预览内嵌的本地预览。它读的就是发布时会送上线的那份生成物(自)
孤儿① 没有对应条目的残留文件;② 没被收掉的子进程(自,一词两义)

E. 站点与前端

词释义
占位符模板里用两个花括号标出的值,如站点名、年份(自)
片段用两个花括号加箭头插入的局部模板(如页脚、联系条)(自)
内联 / 预置不放进外部文件的那段主题脚本。必须早于样式表执行,否则浅色模式会闪一下(自)
指纹① 资源 URL 上的 ?v=(缓存失效用)② 图片相似度的 256 位哈希(自,一词两义)
瀑布流摄影页的列式排布,列宽与 CSS 对应(借)
灯箱点开看大图与参数的浮层(借)
懒加载图片进入视口才加载(借)
深浅主题明暗两套配色,偏好存 localStorage(借)

三、词的三种来历:决定、事故、借用

第一类:决定。 比如"闸门"。它不是"检查"的同义词,而是一个决定:这件事没有商量余地。同类的还有"原样输入"(拒绝下意识点击 ✓)、"只读"(运维面板只读,回滚是唯一的例外 ✓)、"不可逆"。

第二类:事故。 有些词是从坑里长出来的。比如"孤儿"(进程收不干净)、"残档"(改名后留下的文件)、"来路不明"(images/ 里没有对应条目的文件)。这些词在项目第一周并不存在 —— 是踩过之后才需要名字的。

第三类:借用。 "体检""上线""云盘""脏"都是从日常词汇借来的。借用的好处是一看就懂,坏处是它带着旧含义:如果"上线"在你的团队里指"合并到主分支",那借用就会误事。

这三种来历,其实对应三种不同的记忆需求:决定要记一辈子(它是规则),事故只在那类情况再出现时才需要(它是索引),借用要定期校准(它会漂)。

四、词会漂:三处如实记下

字典写到最后,发现三处词在漂的地方。不写下来,这份字典就是骗人的。

① 产物 vs 生成物。 数了一下:"产物" 69 次,"生成物" 48 次,指的是同一个东西。这是我自己的混用 —— 两个词都没有错,但同时用就是错。

② 线上(64 次)vs 上线(34 次)。 一个是位置,一个是动作,道理上很清楚;但句子里的界线并不总是清楚,比如"这个改动还没上线"和"这个改动还没到线上"意思一样,用的词不同。

③ 只存在于对话里的词。 "白盒"我常用,但仓库里出现 0 次;"手放""来路不明"只出现在我的随笔里,不在代码与文档里。也就是说:有一部分词是只在"对话现场"成立的方言,一离开现场就没有人知道它指什么。

还有两个一词多义:"指纹"(资产缓存指纹 / 图片相似度哈希)、"孤儿"(残留文件 / 子进程)。这两个在日常使用中靠上下文区分,暂时没造成误解 —— 但它们是字典里最该标红的两条。

五、为什么值得写成字典

因为下一个接手的人,是先学词、再学代码的。

他可以不懂 srcset 怎么算,但必须先知道"原片"和"母图"不是一回事;可以不懂部署脚本,但必须知道"回滚点"和"快照"分别在什么时候用。词错了,代码读懂了也是错的 —— 你会用对的函数做错的事。

反过来说,这份字典也是一份设计的索引:每个词都能指回一处决定 ——

闸门   → 不让不一致的产物出门
原样输入 → 不让不可逆的动作被下意识点掉
回滚点 → 让"先存、后覆盖"成为流程的顺序
测试面 → 让"界面看不出来的错"也有地方被看见

前面那些随笔里写过的东西,其实都能压缩成这几个词。词是压缩过的设计。

结语

这份字典里,我最有把握的是那些因为事故才有的词 —— 它们一定有用,否则不会有人专门给它起名字。

最没把握的是那些借来的词 —— 它们看起来最自然,也最容易在别处被理解成别的意思。

所以如果只留一句话:

词是决定的化石。但化石会风化 —— 借来的词尤其。

Get in Touch

联系

这篇写完之后又踩了新的坑,或者你有别的看法 —— 欢迎写信来聊。