github - Tony Bai

本文永久链接 – https://tonybai.com/2025/10/24/honoring-1024-programmers-day

大家好，我是Tony Bai。

今天，10 月 24 日，是一个特殊的日子。

它并非法定假日，地图上也没有标注。但对于一群特定的人来说，这个日期本身，就是一种无需言说的默契。1024，是 2 的 10 次方，是 1KB，是我们构建整个数字世界的基石。

它，就是属于我们程序员自己的节日——1024 程序员节。

所以，今天这篇文章，不聊源码，不谈架构，只想写给每一个奔跑在二进制世界里的你：

致敬那些深夜里，与 Bug 搏斗到天明的执着身影；
致敬那些显示器前，在 0 和 1 中创造出无限可能的大脑；
致敬那些用一行行代码，默默改变着世界的同行者们。

你们，值得被看见，被理解，被尊重。

程序员的宿命：永远在学习“第一课”

作为程序员，我们的职业生涯，似乎就是一场永无止境的“学习第一课”的旅程。

我至今仍记得自己第一次学习 C 语言时，面对指针的困惑；第一次接触并发编程时，被死锁折磨的痛苦；第一次探索 Go 语言时，被其简单哲学所震撼的喜悦。

无论是学习一门新语言，还是掌握一个新框架，亦或是理解一种新的架构思想，我们总是在不断地“清空自己”，以一个初学者的心态，回到“第一课”的起点。

这正是这个职业最磨人、也最迷人的地方。它强迫我们保持好奇，持续奔跑，永不僵化。

我将我的极客时间专栏《Go语言第一课》沉淀成书，正是源于对这份“程序员宿命”的深刻理解。我希望它不仅仅是教你一门语言的语法，更是想为你提供一套坚实的、可信赖的、能够举一反三的学习体系和思维范式。它是我作为一个“长期主义”布道者，希望能为你的下一段“第一课”之路，铺下的一块最坚固的基石。

灵魂拷问：AI 时代，我们还需要“第一课”吗？

我知道，很多人心里都有一个疑问：在 AI 如此强大的今天，我们似乎可以随时跳过所有“第一课”，直接向 AI 要答案。那么，系统性的学习是否已经过时？

作为一名同样深度使用 AI 的工程师，我的答案是：不，恰恰相反，在这个时代，扎实的“第一课”比以往任何时候都更加重要。

AI 是“陪练”，不是“内功心法”。 它可以极大地加速我们实现想法的过程，但它无法替代我们建立知识体系的“内功”修炼。它能告诉你“是什么”，却很少能告诉你“为什么”。

我看到太多的初级工程师，在 AI 带来的“我什么都行”的幻觉中，陷入了“知其然，不知其所以然”的困境。这种“能力空心化”，会在未来的某个时刻，成为职业生涯中难以逾越的瓶颈。

而系统性地学习一本好的入门书，正是在 AI 时代对抗这种“能力空心化”、构建自己不可替代核心竞争力的最佳途径。它强迫你去理解代码背后的设计哲学、核心原理和权衡取舍，而这些，恰恰是 AI 无法生成的、属于你自己的智慧。

节日献礼：送你一本签名的《Go语言第一课》！

在这个属于我们自己的节日里，我想用一份最“硬核”的礼物，来回馈大家一直以来的支持，也为每一位仍在奔跑的同行者，加一次油，充一次电。

我准备了 2 本我的亲笔签名版《Go语言第一课》，送给我的读者们。

【参与方式】

点击此链接进入我的公众号文章，分享文章，转发朋友圈，并在本文评论区留言，说说你作为程序员最难忘的一个瞬间/故事，或者你对程序员这个职业最深的思考。

它可以是一次通宵排查 Bug 后的豁然开朗，可以是自己的代码被千万用户使用时的成就感，也可以是对这个行业未来的迷茫与期许。

【抽奖规则】

我将从所有留言中，精选 2 条最走心、最能打动我的分享，每人赠送一本我的亲笔签名版《Go语言第一课》！

【活动截止时间】

2025年10月31日 23:59

期待在留言区，看到你的故事。

行动号召：为你的热爱，充一次电！

当然，节日的福利属于每一个人。

