



























本文永久链接 – 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 在开篇就点明了核心:维护者看代码,就像通过一个卫生纸筒的中心在看世界,视野极其狭窄。
你的任务,就是让他永远无法拼凑出完整的画面。
go
// 古法复刻
var l int64 = 11 // 这是 11 还是 1l?
var speed int = O1 // 这是 O1 还是 01?go
// 古法复刻
var swimmer, swimner string // 99% 的 Code Review 都会看走眼
var hashTable, HashTable *map[string]intgo
// 古法复刻
func GetUserAuth(...) {}
func GetUsrAuthorization(...) {}
var athnClient *Clientgo
// 古法复刻
i++ // i plus 1滥用全局变量:永远不要使用局部变量,把一切都提升为包级变量,让并发的 Goroutine 们去为了争夺它而自相残杀。
// 古法复刻
var tempResult string // 提升为包级变量
func HandleRequestA() {
tempResult = "result_from_A"
// ...
}
func HandleRequestB() {
tempResult = "result_from_B"
// ...
}
// 当这两个函数并发执行时,一场血案即将发生。
当然原文中,Roedy Green的“骚操作”不止这些。
但其中的一些“防御”手段对今天的Go语言来说,并不生效。
你会发现 Go 语言在设计之初,就已经对这些“手段”进行了“免疫”,比如:
当然,Go 也不是万能的。很多源自 Java/C++ 时代的“高级骚操作”,在 Go 里依然可以“继续存在”。
go
// 古法复刻:这个函数名和类型名完全一样,但它不是构造函数!
type User struct{ name string }
func User(name string) { /* ... do something evil */ }go
// 古法复刻
if len(users) > 99 { // 这里是 > 99
// ...
}
for i := 0; i < 100; i++ { // 这里是 < 100
// ...
}go
// 古法复刻
func Process(input interface{}) {
switch v := input.(type) {
case string: // 处理字符串
case int: // 处理整数,但逻辑和 string 完全不同
// ...
}
}重温这本 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原生开发之旅。

你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?
继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。
目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!

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

© 2026, bigwhite. 版权所有.
Related posts:
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。