停止“Saving Keystrokes”。我花3秒钟省下3小时

Source: Dev.to

我们都有过这种经历。

你正进入状态。逻辑流畅，音乐嘹亮，你只需要在 map 函数里临时保存一个用户对象。

你可以输入 updatedUserObject。

但那是 17 个字符。

更快的办法是什么？u。

u 只有一个字符。高效、快捷。你现在就知道 u 代表什么。于是敲进去，代码编译通过，你感觉自己很有生产力。

你刚刚给未来的自己埋下了陷阱。

这就是 Junior Trap（初级开发者陷阱）——击键节省者。

它基于一个谎言：认为打字速度是软件工程的瓶颈。

事实并非如此。真正的瓶颈是 阅读理解。

意图词典

当我们使用像 data、item 这样的通用名称，或像 x 这样的单字符时，我们就在隐藏信息。我们把上下文从逻辑中剥离。

要理解一个充斥着 x 和 d 的函数，阅读者（很可能是六个月后的你）必须在脑中保持整个程序的逻辑，才能理清发生了什么。你在为省下 0.5 秒的敲键时间而消耗团队成员的 认知 RAM。

变量名不仅仅是标签；它是意图的定义。

初级陷阱：“击键节省者”

“我只把这个变量命名为 u 而不是 updatedUserObject，因为敲起来更快。我现在知道它的含义，所以没问题。”

专业做法：“自动补全依赖”

专业的初级开发者知道，代码是写给阅读的，而不是写给敲键的。

我们生活在 IDE 的黄金时代。VS Code、WebStorm、IntelliJ 都比我们更聪明。它们拥有自动补全。

策略：先一次敲出完整、描述性、能体现意图的名字，然后一直按 Tab 完成。

我们乐于用现在的三秒敲键，换取后期三小时的调试时间。当你使用描述性名称时，无需阅读前面二十行代码就能明白变量保存了什么。变量本身已经告诉你了。

代码示例：“数据倾倒” vs. “故事”

// 之前（神秘盒子）

// 'data' 可能是任何东西。
// 我们必须在脑中把 'data' 映射为 '天气 API 响应'
// 把 'v' 映射为 '温度值'。
const data = getInfo();

if (data) {
  const val = data.v;
  // 如果我单独阅读这一行，根本不知道发生了什么。
  updateUI(val);
}

// 之后（意图明确）

// 即使不看文件的其余部分，也能准确知道这是什么。
const weatherReport = fetchWeather();

if (weatherReport) {
  const currentTemperature = weatherReport.degrees;

  // 这一行读起来像一句英文句子。
  updateUI(currentTemperature);
}

羞耻之墙

如果在代码审查（或你自己的 PR）中发现这些情况，请立即标记。它们是 上下文吸血鬼——把代码的意义吸干。

• data → 什么数据？使用 userProfile 或 transactionList
• item → 哪个条目？使用 cartItem 或 notification
• flag → 真值代表什么？使用 isVisible 或 hasAccess
• arr → 数组里是什么？使用 activeUsers

停止为编译器写代码。开始为人类写代码。

本文摘自我的手册 《Professional Junior: Writing Code that Matters》。它不是 400 页的教材，而是一本关于未成文工程规则的实战指南。

👉 获取完整手册