如果你不想等待抽奖，或者想把这份礼物送给身边正在学习 Go 的朋友，现在就是最好的时机。双十一促销已经启动，各大电商平台的五折购书折扣都是全年最低。不到 40 元，即可拥有这本经过 2.4w 人验证、300 多页的 Go 入门宝典。

图书勘误与配套代码：https://github.com/bigwhite/goprimer

小结：愿我们永远奔跑

最后，再次向每一位奔跑在二进制世界里的同行者致敬。

愿你的代码永远优雅，愿你的编译永远通过，愿你的创造力永不枯竭，愿你的 err 永远为 nil。

1024，程序员节快乐！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/09/20/refactoring-go-in-large-codebases

大家好，我是Tony Bai。

“要不……我们重写吧？”

在任何一个发展到一定阶段的 Go 项目中，这句话都像一个幽灵，反复出现在技术讨论中。面对一个布满补丁、逻辑盘根错节、维护成本日益高昂的“大泥球” (Big Ball of Mud)，彻底推倒重来的想法总是充满了诱惑。

然而，这往往是通往灾难的捷径。重写项目常常陷入延期、超出预算、甚至最终失败的泥潭。那么，正确的道路究竟在何方？

在 GitHub 的软件工程师 Brittany Ellich 最近的一次分享中，她系统性地为大型 Go 项目的维护者提供了一份清晰的实践指南。本文将为你完整呈现这份源自顶级工程团队的宝贵经验。

核心困境——为何“重写”如此诱人？

在深入探讨如何重构之前，我们必须先理解“为何不应轻易重写”。推动重写的往往是三个看似合理、实则充满谬误的论点。

谬误一：“重写会更快”

这是最普遍的错觉。我们往往只看到了系统中那 20% 腐烂的部分，并天真地认为重写它们就是全部工作。但我们忽略了：

那 80% 仍在正常工作的部分也必须重写。
在重写期间，旧系统仍需维护，团队精力被一分为二。
数据迁移和系统下线本身就是极其复杂且耗时的大型项目。

最终，“快速重写”几乎无一例外地会演变成一场旷日持久的拉锯战。

谬误二：“这次我们能写出‘干净’的代码”

“如果我们从头开始，就能‘做对’。” 这句话听起来无比正确，却忽视了一个残酷的现实：

“生产应用程序本质上就是混乱的。这是特性，不是 Bug。”

那些看似丑陋的边界情况，恰恰是多年用户反馈积累下的业务逻辑；那些晦涩的变通方案，是无数次深夜故障排查后沉淀下的组织知识。一个“干净”的重写版本，往往意味着这些宝贵的隐性知识被全部丢弃，你将不得不重新踩一遍所有过去的坑。

谬误三：“新技术栈能解决我们的问题”

“如果我们用 Rust 重写，性能问题就都解决了！” 这是技术驱动的典型陷阱。

学习一门新技术很容易，但精通它很难。在重写项目中引入一个全新的技术栈，意味着团队将在“学习”和“构建”之间反复横跳，犯下大量新手错误。更明智的做法是，用现有、成熟的技术栈，通过重构解决已知问题，这远比用一门新语言写出同样有问题的代码要高效得多。

诊断结论：重构，而非重写，是持续改进的唯一路径。正如敏捷宣言早已告诉我们的那样，最好的软件产品源于持续的改进，而非完美的规划。

系统性重构框架——一套可落地的实践指南

既然重写不可取，我们该如何系统性地对现有 Go 代码库进行“外科手术”？Ellich 提出了一套以“易读、易测、易改”为核心原则的实践框架-THINK。

实践一：建立测试安全网

在修改任何代码之前，第一步永远是建立安全网。如果你的代码库测试覆盖率不足，可以采用 Michael Feathers 在《修改代码的艺术》中提出的“特性刻画测试” (Characterization Tests)。这种测试不关心代码的内部逻辑，只关心“给定某种输入，是否能得到预期的输出”，以此锁定现有行为，确保你的重构不会引入新的 Bug。

实践二：统一错误处理

