本文永久链接 – https://tonybai.com/2026/04/06/how-to-write-unmaintainable-code

大家好，我是Tony Bai。

在这个由 Claude、GPT、Gemini等大模型定义的 2026 年，我们似乎已经习惯了 AI 那种近乎“洁癖”的编码风格：优雅的接口设计、滴水不漏的错误处理、以及永远对齐的工整格式。

AI 正在用它那冰冷的、毫无感情的逻辑，将软件工程推向一个前所未有的标准化时代。

但就在前几天，我在一个尘封的互联网角落里，挖出了一本写于 1999 年的上古奇文——《How To Write Unmaintainable Code》（如何编写不可维护的代码）。

这篇文章的作者 Roedy Green，怀着一种极其黑色幽默的极客精神，手把手教导当年的 Java 程序员们，如何写出能让“接盘侠”当场崩溃、从而保证自己“终身就业”的屎山代码。

当我用 AI 时代的眼光，去重新审视这本 27 年前的“反向圣经”时，我感到既荒谬又亲切。它就像一面镜子，照出了在没有 gofmt、没有 AI、没有 Claude Code 的“古法编程”时代，我们曾如何野蛮生长，以及 Go 语言在设计之初，就已经用多么前瞻性的眼光，封印了那些曾经肆虐一时的“魔鬼”。

今天，就让我们开启一场技术考古之旅，用现代 Go 语言，来“复刻”一下这些差点失传的“防御性”编程之术。

底层哲学：把你的同事想象成一个“管中窥豹”的傻子

Roedy Green 在开篇就点明了核心：维护者看代码，就像通过一个卫生纸筒的中心在看世界，视野极其狭窄。

你的任务，就是让他永远无法拼凑出完整的画面。

古法复刻：让同事“提刀来见”的 骚操作

命名之罪

1. 用 l 冒充 1，用 O 冒充 0：利用字体的模糊性，制造视觉混乱。
   go
// 古法复刻
var l int64 = 11 // 这是 11 还是 1l？
var speed int = O1 // 这是 O1 还是 01？
2. 创造极其相似的变量名：仅通过大小写或一个不显眼的字母进行区分。
   go
// 古法复刻
var swimmer, swimner string // 99% 的 Code Review 都会看走眼
var hashTable, HashTable *map[string]int
3. 滥用缩写，且不保持一致：在不同的地方使用同一个单词的不同缩写，让全局搜索彻底失效。
   go
// 古法复刻
func GetUserAuth(...) {}
func GetUsrAuthorization(...) {}
var athnClient *Client
4. 使用与业务逻辑无关的变量名：比如，在屏幕上显示“Postal Code”(邮政编码)，但在代码里把它命名为 zip。
5. 在函数名中使用极其抽象的词汇：比如 HandleIt, ProcessData, DoStuff。让调用者永远猜不透这个函数到底干了什么。

注释之罪

1. 在注释里撒谎：最简单的一招，改了代码，但不更新注释。
2. 写废话注释：为每一行显而易见的代码配上同样显而易见的注释，用大量的噪音淹没真正有价值的信息。
   go
// 古法复刻
i++ // i plus 1
3. 永远不要注释一个变量：它的单位、取值范围、边界条件，全让维护者自己去猜。

结构之罪

1. 极限压行：在一行里塞进尽可能多的逻辑，挑战显示器的宽度极限。
2. 深度嵌套：以能嵌套 10 层以上的 if-else 为荣，坚决不使用 early return或happy path。

3. 滥用全局变量：永远不要使用局部变量，把一切都提升为包级变量，让并发的 Goroutine 们去为了争夺它而自相残杀。

   // 古法复刻
   var tempResult string // 提升为包级变量
   
   func HandleRequestA() {
       tempResult = "result_from_A"
       // ...
   }
   
   func HandleRequestB() {
       tempResult = "result_from_B"
       // ...
   }
   // 当这两个函数并发执行时，一场血案即将发生。
   

4. 复制-粘贴-修改：当有相似功能时，坚决不抽象，直接复制粘贴。在一个代码库里埋下 5 份只有细微差别的一模一样的代码，等待日后引爆。
5. 一个函数只做一件事？不，一个函数必须干三件事！ 让一个名为 IsValid() 的函数，在校验的同时，偷偷地把数据写入数据库。

