设计文件与代码的版本需要同步推进
别名: 设计代码锁步 · 双端版本 · lockstep versioning · design library version
概念解释
设计源（组件库文件、变量集、实例）和代码包必须指向同一版本身份。同步推进（design-code version lockstep）不是「两边都偶尔发一版」，而是一次契约变更在两端打上相同的破坏位数、相同的标签，使用方在设计工具里拖出的实例与仓库里安装的包是同一个接口。一边已经拆掉旧属性，另一边还在画那个属性，中间的交付物就会在实现阶段被重新发明。
两端的介质不同：一边是文件里的组件与变量，一边是模块与类型。身份必须可对上——同一个名字、同一组公开属性、同一个主版本。对不上，设计评审通过的画面在代码里没有对应的合法调用。
机制
设计和代码若各养一条发版日历，快的那一端会先改契约。设计先改，工程师打开文件看到的属性在包里还不存在，只能本地先做一版「临时」，临时随后成为产品里的永久分叉。代码先改，设计师仍在往旧实例上叠需求，评审里通过的交互在新包里已经被删除。两端的人都会觉得自己跟上了「最新」，其实各自的最新互相不可调用。
锁步把一次契约变更做成跨介质的同一事件：标签、变更说明、破坏位数同时出现在设计库和代码包上。使用方升级时成对升级，而不是「代码先顶上去、设计库下个季度再说」。对不上的窗口期是缺陷，不是正常的协作缓冲。缓冲越长，两边的实例和调用点越会在窗口里长出无法互相替换的结构。
边界
纯探索稿、不进入交付的草图不必锁版本；锁步从「这张文件会被开发对照」开始。热修只动代码内部、设计实例的公开属性未变时，设计库可以不下新主版本，但补丁号仍应能在设计库的发行说明里查到，避免「代码 1.4.3、设计还停在 1.4.0 且无人知道 1.4.3 发生过」。只有一端存在的系统（没有设计库，或没有代码包）谈不上锁步。第三方设计工具若无法给库打与代码相同的标签，要在文件名或发布记录里手写同一身份，不能假装工具里的「最新」就是代码里的「最新」。
怎么落地
- 一次契约变更产出成对产物：设计库文件与代码包使用同一主.次.补丁，发布说明共用同一份破坏清单。
- 交付清单上同时写「设计库版本」和「代码包版本」；两者不等的交付视为未完成。
- 设计工具里的实例旁显示当前库版本；与仓库锁文件不一致时，在走查里作为缺陷而不是作为备注。
- 验证：抽一个正在开发的功能，读设计文件的库版本与仓库锁文件。不一致则列出两边各自多出来的属性——每一条都是窗口期里会被重新发明的接口。再故意只发代码包、不发设计库，看交付清单是否仍能通过：能通过，锁步就不在流程里。把两端标签做成一条对账表，连续三次发版对不上的，停止再加新契约，先把身份对齐。