硬编码
硬编码像把门牌号刻死在墙上。短期很快,但一旦地址变了,你就得砸墙重刻。代码里如果把路径、颜色、文案、价格或环境地址写死,后面变化会变得又慢又危险。
关键结构图
一个写死的值连到多个组件,修改时每条线都变红;旁边是配置中心只改一次的对照图。
What
硬编码是把本该可配置、可替换或来自数据源的内容直接写死在代码里。
硬编码是一种把可变值、业务规则、配置、文案或路径直接写进代码的做法。它的边界是“变化频率和复用范围”:临时常量不一定有问题,但会随环境、用户、版本或数据变化的内容不应写死。
Structure硬编码 = 可变信息 + 固定写入 + 修改成本上升
When
当同一个值在多处重复、不同环境需要不同值、产品文案会调整、设计 token 会变化,或路径依赖本地机器时,要警惕硬编码。
How
先识别哪些值会变化,再把它们移到配置、数据、常量、schema 或 token 中。修改后用测试和验证确认没有遗漏旧值。
Examples
把 API 地址直接写成本机 localhost,部署到生产环境时就会失败。更好的方式是使用环境变量。
把按钮主色散落写在十个组件里,设计改色时就要逐个找。使用 color token 更稳定。
来源
类型:软件工程实践
事实线:工程项目通常通过配置、环境变量、数据文件、常量模块或设计 token 管理可变内容,避免分散硬编码造成维护风险。
依据:软件配置管理、12-factor app 配置原则、前端设计 token 实践。
边界:适用于需要跨环境、跨页面或长期维护的系统;小型一次性脚本可以适度硬编码。
常见误读:不要把所有字面量都视为坏事。真正危险的是把会变的业务事实写死。