Go 语言的反击

当然原文中，Roedy Green的“骚操作”不止这些。

但其中的一些“防御”手段对今天的Go语言来说，并不生效。

你会发现 Go 语言在设计之初，就已经对这些“手段”进行了“免疫”，比如：

• 关于缩进与格式：Roedy Green 痛斥当年程序员通过“故意错位”的缩进来制造 if-else 匹配的视觉陷阱。
  • Go 的反击：对不起，我们有 gofmt。在 Go 的世界里，关于代码格式的“圣战”在第一天就结束了。无论你的代码写得多乱，Ctrl+S 的瞬间，一切都会变得整齐划一。
• 关于花括号：原文建议省略非必须的 {}。
  • Go 的反击：Go 语言强制要求 if, for 后面必须跟 {}，从语法层面彻底消灭了这种的“防御”写法。

现代化的“魔鬼”：用 Go 复刻那些更高级的骚操作

当然，Go 也不是万能的。很多源自 Java/C++ 时代的“高级骚操作”，在 Go 里依然可以“继续存在”。

1. 伪装成构造函数：
   go
// 古法复刻：这个函数名和类型名完全一样，但它不是构造函数！
type User struct{ name string }
func User(name string) { /* ... do something evil */ }
2. 滥用 interface{}：把所有的函数参数都定义成 interface{}，然后在函数内部进行大量的类型断言（Type Assertion）。这能完美地把编译时错误，转化为运行时 panic。
3. 颠倒参数顺序：定义一个 DrawRectangle(height, width int) 函数。在几个版本之后，神不知鬼不觉地把它改成 DrawRectangle(width, height int)，但函数名保持不变。
4. 魔数（Magic Numbers）：在代码里硬编码大量的数字 100，但就是不定义一个常量。更高级的玩法是，偶尔用 99 代替 100-1，用 50*2 代替 100。
   go
// 古法复刻
if len(users) > 99 { // 这里是 > 99
// ...
}
for i := 0; i < 100; i++ { // 这里是 < 100
// ...
}
5. 迷惑性的函数重载（Go 版本）：Go 没有函数重载，但我们可以用“接口”来模拟。
   go
// 古法复刻
func Process(input interface{}) {
switch v := input.(type) {
case string: // 处理字符串
case int: // 处理整数，但逻辑和 string 完全不同
// ...
}
}
   当你的同事传入一个他以为是数字的字符串 “123″ 时，他将收获一个意想不到的结果。

小结：在 AI 时代，我们为什么要回顾“屎山”？

重温这本 27 年前的“反向圣经”，在今天这个 AI 编程时代，显得格外有意义。

AI 的出现，正在把“编写可维护代码”的门槛，拉到前所未有的低点。一个初级程序员，在 AI 的辅助下，也能写出格式工整、变量命名规范的代码。

但这是否意味着“屎山”将成为历史？

恰恰相反。AI 在解放我们生产力的同时，也正在“批量化”和“隐蔽化”地制造着“新时代的屎山”。AI 可能会生成一段逻辑上看似完美，但在高并发下会引发严重数据竞争的代码；它也可能会为了实现一个简单功能，引入一个庞大且带有安全漏洞的第三方库。

这本古老的指南提醒我们：技术的进步可以消灭“语法层面”的丑陋，但永远无法替代人类工程师在“架构层面”的审美与抉择。

在 AI 时代，我们不再需要像 Roedy Green 那样，靠着“加密代码”来保住饭碗。但我们比以往任何时候，都更需要理解那些“不可维护代码”背后的设计缺陷，从而在 Code Review 中，扮演好 AI 的“最终质检员”角色。

代码的整洁与混乱，终究是一场关于“责任心”的博弈。无论时代如何变迁，这，或许是软件工程永恒的真理。

当然，如果你真的想了解古法编程时代的更多“骚操作”，可以看看Roedy Green的原文：https://www.doc.ic.ac.uk/%7Esusan/475/unmain.html

---

今日互动探讨：

在你见过的 Go 项目中，遇到过哪些让你拍案叫绝、或者让你想“提刀来见”的“屎山代码”骚操作？

欢迎在评论区分享你的“开眼”经历！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

