---
title: 网络摩擦与云端 build 优先
date: '2019-03-08 14:54:49'
draft: false
summary: 很多开发效率损耗并不来自编码本身，而是来自拉源码、下依赖和装工具这些被环境持续放大的外围摩擦。
slug: network-friction-turns-build-into-cloud-build
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/HjXRdcSl4
tags:
- developer-experience
- build
- circleci
- network
topics:
- software-engineering
type: post
---

有段时间外网很不稳定，`build` 代码、拉依赖、装工具，经常卡到怀疑人生。最后我被迫启用了一个很现实的办法：直接把改动推到仓库，交给 `CircleCI` 在云端构建。

这件事最让我有感触的，不是“云端构建真方便”，而是很多开发效率损耗，其实根本不发生在写代码的时候。

真正持续吞时间的，是这些外围动作：

- 拉源码
- 下载依赖
- 安装工具
- 搜索资料
- 获取镜像和构建环境

如果这些动作长期受网络摩擦影响，开发者的体验就会逐渐从“本地开发”退化成“先想办法绕开环境问题”。

所以我会觉得，很多时候我们高估了“工程师加班”的有效工作时长。表面上看大家都在努力写代码，实际上其中很大一部分时间，被各种环境摩擦一点点吃掉了。

而且这种摩擦并不只是网络带宽问题。

如果只是单纯带宽不足，理论上还可以通过 `CDN`、镜像加速、区域节点这些方式来逐步缓解。但一旦网络限制和制度限制叠在一起，问题就不再只是“慢”，而是很多全球通用的基础设施根本没法自然连通。

结果就是，一个本来应该统一的大互联网，被切成了多个体验完全不同的局部网络。开发者在不同区域面对的，已经不是同一个默认世界。

这件事最终会反向塑造工作流。

比如：

- 能放到云上跑的构建，就尽量放云上。
- 能通过 `CI` 完成的下载和集成，就不要本地反复重试。
- 本地环境越来越像编辑器和提交器，真正重的构建逻辑迁到远端。

这未必是最理想的开发模式，但在高摩擦环境下，它往往是更现实的生存方式。

所以问题的关键已经不只是“某一次网络抖动”，而是当外围摩擦长期存在时，它会慢慢重写整个工程实践的默认形态。

<!-- WEIBO_MEDIA_START -->
## 原微博中的媒体

![](./weibo-4347583273068818-1.jpg)
<!-- WEIBO_MEDIA_END -->