守护你的棚屋

翻译自 Dylan Butler 《Protect Your Shed》

建造摩天大楼是一项浩大的工程。在订购第一根钢材之前，你得先有建筑蓝图、市政审批和安全审查。这需要成百上千号人，花上数月乃至数年去协同作业。你不可能随便砌几面石膏板墙，就指望整栋楼能承重。

而后院棚屋就是另一回事了。无需蓝图，不用审批，也没人审查。你只需抓几根木料、一把锯子，就可以挥锤开工了。屋子可能漏风，雨稍大些屋顶就会渗水，但它却是你凭一己之力，用一个周末搭建出来的。

过去六年，我的工程师生涯就游走于这两种模式之间。白天，我在企业级规模上构建银行系统；夜晚，我便钻进棚屋，随心所欲地鼓捣些自己喜欢的东西——做的都是些业余项目，有的能溅起些水花，有的则不了了之。

人们很容易把这两种生活看成泾渭分明的两个世界：一份是为了糊口，另一份是为了乐趣。但当我回望这段职业生涯，却领悟到一件更重要的事：企业级开发教会了我如何进行大规模工程构建，但真正让我一直保有工程师本色的，却是那些个人项目。我常对年轻开发者们说，在业余时间做点自己的项目，远比参加任何面试培训或刷 LeetCode 更有助于你的职业成长。

参悟规模化之道

刚进入这个领域时，最令我印象深刻的是，真正花在写代码上的功夫少之又少。设计文档、测试计划、架构评审……这些环节占据了大部分时间，以至于感觉“实际建造”只是工作的一小部分。但正是这些看似外围的工作，才使得大规模建造成为可能。当你需要处理一家大型银行级别的交易量时，你不可能跳过设计阶段，也无法在测试上偷工减料。每一个看似繁琐的步骤之所以存在，都是因为曾有人用惨痛的教训换来了经验。

在这样的环境中工作，你会接触到个人难以企及的规模。比如，你会使用像 Cloud Spanner 这样的工具——一种全球分布式、强一致性的数据库，根本无法在笔记本上模拟运行。你学会防御性设计，在考虑功能之前，先琢磨各种失效模式。但这种规模效应也有代价：僵化。你只是庞大工地上的一名工人，通常无权挑选材料，也鲜有机会去尝试触动地基。

把蓝图带回家

棚屋，正是你将那些从工作中习得的蓝图，真正施展拳脚的地方。刚开始，我的个人项目乱七八糟。如果说有“架构”这个东西，那也往往是事后诸葛——标准的棚屋做派。但久而久之，工作中的那些模式开始自然而然地渗透进来。当你花了足够多的时间去设计需要妥善处理故障的系统，这种思维就会变成一种本能。

我的家庭实验室（homelab）就是最好的例子。它从一个跑在单台机器上的容器开始，最终演变成一个托管集群，拥有自动化部署和完全由代码定义的基础设施。这正是把摩天大楼的结构性纪律，应用到一个我拥有完全自由的空间里。我的个人项目不再轻易崩溃。它们依然是以我的方式快速构建而成，但根基却扎实了。企业教会了结构完整性的规则，而棚屋则给了我一片真正能扮演建筑师角色的天地。

自由地折腾

当你为自己而建，一个错误决策的代价无非是浪费一个晚上。但在工作中，选错技术路线会影响到真实的团队和真实的客户。棚屋之所以如此宝贵，正在于其快速反馈的循环。你既是开发者，又是审查者，还是用户。你可以推倒并重建某样东西，就为了体验一下感受。

我曾用 Go 语言写了一个 Game Boy Advance 模拟器，并非因为世界需要它，而是因为我想从那个层面弄懂硬件是如何工作的。我也曾自己搭建服务，使用一些上班时绝不会碰的工具，单纯是为了理解它们的取舍得失。你可以尝试从未用过的工具，而不必为此写一份提议书。这些实验大多不会变成创业想法，但它们都会在你身上留下痕迹：一个新的模式，一个关于不该做什么的教训，以及对技术领域更广阔的理解。

最重要的是，棚屋是好奇心得以存活的地方。企业级开发价值巨大，但它也会消磨你。迭代匆匆，需求单上的条目永不见少，问题也开始显得千篇一律。而个人项目正是你找回“编写软件其实很有趣”这一初心的所在。

把锤子带进摩天大楼

在我职业生涯的早期，我对容器化和云基础设施还很陌生，工作中的学习曲线相当陡峭。但因为我利用自己的时间，在家里用 GCP 搭建和运行着容器化系统，这些概念就吸收得更快。我从两边都在不断试炼入手。这种模式在我的职业生涯中反复上演：某个周末，你出于好奇在棚屋里尝试新东西；你弄清了它的取舍、痛点，以及那些文档不会告诉你的细节；几个月后，当团队在工作中评估相同的工具或方法时，你就不再是从零开始了。

正因为在自己的环境里跌倒过，在自己的时间里评估过工具，亲身体会过那些痛点，你才能够在工作中做出有理有据的判断，而非猜测。