---

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/02/09/go-immutable-types-8-year-dormant-proposal-awakened

大家好，我是Tony Bai。

2026 年 2 月 4 日，在 Go 语言规范团队的最新一次“语言变更评审会议”纪要中，一个尘封已久的 Issue 赫然在列：proposal: spec: immutable type qualifier #27975。

这个提案最初提交于 2018 年，那是“Towards Go 2”口号喊得最响亮的年代。当时的 Go 社区正沉浸在对泛型、错误处理和不可变性的热烈讨论中。然而，随着泛型的落地，关于不可变性的声音似乎逐渐微弱。

如今，这个提案被重新摆上台面，是否意味着 Go 语言在完成泛型这一宏大叙事后，终于要向“数据竞争”和“防御性编程”这两个顽疾开刀了？

今天，我们就来看看复盘这份长达 8 年的提案，剖析一下“不可变性”对 Go 意味着什么，以及它面临的巨大挑战。

痛点：防御性拷贝的代价

在 Go 1.x 的世界里，我们为了保证数据的安全性，往往需要付出高昂的代价。

假设你有一个包含敏感配置的结构体，你想把它暴露给其他包，但又不希望它被修改：

type Config struct {
    Servers []string
    // ...
}

// 现在的做法：为了安全，必须返回拷贝
func (c *Config) GetServers() []string {
    out := make([]string, len(c.Servers))
    copy(out, c.Servers)
    return out
}

这种“防御性拷贝”带来了两个严重问题：

1. 性能损耗：每次访问都要分配内存和复制数据，对于热点路径是不可接受的。
2. 语义模糊：如果我不拷贝，直接返回 c.Servers，调用者能不能改？文档说不能改，但这只是君子协定，编译器不会阻止手滑的程序员。

正如提案作者 romshark 所言：“我们现在的做法，要么是不安全的（直接返回指针），要么是低效的（防御性拷贝）。”

而不可变类型（Immutable Types）的引入，旨在提供第三种选择：既安全，又高效。

提案核心：immut 限定符

NO.27975 提案的核心思想非常直接：引入一个新的类型限定符（最初建议重载 const，后倾向于引入immut ），让编译器来强制执行“只读”契约。

想象一下这样的 Go 代码：

// 定义一个只读的切片类型
func ProcessData(data immut []byte) {
    // 读取是 OK 的
    fmt.Println(data[0]) 

    // 修改是编译错误的！
    // data[0] = 'X' // Compile Error: cannot assign to immutable type
}

在这个愿景中，不可变性是类型系统的一部分。

• 赋值限制：你不能把一个 immut 类型的变量赋值给一个 mut（可变）类型的变量，这防止了“权限逃逸”。
• 传递性：如果一个结构体是不可变的，那么它字段指向的所有数据（如切片、映射、指针）也自动变为不可变。

这看起来很像 Rust 的 & (immutable reference) 和 &mut (mutable reference)，或者 C++ 的 const。但 Go 社区的讨论，揭示了这背后远比想象中复杂的工程难题。

社区激辩：理想与现实的碰撞

这份提案下的讨论区，堪称 Go 语言设计哲学的“修罗场”。Ian Lance Taylor, Rob Pike 等核心大佬纷纷下场，与社区开发者展开了长达数年的拉锯战。

const 污染

这是 Ian Lance Taylor 最担心的问题。如果你把一个底层函数的参数标记为 immut，那么所有调用它的上层函数，为了传递这个参数，往往也需要把自己的变量标记为 immut。

这种“传染性”会导致代码库中充斥着 immut 关键字。更糟糕的是，如果你以后需要修改底层函数，让它对数据进行一点点修改，你需要修改整个调用链上的类型签名。这在 C++ 中被称为“const correctness”的噩梦。

io.Writer 的尴尬

bcmills 提出了一个极其尖锐的兼容性问题：现有的 io.Writer 接口定义是 Write(p []byte)。

• 如果我们把 p 改成 immut []byte，那么现有的所有 Write 方法实现都会破坏兼容性。
• 如果我们不改，那么即使我手里有一个只读的切片，我也没法把它传给 io.Writer，因为类型不匹配。

这似乎陷入了一个死循环：要么破坏所有现有代码，要么新特性无法与标准库兼容。

