科研软件开发的软件工程实践——一份系统映射研究

Elvira-Maria Arvanitou, Apostolos Ampatzoglou, Alexander Chatzigeorgiou, Jeffrey C. Carver, Software Engineering Practices for Scientific Software Development: A Systematic Mapping Study, Journal of Systems and Software (2021).

论文笔记系列第三篇。前两篇分别是 Brooks《No Silver Bullet》（讲软件的本质困难）和 Parnas 1972（信息隐藏，讲怎么切模块）——都是"经典理论"。这一篇是"当代实证现状"：科研人员写软件时，到底用了哪些软件工程实践、又看重哪些质量属性。

一句话结论

基于 359 篇原始研究，科研软件开发者最关注"实现"和"测试"两件事，实践也偏向"让开发更省力"（复用、第三方库、框架、好用的编程技巧）；除了性能，可维护性和开发生产率也是重要驱动。最关键的缺口是：几乎没人研究这些实践的权衡（trade-off）与副作用。

研究背景

• 科研软件越来越大、越来越复杂、维护和复用需求越来越强；但开发者多是没有正规计算机背景的科研人员——上过两门入门课就开始自学编程，大量时间耗在跟软件搏斗上。
• 数据佐证：NSF 投入超 96 亿美元、支持 18000+ 项目；95% 的博士后报告要用软件；科学家 >40% 的时间花在构建软件上，却很少用上 SE 的成果。

方法：系统映射研究

• 类型：系统映射研究（systematic mapping study, SMS），而不是系统文献综述（SLR）——因为目的是概览与分类，不做结果综合，也不评估原始研究质量。
• 流程：Scopus + 四大数字图书馆（IEEE Xplore / ACM / Springer / ScienceDirect）初筛约 1000 篇 → 去重、按纳入/排除标准过滤 → 最终纳入 359 篇。
• 研究问题：
• RQ1：哪些 SE 实践被研究最多？
• RQ2：关注哪些质量属性？实践对质量有何影响？实证证据强度如何？（含 3 个子问题）

核心发现

1）研究集中在"实现"和"测试"

开发活动分布：实现 159 篇 ≫ 架构 71 > 测试 50 > 设计 28 > 需求 23。而维护只有 7 篇（不到 2%）——作者指出这是明显缺口：维护又重要又贵，却最少被研究。

2）最受关注的实践，多数是"让开发更省力"那类

• 降低开发难度：可复用代码识别、第三方库、开发框架、可演进的实现
• 测试：测试驱动开发（TDD）、回归测试、自动化测试
• 编码：编程语言、编译器、代码生成、代码管理
• 项目管理：标准化的开发流程（而非临时随意的方式）
• 质量保证：聚焦非功能需求的保障手段

3）质量属性优先级：性能第一

性能（performance）是头号优先级，其次是 可维护性 + 开发生产率；再往后是复用性、正确性、可靠性、可移植性等。

一个值得注意的点：可移植性在科研软件里格外重要，因为它和性能挂钩——比如为降低耗时要把计算从 CPU 挪到 GPU，代码必须能跨处理器、硬件、操作系统移植。

4）最突出的（也是作者意外的）结论：复用

科研软件的复用主要靠库复用（不像传统 SE 那样靠软件产品线 SPL）。但作者指出：这么丰富的可复用软件缺乏可见性，建议建立一个像 Maven 那样的可复用制品仓库。

5）关键缺口：缺乏"权衡"证据

几乎没人报告用了某个实践之后，对其他质量属性的负面/间接影响。作者反复强调：任何 SE 实践都很少没有副作用，也不会在所有场景下效果一致。

6）语言分布

C++ > C > Fortran > MPI > Java > Python > Matlab。
（符合科研计算的传统格局；Fortran 仍是大规模数学计算的主力，C 系语言则受益于自然科学专业的课程体系。）

对做科研代码的人的实用评价

如果你在写研究代码（比如做视觉/机器学习实验），你正是这篇论文描述的"科研软件开发者"：

• 优先复用：延续"买 vs 造"的默认；别重造轮子。
• 性能是硬约束：作者明确劝研究者不要为了别的质量属性牺牲性能；任何改进（重构、加抽象层）都要评估其对性能/精度的影响。
• 做权衡分析：这条直接呼应 Parnas——解耦/信息隐藏能提可维护性，但有性能代价（Parnas 本人也承认）；这篇用 359 篇实证告诉你，这个代价普遍被忽略。
• 补短板：维护与需求活动被严重忽视；留好可复现、可维护的"需求"（评测协议、数据假设）比多写一个模块更值钱。

一个免责提醒：mapping study 只做分类与计数，不给"结论强度"分级——所以"被研究得多"不等于"被证明有效"。作者自己把"实证证据不足（尤其 trade-off）"列为最重要的未来方向。

术语表 / Key Terms

• systematic mapping study (SMS) — 系统映射研究；概览/分类式的系统性综述，不做结果综合，也不评估原始研究质量
• systematic literature review (SLR) — 系统性文献综述（与 SMS 相对，强调结果综合与质量评价）
• primary study — 原始研究（一级研究）；被映射/综述逐一分析的每一篇文献
• research question (RQ) — 研究问题
• GQM (Goal-Question-Metric) — 目标-问题-度量框架；用"目标→问题→指标"组织研究设计
• software engineering (SE) practices — 软件工程实践
• scientific software / scientific computing — 科研软件 / 科学计算
• HPC (High Performance Computing) — 高性能计算
• quality attribute (QA) — 质量属性
• non-functional requirements — 非功能需求（相对于功能性需求）
• maintainability — 可维护性
• reusability / reuse — 可复用性 / 复用
• portability — 可移植性
• correctness — 正确性
• reliability — 可靠性
• scalability — 可扩展性
• productivity — 生产率
• development activity — 开发活动（需求 / 设计 / 实现 / 测试 / 维护…）
• implementation — 实现（编码阶段）
• SDLC (Software Development Life Cycle) — 软件开发生命周期
• test-driven development (TDD) — 测试驱动开发
• regression testing — 回归测试
• automated testing — 自动化测试
• third-party library — 第三方库
• framework — 框架
• CBSE (Component-Based Software Engineering) — 基于组件的软件工程
• COTS (Commercial Off-The-Shelf) — 商用现成品（软件）
• SPL (Software Product Line) — 软件产品线
• domain-specific language (DSL) — 领域特定语言
• refactoring — 重构（文中作为"须评估其对性能影响"的例子）
• trade-off analysis — 权衡分析；应用某实践时在不同质量属性之间的取舍
• side-effect — 副作用；此处特指应用某实践对其他质量属性的间接负面影响
• ad-hoc process — 临时/随意的（开发）流程（相对于标准化流程）
• digital library — 数字图书馆（文献数据库，如 IEEE Xplore）
• inclusion / exclusion criteria — 纳入 / 排除标准
• threats to validity — 有效性威胁（研究局限的正式说法）
• empirical evidence — 实证证据
• catalogue — 目录 / 清单（文中指 SE 实践清单）

---

论文笔记系列。前两篇：软件构架：本质任务和附属任务（Brooks, 1986/1987）；软件构架：按什么标准把系统切成模块（Parnas, 1972）。