边开发边优化代码

最受欢迎的开发端点

我们来假设一下……

优化选项

太长不看

我始终主张在编写代码时，无论开发的产品规模大小，都应该考虑可扩展性和优化。很多人认为，如果不需要优化，就没必要优化，那样只会浪费时间。没错，优化有时确实需要花费一些额外的时间，但从长远来看，这点时间可以避免很多麻烦。

我说的不是要重新架构整个功能，而是你在编码过程中可以做的一些小优化，我保证这些优化将来会产生影响。在这篇文章中，我将通过一个我最近在开发团队中做的优化示例（通过这个 pull request），来说明我们原本是如何避免创建这个 pull request 的。

最受欢迎的开发端点

每次加载开发页面时，我们都会发起一个异步调用来获取一些用户数据，以便填充视图中的变量。这些用户数据来自某个端点async_info/base_data。由于每次页面加载都会发起此调用，因此它的访问量远高于我们访问量最高的端点。顶部的紫色线条显示了对该端点的调用次数async_info/base_data。

鉴于我们频繁调用这个接口，我决定仔细检查一下，确保它尽可能简洁高效。我做的第一件事就是查看我们返回的哈希值的构建方式。以下是我修改前的哈希值：

{
  id: @user.id,
  name: @user.name,
  username: @user.username,
  profile_image_90: ProfileImage.new(@user).get(width: 90),

  followed_tag_names: @user.cached_followed_tag_names,
  followed_tags: @user.cached_followed_tags.to_json(only: %i[id name bg_color_hex text_color_hex hotness_score], methods: [:points]),

  followed_user_ids: @user.cached_following_users_ids,
  followed_organization_ids: @user.cached_following_organizations_ids,
  ...
}

请注意，我们有两个不同的标签字段返回相同的数据。我不知道哪个字段是先添加的，但为了便于举例，我们假设它followed_tag_names是第一个添加的字段。

我们来假设一下……

假设你是之前的开发者，正在followed_tags向哈希表中添加值。你需要视图中的所有标签信息，而不仅仅是标签名称，所以你将新字段添加followed_tags到了哈希表中。很多开发者到此为止。他们已经掌握了所需的信息，工作就此完成。

这时我要说，别停！花点时间看看你的哈希值。你现在为了获取相同的标签信息，竟然进行了两次调用。虽然在哈希值不经常生成时这可能没什么问题，但当你的网站开始火爆，每天生成数百万次哈希值时，这绝对不是理想的做法。额外的调用会累积起来，造成很大的性能损失。与其停下，不如花几分钟时间处理一下这段不优化的代码，这样就能轻松解决这个问题，避免日后出现很多麻烦。

优化选项

以下是我在优化这段代码时考虑的两种方案。

1）我们可以将标签缓存到一个变量中，然后在哈希表中引用该变量，如下所示。这样可以避免额外的数据库访问，并确保我们不会将资源浪费在冗余调用上。

tags = @user.cached_followed_tags
{
  id: @user.id,
  name: @user.name,
  username: @user.username,
  profile_image_90: ProfileImage.new(@user).get(width: 90),
  followed_tag_names: tags.map(&:name),
  followed_tags: tags.to_json(only: %i[id name bg_color_hex text_color_hex hotness_score], methods: [:points]),
  followed_user_ids: @user.cached_following_users_ids,
  followed_organization_ids: @user.cached_following_organizations_ids,
  ...
}

2) 如果我们既不想进行额外的数据库调用，又想避免发送重复信息，我们可以采用我在pull request中提供的解决方案。在 pull request 中，我移除了该followed_tag_names字段，并更新了视图代码，使其能够解析该字段中的 JSON 数据followed_tags。我选择这种方法是因为它既可以减少一次数据库调用，又可以减少与服务器之间的数据传输量。

const followedTagNames = JSON.parse(currentUser.followed_tags).map(t => t.name);
...
<ReadingList
  availableTags={followedTagNames}
  statusView={root.dataset.view}
/>,

太长不看

花几分钟时间检查一下代码，思考一下扩展性，至少可以帮你省去以后的一些麻烦。往好了说，这还能避免应用在用户激增时出现严重的运行缓慢。

祝您扩展愉快！