所谓“不可变”，到底是谁不可变？

jimmyfrasche 指出了一个微妙的语义陷阱。

在 C++ 中，const T& 只是意味着“我不可以通过这个引用去修改它”（Read-only View），并不意味着“这个数据本身不会变”。因为可能还有另一个非 const 的指针指向同一块内存，并且正在修改它。

如果是前者（只读视图），它无法解决并发安全问题（数据竞争依然存在）。如果是后者（真正的内容不可变），那么 Go 必须引入一套类似 Rust 的所有权（Ownership）系统来保证“没有其他人在写”。这对于 Go 来说，改动太大了。

为何现在重提？

既然困难重重，为何在 2026 年的今天，这个提案又被翻出来了？

我认为有几个关键因素：

首先，泛型的“降维打击”。以权限泛型（Permission Genericity）化解兼容性死结。

前面提到了，在 Go 1.18 泛型落地之前，不可变性提案面临着一个被称为“io.Writer 陷阱”的致命矛盾：如果将 io.Writer.Write(p []byte) 改为接受 immut []byte，将导致全世界现有的实现代码因签名不匹配而崩溃；如果不改，只读数据又无法直接传入。

泛型的引入为这一难题提供了全新的解题思路。通过类型约束中的联合类型（Union Types），我们可以实现所谓的“权限泛型性”。这意味着 mutability（可变性）不再是一个硬编码的死结，而可以作为一个类型参数（Type Parameter）来处理。

想象一下，我们可以利用泛型约束定义一个覆盖“可变”与“不可变”两种状态的超集：~[]byte | ~immut []byte。下面是在这种模式下的一个泛型化的Writer接口：

// 这是一个设想中的“权限泛型”接口
type Writer[T ~[]byte | ~immut []byte] interface {
    Write(p T) (n int, err error)
}

泛型化的 Write[T ~[]byte | ~immut []byte](p T) 方法，在逻辑上可以产生如下影响：

1. 权限无关的调用：由于约束涵盖了两种类型，调用者现在可以合法且安全地将 immut []byte 传给标准库函数，解决了“只读数据无法写入”的窘境。
2. 非破坏性的兼容：对于现有的实现者（如 bytes.Buffer），其原本定义的 Write([]byte) 签名可以被视为该泛型约束的一个特化实例。编译器可以在不改动任何旧代码、不引入任何运行时开销的前提下，在静态分析阶段完成权限的自动适配与校验。

其次，性能压力的倒逼。

随着 Go 在高性能领域的应用越来越深（如数据库、AI 推理），对于“零拷贝”的需求越来越强烈。能够安全地共享内存，是提升性能的关键。

最后是安全性需求。

在并发编程中，数据竞争依然是 Go 程序的头号杀手。go vet 和 race detector 虽然好用，但它们是运行时的、滞后的。社区渴望一种编译期的保证。

未来的可能性：温和的演进

虽然完全的“不可变类型”可能依然很难落地，但我们可以期待一些更温和的替代方案：

• 只读视图 (Read-only Views)：不是引入新的关键字，而是引入一种新的泛型类型 ReadOnly[T]，或者编译器内置的 view 类型。
• 纯函数检查：引入一种机制，标记某些函数是“无副作用”的，从而允许编译器进行更激进的优化。
• 静态分析增强：不改变语言规范，而是通过更强大的 vet 工具，利用注释或特定命名约定，来静态检查不可变性约束。

小结

NO.27975 提案的“复活”，是一个信号。它表明 Go 团队并没有满足于现状，依然在探索如何在保持“简单”这一核心价值观的同时，赋予语言更强的表达力和安全性。

无论最终结果如何，这都是 Go 语言演进史上值得铭记的一笔。它提醒我们：在软件工程中，没有免费的午餐，每一个简单的特性背后，都是无数次复杂的权衡。

---

你支持引入 immut 吗？

面对“性能”与“简单”的博弈，你是否愿意为了消除数据竞争而接受 immut 带来的“类型传染”？在你的项目中，是否也曾深受“防御性”的性能困扰？

欢迎在评论区分享你的看法，或者聊聊你最期待的 Go 演进方向！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

---

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

© 2026, bigwhite. 版权所有.