文/一个在软件工程和极简主义之间来回摇摆的人
前几天在一个技术群里，有人转发了一张图——某大厂内部的一个微服务调用链路图。密密麻麻的节点和箭头几乎铺满了整个屏幕，像一张城市规划的地铁线路图，还是那种有十几条线路、几十个换乘站的大城市。
有人评论说：”我们这个行业，把’Hello, World!’搞成了这个样子。”
这句话让我想了好久。我们确实把一件”输出一行字”的事情，变成了一个需要几百个服务、几十种组件、无数配置才能完成的高难度工程。这里面当然有合理的理由——规模、可用性、扩展性、安全性。但有时候我也会想，那个站在1972年只用了三行代码就向世界问好的柯林汉，如果看到今天一个完整的”Hello, World!”级别的微服务需要几十个YAML文件才能部署起来，他会说什么。
他大概会说一句：你们把事情搞复杂了。
一个”简单事实”的遭遇
软件工程这个行业，很有意思。我们自称”工程”，所以我们做架构设计、做流程规范、做质量管控、做风险预案。这些东西都是有道理的，大项目确实需要这些。但问题在于，这些”工程化”的东西一旦建立起来，就会像滚雪球一样越滚越大，最后把”做软件”这件事本身裹得严严实实。
我记得有一次参加一个架构评审会，讨论的是一个新服务的接入方案。会上有架构师、有运维、有安全、有DBA，每个人都在提要求：”你这个要接入监控””那个要接入日志””要配熔断降级””要做灰度发布””要满足等保要求”。快两个小时过去，最开始那个”我们要接一个什么服务”的问题已经没人记得了。所有人都在讨论怎么接、用什么流程、配什么参数。
后来散会了，那个负责接进来的小伙子走到我旁边，低声说了一句话：”其实我现在只需要让那个服务能返回’Hello, World!’就好。”
那个瞬间，我突然觉得”软件工程”和”Hello, World”之间，有一条很深的裂缝。我们在”工程”那一侧垒了太多东西，以至于”软件”本身最简单的那个形态，已经被淹没了。
那个只写了三行的”原型”，救了整个项目
这个故事我讲过几次，但值得再讲一遍。
我们团队曾经接手一个遗留系统，几万行代码、十几个模块、七八个数据源、各种诡异的历史依赖。接手的前三个月，团队几乎都在”读”代码，没有人敢”动”代码。因为据说”动一下可能就崩了，没人知道为什么”。
后来我们新来的一个应届生，胆子比较大。他偷偷用了一周时间，把核心功能从那个庞大的系统里”抠”了出来，单独跑了一个极简版本。那个版本只有三行跟业务相关的代码，返回一个固定字符串。
他把那个极简版本部署到测试环境，然后拿压测工具打了一下——延迟个位数毫秒，CPU占用接近于零。
有了这个”极简版本”作为锚点，团队开始对照着去拆原来的大系统。每拆一个模块出来，跟极简版本对比一下：加了你这个模块之后，延迟增长了多少？CPU多了几个百分点？每拆一步都有一个”干净的起点”做参照，可以精准地知道增加的负担来自哪里。
后来那个遗留系统被拆成了十几个独立的服务，拆完之后整个系统稳定性和响应速度都上了一个台阶。这一切的起点，是一个三行的、只输出固定字符串的”伪Hello World”。
那个应届生后来复盘的时候说了一句话：”我就是写了一个最小的、能证明’这条路走得通’的例子。然后所有复杂的决定，都是在这个’能走通’的基础上做的增量。”
当专家想复杂的时候，初学者用Hello World找到了真相
还有一个挺讽刺的现象。很多复杂问题的答案，往往不在复杂的分析里，而在最简单的那一步验证里。
我认识一个做性能优化的老手，他在一个团队里做了三个月，试图定位一个”偶尔超时”的问题。他分析了GC日志、看了网络抓包、检查了磁盘I/O、调了线程池大小。三个月过去，问题依然偶尔出现。
后来一个新来的实习生，什么都不会，就只会写Hello World级别的代码。他写了一个极其简单的客户端，循环发请求给那个服务，然后把每次的耗时打印出来。打印了大概一万条之后，他发现一个规律：每隔大概两百次请求，就有一条耗时特别长。
他把那个时间点跟服务端的日志对了一下，发现每次超时都正好发生在”日志轮转”的时刻——系统在滚动日志文件的时候，文件锁竞争导致请求被阻塞了几百毫秒。
老手分析了三个月没找到的原因，新手用”打印耗时”这种最原始、最Hello World级别的手段发现了。因为老手想得太多太深，新手只是”把它打印出来看一下”。
那个”极简参照物”，比任何架构图都管用
软件工程喜欢做”抽象”。架构图是抽象、设计模式是抽象、分层架构是抽象。这些抽象帮助我们理解复杂系统。但抽象也有一个副作用——它离”代码实际在干什么”越来越远。
你看到的是一张漂亮的六边形架构图，点击每个边都能展开子图，你觉得这个系统设计得真棒。但你不知道那个最底层的、实际在干活的那一行代码长什么样，它执行的时候CPU在干什么、内存用了多少、延迟是多少。
Hello World级别的测试，提供了一个”绕过所有抽象、直接看到本质”的窗口。它不经过任何中间层、不经过任何框架、不经过任何配置——就是把最原始的那条执行路径拉出来让你看一眼。看一眼它的状态，就是看一眼系统的地基。
所以我现在参与任何一个大项目，都坚持保留一个”极简入口”——一个没有任何业务逻辑、不依赖任何外部组件、只返回固定内容的接口。它不是给用户用的，它是给”人”看的。看它就能知道”系统本身有没有问题”。
这个接口在代码库里通常只有几行，没人注意，也没人会去改它。但它永远在那里，像一个安静的基准点。当系统出问题、所有人焦头烂额的时候，先去看一眼那个接口——它活着，就说明”系统底层”没事。它死了，就说明问题出在根上。
就这么简单。
所以Hello World和软件工程到底什么关系
我最后想清楚了这个问题。
软件工程研究的是”怎么做大、怎么做复杂、怎么做可靠”。而Hello World研究的是”怎么做小、怎么做简单、怎么做可验证”。它们不是对手，是搭档。
大项目需要工程化，需要流程、需要规范、需要各种抽象。但所有这些”大”的东西，都需要一个”小”的基准来校准——确保在复杂的外壳之下，那个最核心的”它能输出一行字”的能力，始终存在。
就像你建一栋摩天大楼，你需要结构工程师、需要材料力学、需要施工管理，这些都是”工程”的部分。但你打地基之前，永远要先做一件事——在纸上画一条线，说”我打算在这里建一栋楼”。
那条线就是Hello World。
它什么都没盖，但它是一切”盖”的开始。它不在最终的大楼里，但它一直在地下支撑着大楼。
所以我后来不再觉得”软件工程”和”Hello World”之间有裂缝了。它们只是工作的不同尺度。一个人既可以用”工程”的尺度去管理几万行代码的复杂系统，也可以用”Hello World”的尺度去验证那条最基础的执行通路。
两种尺度都要有。缺一个，软件这个行当就站不稳。