5天啃完一个CI/CD引擎，新人发现架构设计的3个反直觉

去年有个朋友让我看Woodpecker的代码，说是个能本地跑的CI/CD工具。我打开仓库时，Go语言的语法高亮都在嘲笑我——但5天后，我居然能给别人讲清楚它的架构了。

这不是励志故事，是关于新手怎么在陌生代码里找路标的实操记录。

第一天：别急着读代码，先画地图

我花了整整一下午没写一行代码，就在目录里逛。根目录下三个文件夹跳出来：Server、Agent、CLI。当时我就猜到这是个主从结构，但猜错了通信方式。

Server是大脑，Agent是手脚，CLI是给用户用的遥控器。这个分工很常见，但Woodpecker的Agent设计有个别扭的地方——它主动找Server要活干，而不是Server派活过来。这种"反向求职"的模式，让扩缩容变得特别简单：多加几台机器，各自去Server门口排队就行。

gRPC（一种远程调用框架）加Protocol Buffers（数据序列化格式）的组合，我当时以为是性能考量。后来翻issue才发现，作者2019年选型时只是因为"不想写REST的boilerplate"。技术选型有时候就这么随意。

第三天：被阻塞通信坑了一把

Agent的生命周期图我盯着看了20分钟。初始化→连接Server→循环拉取任务→执行→上报结果→等待下一个。看起来是标准的生产消费模型，但有个细节藏得深：上报结果是阻塞的。

这意味着如果Server挂了，Agent会卡在"汇报成绩"这一步，而不是继续干别的。我当时觉得这是bug，去Discord问了一句。维护者回复说：「我们宁可Agent等着，也不想让任务状态丢进黑洞。」

可靠性优先于吞吐量，这个取舍在文档里一个字没提。

新手看架构图容易只数箭头，不看箭头上的时序。阻塞还是异步，往往决定了系统能扛住什么级别的故障。

第五天：发现藏了3年的设计债

代码里有个TODO注释，写于2021年，说"以后要把Agent的心跳和任务执行拆成两个goroutine"。我算了下，这个"以后"已经拖了800多天。

不是没人想改。我翻到一个PR，作者花了两周重构，测试覆盖率从72%掉到61%，被拒绝了。维护者的理由很直接：「CI/CD工具的第一要务是不破坏用户的pipeline，不是代码优雅。」

这个拒绝让我重新理解了"技术债"这个词。有些债是故意不还的——重构的收益抵不上回归测试的成本，那就让它丑着。

给同样新手的建议

我总结了一个笨办法：看任何开源项目，先找到它的"故障模式"。Woodpecker的Agent如果连不上Server，会指数退避重试，最大间隔5分钟。这个参数在代码里写死，没有配置文件能改。

为什么？因为作者假设"Server挂了是运维的事，Agent不该自作聪明"。这种设计哲学，读十遍README也读不出来，只能在错误处理的分支里找到。

5天下来，我的Go依然写得很烂，但下次遇到陌生的分布式系统，我知道该先看目录结构，再找通信协议，最后盯死错误处理的路径。代码是地图，不是目的地。

你现在手头有没有一个看了就头疼的开源项目？如果给你5天，你会从哪行代码开始？