无障碍编程：变量命名里的视障友好之道

　　去年七月份那会儿，我原以为“无障碍编程”就是个公益项目里的小噱头——毕竟咱们写代码的，谁天天盯着变量名是不是对视障开发者友好？结果有天跟甲方吵完需求，他甩过来个链接，说“你们这代码连读屏软件都读不顺，盲人同事怎么用？”。我点进去一看，好家伙，变量名全是一串英文缩写加数字，读屏软件念出来跟念咒似的，什么“btnSubmit2023”“txtNameV2”，听得人直犯晕。

　　那天我盯着屏幕发了半小时呆，办公室空调太冷，冻得手指发麻。手机突然震动，是测试组小王发来的截图——他戴着耳机，屏幕上是代码编辑器，读屏软件正用机械音念：“变量名‘flgIsActive’，当前值：true”。小王在消息里骂：“这念出来是‘flag is active’，谁知道‘flg’是‘flag’的缩写啊？盲人同事得猜半天！”我回他：“要不咱们把缩写全改了？”他秒回：“改？甲方昨天刚催上线，改一个变量名，整个模块的注释、测试用例都得跟着动，烧钱啊。”

文章配图，仅供参考

　　后来跟团队商量，定了条规矩：变量名必须用完整单词，缩写得加注释说明。比如“isUserActive”而不是“flgIsActive”，“userNameInput”而不是“txtName”。改的时候，测试组小李凑过来吐槽：“这得多打多少字？我键盘都要磨秃了。”我怼他：“你少打两局游戏，键盘能用三年。”他撇撇嘴走了，结果第二天跑来说：“哎，读屏软件念‘is user active’的时候，盲人同事居然直接懂了，不用问我‘flg是啥意思’了。”

　　其实最让我意外的是，这改动没影响效率——反而因为变量名更清晰，代码审查时出错率降了。之前用缩写，新人接手项目得先背“缩写词典”，现在直接看变量名就知道干啥用的。有次跟甲方开会，他们盲人测试员说：“以前读代码像听天书，现在至少能跟上思路了。”甲方当场拍板，说以后所有项目都得按这标准来。

　　但说实话，一开始我挺抵触的。觉得“无障碍”是额外负担，跟ROI没关系。直到有天看到个数据：全球有二点八五亿视障人士，其中不少是程序员或测试员——这数字比我想的大多了。我原以为“视障友好”是小众需求，结果发现，它其实是“优胜劣汰”里的“优”——代码更清晰，维护成本更低，团队效率更高，这不就是竞争力吗？

　　现在再写代码，变量名里连“temp”都不用——直接写“temporaryValue”，虽然多打几个字母，但读屏软件念出来顺溜，新人接手也快。有次跟同行吃饭，他吐槽：“你们现在变量名写这么长，不怕影响性能？”我笑：“性能差那零点零几秒，用户感知不到；但变量名读不顺，视障同事能骂你一辈子。”他愣了下，低头扒拉两口饭，说：“回头我也改。”

　　窗外天黑了，办公室的灯亮得刺眼。我盯着屏幕上的变量名，突然想起去年七月那天的冷空调——当时觉得“无障碍”是麻烦，现在才明白，它其实是代码的“基本修养”。就像咱们写广告素材，得考虑不同设备的显示效果；写代码，也得考虑不同用户的“读取”方式。视障开发者不是“特殊群体”，他们是用户的一部分——而用户的需求，从来不该被“优化”掉。

　　下一步怎么试？我打算把这套标准推广到整个团队，甚至跟甲方商量，把“无障碍代码审查”加进验收流程里。至于效果？烧了不少时间改代码，但甲方没砍预算，测试组也没抱怨——反而说“现在改bug都快了”。至于视障同事的反馈？他们说：“终于不用猜变量名了。”这就够了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!