好的代码的沉默之死
The silent death of good code

原始链接: https://amit.prasad.me/blog/rip-good-code

作者反思了软件工程的变化,感叹于对“好代码™”的重视程度下降——这种代码易读、易维护、且经过精心设计。虽然最初对编写此类代码充满热情,但他们目前的工作重心是*实用*的软件,不一定是*漂亮*的代码。 他们用同事的经历来说明这一点:一个C程序的Rust重写,借助AI快速完成,虽然功能正常,但缺乏清晰和优雅。随后的、经过深思熟虑的重写——*没有*过度依赖AI——产生了极高质量的代码。 作者注意到一种趋势,即AI辅助编码优先考虑速度和功能,而非精湛的工艺,导致代码“可用”但并非真正*好*的代码。他们担心这预示着对代码质量的整体欣赏度下降,就像过去一代工程师可能在各自领域看到类似的转变一样,并哀悼“好代码”可能发生的“静默消亡”。

## 优秀代码的静默消亡 - 摘要 最近的Hacker News讨论集中在“优秀代码”在软件开发中逐渐减少的观点上,这主要归因于AI编码助手(LLM)的兴起。 历史上,精心编写的代码因其可维护性和可扩展性而受到重视,而目前的重点正在转向快速交付和“足够好”的代码。 许多评论者认为,真正的“优秀代码”需要深刻的理解和架构思维——这些是当前AI难以复制的品质。 然而,快速交付的压力常常压倒了对优雅的追求,而且管理者很少优先考虑代码质量。 有些人认为LLM可以通过更快的重构和抽象来*促进*更好的代码,如果能经过深思熟虑地使用并制定明确的标准。 另一些人则担心它们会将平庸的代码规范化,导致代码库越来越复杂和脆弱。 关键点是,LLM降低了对“足够好”代码的要求,可能会降低开发者对其工作的技能和自豪感。 最终,这场讨论凸显了在快速发展的环境中,工艺精神与实用主义之间的紧张关系,许多人认为编写真正优秀的代码可能更多地成为一种个人追求,而不是专业标准。
相关文章

原文

I’ve been passionate about writing “Good Code™” since before I started my career, beginning way back when I was still a kid in middle school.

What is “Good Code™“?

Good Question™ :)

Good Code is code that is easy to read and understand. Good Code is code that is pleasing to develop with and maintain. Good Code is code that exists for a specific reason, and no more. Good Code is a product of the rare combination of talent, experience, passion, and the investment of time that may not be immediately useful for the business. And most unfortunately, Good Code is rare.

That being said, by trade, I am a Software Engineer. Not a “Computer Programmer”, nor a “Coder”, nor any other title that implies that my job is to “write good code”. In fact, nothing about my job title necessitates that I read or write code at all! My job is to create useful software that solves real problems.

Recently, a colleague of mine at Modal rewrote an external system that integrated deeply with the Linux kernel. The initial rewrite was a simple translation of a C codebase to a Rust one, in preparation for some custom feature work. The resulting code wasn’t bad, nor was it un-idiomatic Rust. What it also wasn’t was Good Code. It was hard to read and understand, would have been difficult to extend and maintain, and it wasn’t even clear to us why we’d taken the burden of rewriting and maintaining this extra system.

The initial rewrite also relied heavily on coding agents.

This same colleague then invested time into understanding the kernel subsystem, the exact reasons why the original C program was written how it was, and rewrote the Rust translation himself. The difference was night and day; the code flowed naturally, explained itself and the underlying subsystems, and may genuinely be some of the nicest parts of the entire codebase. Better, I think, than even the original C, despite this type of program being arguably one of the best places to use C over Rust.

It was the first time in weeks, maybe months, that I’d felt something that used to be common in my day-to-day: excitement about the lines of code in front of me. I used to write (approximations of) Good Code most days. Somewhere along the way, everything changed. Nowadays I don’t even write the first version of most of the code I commit. I’m definitely far more productive with an agent at my side. They’re not at all horrible at this coding stuff, just not truly great at it. At the end of the day, the code they spit out is… acceptable. It gets the job done, it passes my litmus tests, but it certainly isn’t Good Code.

Perhaps the age of caring about these lines of code is over. I’m sure that there were folks passionate about Good Assembly or Good Circuits whose passions have quietly faded into the echoes of “how things used to be,” forgotten as they and their fields evolved. From my (biased) perspective, the change in Software Engineering feels uniquely sudden, and I can’t help but mourn the silent death of Good Code.

联系我们 contact @ memedata.com