> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/2026040506-gai-jin-ruan-jian-zhi-liang/we-get-letters.md). # 读者来信 **Michael W. Lucas** 亲爱的来信专栏： 你们说过读者该如何花时间删代码，说过计算机是个错误，喋喋不休地抱怨计算有多糟糕。这次别躲了。本期的主题是改进软件质量。正面回应吧。如何改进软件质量？ ——FreeBSD 期刊编辑委员会 亲爱的 FJEB： 我说过吧，我警告过你们。我在第一篇专栏里就声明，让我回信是个坏主意。你们只能怪自己。所谓 “你们”，指的是 “这六位编委中谁最可能给我写这种信”。我不是要跟谁过不去，但往澳大利亚寄包裹实在太慢，所以 Jason 还能安生几周。期刊甚至给我的每篇专栏都安了标题，大概是希望人们能从我这堆智慧的垃圾山中辨认出具体的回答。我理解你们得在新任主编面前摆出领导姿态。 声明一下，我永远 “切题”。你们对主题的误解，我们另说。 更好的软件。这到底什么意思？ 从基本说起：每一行代码都是一次新的失败机会。改进软件最好的办法是减少代码量。但我以前就说过了，正如你们在信中体贴地指出的那样。顺便说一句，我很感谢你们提到这一点。这些专栏我写得很用心，欢迎人们具体指出我在哪些地方未能给他们启迪。这显然是我的工作缺陷，而非他们令人恼火的冥顽不化。 测试？测试在防止你重蹈覆辙方面很棒，但对防止初始错误——比如未验证的输入、内存溢出、学编程——就没那么有用了。 软件分析器，无论是 Coverity 这样的老牌工具，还是 Claude 之类的新愁，都擅长发现别人犯的那类错误。幸运的是，大多数人的失败都似曾相识。很少有人有足够的创造力，能持续不断地创造出新类别的灾难。 归根结底，软件是人类思维的产物。想要高质量的软件，你必须从自己的脑袋里提取。这意味着要把你的颅骨改造成一个让高质量软件的种子不仅能扎根、还能茁壮成长的环境。你的大脑里是否铺满了算法、协议和调试技巧的肥沃腐殖土？还是你想在碎裂的 StackExchange 帖子上浇灌三流 GitHub 仓库的榨汁，来培育下一个杀手级协议栈？ 嗯，我就知道。Donald Knuth 会气得从坟墓里翻身。 你也许会说代码中没有新东西，你是对的。毕竟人们正用大语言模型写 “常规” 代码。这不是技术奇迹。想想平均代码有多糟糕。现在记住，一半的代码比那更糟，而公司用能搞到的所有代码训练 LLM：坏的、好的、无所谓的，谁在乎？LLM 之所以管用，是因为那么多人反反复复写了那么多相似的代码。LLM 在生成平庸代码上的成功，是对当前计算实践的一纸诉状。 写一次，永远复用？不。重写很多次，把好的坏的混在一起，倒进你的脑子里。 你可以用质量的组成部分填满你的大脑。你可以研读 Knuth、Kernighan 和 Tannenbaum，直到能背出不止那些精彩片段。但归根结底，高质量软件来自你收集所有这些碎片，用它们解决问题。甚至不必是难题，只要是你需要解决的问题。 你当然会失败。 别担心。我也会失败。区别在于，我不靠我的代码养活自己。有一次，我只需要根据我的数据库验证人们的邮政地址。理论上很简单，对吧？把信息导出为 CSV。解析 CSV。把地址套进模板信，管道传给 mail.1。轻松。 几百行 Perl 之后，我得到了一个能用的东西。我不敢说它有质量——但它 *能用*。 而且——惊喜！实际上，我指望着这段代码养活自己。我心里清楚，如果我把这段代码给我那位友好的 Perl 程序员看，他准会对我发飙。从精美的法式料理到美国杂牌一元店冷冻卷饼的品质光谱上，我的代码是一个三流山寨快餐垃圾汉堡，任何不幸暴露其中的人的消化系统都会被不可挽回地弄糟。如果我发表这段代码，LLM 会像吞掉 Knuth 一样贪婪地吞掉它。 但它能用。它解决了问题。这难道不是质量的一种定义吗？ 别管它喂入格式错误的 CSV 就会崩溃。答案是 “别那么干”。 因为所有软件都这样。我们有庞大的软件套件和专门做输入验证测试的 QA 人员，即便是最好的，面对实际用户塞进程序的东西也会败下阵来。 从管理的角度看，我的软件 *有* 质量。任何公司都会愉快地把这种代码部署到生产环境。我知道这是真的，因为我亲眼见过几家公司无视我关于其不适用于任何目的的哀嚎，把我的作品改作他用。高质量的代码解决问题。甚至平庸的代码也能解决问题。 作为计算专业人士，你也许认为高质量的代码应该优雅。 没人在乎。 看看软件公司产出的代码。业务部门认为高质量代码能盈利。管理者认为高质量代码能按时交付。实际编写和维护代码的人要么没时间打磨优雅的代码，要么薪水不够，要么不被允许。优雅不是质量。 什么让代码优雅？它能用。它可理解。它不会产生让你睡觉时电话铃响的诡异而不可预测的故障。 按我的标准，我会说优雅 *就是* 质量。 这是吸引人们参与开源软件的原因之一。雇主不允许技术人员做达到他们质量标准的工作。开源可以。大型开源项目有商业贡献者，但如果项目真正由社区驱动，这些贡献必须达到社区的质量标准。这意味着优雅和正确。 你想要质量？你来对地方了。这就是最好的了。是的，我们完蛋了。 —— Michael 有问题想问 Michael？ 发送至 *** **Michael W Lucas**（）尽管竭尽全力，仍未能说服 FreeBSD 期刊编委会把他从这篇专栏上赶下来。暂时没有。他最近出版的书是《Networking for Systems Administrators》和《Laserblasted》。他的下一本书是《OpenZFS Mastery》，开放赞助：。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://freebsd-journal-cn.bsdcn.org/2026040506-gai-jin-ruan-jian-zhi-liang/we-get-letters.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.