在 Go 中，错误处理的方式直接影响着应用的整体结构。随着时间的推移，代码库中往往会出现多种错误处理风格：丢失上下文、日志与返回并存的“双重处理”、或是被忽略的“静默失败”。选择一种统一的、规范的错误处理方式（例如，统一使用 fmt.Errorf 配合 %w），并将其应用到整个代码库，是性价比极高的重构起点。记住 Go 的谚语：“错误是值”，像对待普通值一样，认真地对待它们。

实践三：定义清晰的接口

接口定义了系统的边界。清晰的边界是实现“易测”和“易改”的关键。
* 拆分大接口：遵循接口隔离原则，将臃肿的大接口拆分成多个专注于单一职责的小接口。这能避免客户端依赖它们不需要的方法，并极大地简化 mock 的编写。
* 警惕 any (interface{})：除非在序列化等少数场景，否则应避免使用空接口。明确的类型是 Go 静态类型优势的体现，它能在编译期而非运行时发现错误。

实践四：收窄与解耦依赖

紧耦合是代码变得难以修改的根源。

使用依赖注入 (Dependency Injection)：不要在业务逻辑函数中直接创建数据库连接等外部依赖。通过函数参数或结构体字段将依赖（最好是接口）注入进来，能让单元测试摆脱对真实外部环境的依赖。
分离关注点：避免在整个应用中传递一个混合了 API、数据库、验证逻辑的“全能”模型(用户数据结构)。在应用的不同层（API 层、数据层）定义各自所需的、职责单一的模型，能让各层的修改互不影响。
外部化业务规则：将易变的业务逻辑（如折扣计算、计费规则）从代码中剥离，交由配置或独立的规则引擎服务管理。这样，当业务规则变更时，无需工程师介入修改代码和重新部署。

实践五：坚持持续改进

不要寄希望于“重构冲刺周”或“技术债偿还日”。这些形式化的活动往往收效甚微。最好的策略，是在日常的功能开发中，持续、小步地进行重构。这正是“童子军军规”——“让营地比你来时更干净”——在软件开发中的体现。

优先级规划——如何决定重构的起点？

重构任务千头万绪，如何选择最有价值的切入点？Ellich 提供了一个简单而高效的“影响力-费力” (Impact-Effort) 矩阵。

第一优先级：高影响，低费力 (Quick Wins)

这些是“速效成果”。例如，为关键路径的错误信息添加上下文、将硬编码的常量提取到配置中、用具体类型替换空接口等。这些改动风险低，见效快，能迅速提升代码质量和团队信心。

第二优先级：高影响，高费力 (Major Projects)

这些是需要严肃对待的“大型项目”。例如，拆分核心模块的大接口、标准化整个代码库的错误处理、分离紧耦合的核心模型等。这些任务需要被当做正式的功能需求来规划和排期，它们能从根本上改善系统健康状况。

第三优先级：低影响 (Ignore for now)

任何低影响的工作，无论费力与否，都应该被有意识地忽略。避免团队将宝贵的精力浪费在价值不大的事情上，直到它们有朝一日变成了高影响的问题。

现代助推器——让 AI 成为你的重构伙伴

过去，“持续重构”说起来容易做起来难，因为它会挤占开发新功能的时间。但现在，AI 编码助手（如 GitHub Copilot Agent）正在改变游戏规则。

Ellich 分享了她的团队如何利用 AI 来处理那些“重要但不紧急”的重构任务，让它们不再堆积在积压列表 (Backlog) 中直至腐烂：

提升测试覆盖率：给 AI 一个明确的指令（“为 lib/services 目录下未被覆盖的路径创建表驱动测试”），它可以快速生成高质量的测试用例。
标准化代码模式：提供一个代码片段作为范例（“使用这种新的错误处理方式，并将其应用到 lib/services 目录下的所有文件中”），AI 可以在整个代码库中系统性地推行这一模式。
迁移技术方案：创建一个小型的、人工完成的 PR 作为示例（“参照这个 PR，将项目中所有旧的 mocking 库替换为新库”），然后让 AI 将这个变更应用到所有相关文件中。

AI 的出现，让“持续处理技术债”的成本被前所未有地降低。它使我们终于有能力在交付新功能的同时，系统性地改善代码库的健康状况。