# 为何糟糕的科研代码胜过严格遵循编程规范的代码 [译]

- Link: https://paooo.com/ai-study/8510/
- Published: 2024-08-25T18:15:30+08:00
- Author: 宝玉的分享

⚡ [Prompt](https://paooo.com/ai-image-prompts/) 语宙 AI 导读 · 30 秒核心看点

 * 科研代码常有命名差、函数长、全局变量多等问题，但通常仍更容易读懂和修复。
 * 软件工程式复杂设计会让调试、搜索和追踪调用链变得极其困难，反而降低可维护性。
 * 作者强调：在科学场景里，简单无聊的实现有时比过度专业化的“高级工程”更实用。

我刚读了一篇名为“科学代码的低质量”的文章，作者认为科学家编写的代码质量不如涉及到“
软件工程师”的情况。

在过去的十多年里，我一直在一个以数学或物理背景人士为主的环境中工作，这里的人对“软件
工程”的了解相对有限。

一直以来，最大的混乱往往是那些自认为是程序员的少数人造成的。我必须承认，自己也曾
制造过几次大混乱，而这些混乱至今还未得到解决。还有几次其他的大混乱，幸好代码被废弃
了，这意味着给我的雇主造成的损害仅限于我薪水的浪费，没有对他人的工作效率产生负面
影响。

我声称自己基本上已经改过自新了。我努力保持事情的简单无聊，并且我认为在过去 5-6 年
里，我没有做过什么让许多人因为处理我错误的聪明创意而奇怪地看着我。

我也知道一些程序员明确地没有改过自新。人们怪异地看着他们，而他们则认为自己是对的，
是其他人疯了。

同时，那些不是程序员，但更像是数学家、物理学家、算法开发者、科学家等人，通常会犯
以下几种错误：

 * 函数过长
 * 取名不佳（如 m、k、longWindedNameThatYouCantReallyReadBTWProgrammersDoThatALotToo）
 * 随处访问 – 全局变量/单例、“全能对象”等
 * 崩溃（空指针、边界错误），主要依靠 valgrind 和大量测试来减轻
 * 对并行编程错误的漠不关心（几乎完全依靠工具解决）
 * 过于轻易地使用那些由聪明的程序员编写的库，这些库中充满了重载操作符和模板等复杂
   内容

我觉得这些还算可以处理。如果有人需要我的帮助来调试某些东西，我通常能够理解这些人
在软件方面想要做什么。在算法层面，我可能不完全理解他们。但是他们想把哪个变量传递
给哪个函数，我通常都能明白。

而软件工程师的错误则完全不同：

 * 复杂的多重/虚拟继承
 * 主要由轻量包装构成的 7 到 14 层栈帧，其中包括函数指针/虚函数，可能还在中断处理
   程序中
 * 文件散布在无数目录中
 * 使用来自地狱的动态结构进行查询 – 如运行时拼接各种部分形成的名称的字典等
 * 动态加载和其他难以追踪的技术
 * 一系列近乎相同的名称，如 DriverController、ControllerManager、DriverManager、
   ManagerController、controlDriver 等，它们相互调用
 * 模板调用重载函数，希望在模板定义的地方可见声明，或许不可见
 * 使用装饰器、元类、代码生成等技术

其结果是，你不知道谁调用了什么或为什么，调试器的作用有限，集成开发环境和搜索工具
几乎

无法使用。你几乎不得不放弃理解这一切，直到泪水不自觉地流出。

当然，这是一个夸张的描述，不是每个人在任何时候都是罪人，而且我主要是一名“程序员”
而不是“科学家”，我真诚地认为我的工作总体上是有积极成效的 – 但你应该明白我的意思。

科学代码能从更好的“软件工程”中受益吗？也许可以，但我不相信软件工程师能带来这些益处！

简单的思维、无忧无虑的近乎无能有时可能比满怀好意却铺设了通往地狱的高速公路的工业
级专业更为有益。计算机外的“真实世界”充满了这样的例子。

哦，还有一个非常尖锐的观察，我害怕这太过真实而不能忽略：懒惰是许多问题的根源。科学
家忙于科学研究，因此他们没有时间无谓地增加代码的复杂度。许多程序员的工作实际上并不
复杂 – 任务很简单 – 所以他们有太多的时间，他们用这些时间沉迷于“API 设计”，于是就
产生了怪物。

（实际上，当工作在技术或社会层面上远非琐碎时，程序员糟糕的训练使他们的注意力偏离
了直接的职责 – 这个东西是否真的运行良好、易于使用、高效/经济等 – 而是宣称自己只负责
神圣的 API，并开始使其变得异常复杂。与此同时，从功能上来说，这个东西几乎无法运行。）

❓ 常见问题解答（FAQ）

为什么作者认为糟糕的科研代码反而更好？

因为这类代码虽然不规范，但通常结构直白、变量和函数关系容易看懂，出了问题也更容易
定位。相比之下，过度工程化的代码常把复杂性藏进继承、模板、动态加载和元编程里，调
试成本更高。

文章里批评的软件工程式代码有哪些典型问题？

包括复杂的多重/虚拟继承、层层包装的调用栈、目录和文件过度分散、动态结构查询、动态
加载、相似命名混乱，以及模板、装饰器、元类和代码生成带来的可追踪性下降。

这篇文章是否主张完全不要软件工程规范？

不是。作者承认这是夸张表达，也承认更好的工程实践可能有帮助；但他强调在科学代码场景
中，过度追求“优雅架构”常常适得其反，简单、直接、可理解更重要。

🔬 语宙深潜追问 · 进阶实操拆解

科研代码如何兼顾可读与可复现？

优先把实验流程写成线性脚本，减少抽象层级，并固定随机种子、依赖版本和输入输出。再
用少量注释说明科学意图，而不是追求工程化框架，保证别人能快速复现实验。

什么时候该重构科研代码？

当代码开始被多人复用、实验频繁迭代或结果依赖复杂配置时，就该抽出核心模块。重构目标
不是“变优雅”，而是把最容易出错的参数、数据路径和评估逻辑收拢起来。

🗳️ 读者观点微投票 · 您的实战立场是？

科研代码真的越朴素越好吗？

🕸️ 语宙向量知识图谱 · 语义强关联深度内链

[🐋 所属权威专题：DeepSeek 深度实战与部署 →](https://paooo.com/topics/deepseek/)

 * [为什么我对低代码持怀疑态度 [译]](https://paooo.com/ai-study/8463/)
 * [技术细节：简单说“不是高深莫测”（单调与 bors 的历程）[译]](https://paooo.com/ai-study/8647/)
 * [代码并非技术债 [译]](https://paooo.com/ai-study/7137/)
 * [如何构建高质量软件：一个被忽略的课题 [译]](https://paooo.com/ai-study/7075/)

[🏛️ 宝玉的分享](https://paooo.com/author/baoyu/) · 前沿大模型翻译与提示词工程实战
分享专栏，聚焦海外一手 AI 技术动态与工程实践。

[📄 Markdown 纯净版](https://paooo.com/ai-study/8510/?format=md)

💡 这篇内容对您有启发吗？

[📡 RSS 订阅](https://paooo.com/feed/)[✨ 提交 AI 工具 / 合作](https://paooo.com/submit-tool/)

**🚀 Prompt 语宙 AI 创作者生态：**探索 2,800+ 全球实用 AI 工具与高精度生图提示词
咒语库

[🧭 语宙 AI 导航 (ai.paooo.com)](https://ai.paooo.com/)[🎨 AI 生图 Prompt 库](https://paooo.com/ai-image-prompts/)
[📚 核心专题导航](https://paooo.com/topics/)[⚡ AIGC 早报生成器](https://paooo.com/mtool/)