“开发人员缺乏技能”。

或许。

我认为开发商缺乏激励的可能性更大。编写可靠的代码既困难又昂贵，而且在学术界，回报很少甚至是负面的。您要的是一份指南清单，但您的所有示例都是针对技术情况的，而不是针对社会情况的。那是自找麻烦。

获得优质软件的一种方法是改变激励措施。在我作为编辑的工作中，如果作者没有发布他们的源代码或者源代码不符合我的（诚然是自定义的）标准，我会发回论文。一些期刊，如 JOSS，更进一步，并为他们期望看到的内容提供了指导方针。如果您发现自己处于审稿人或编辑的权力位置，请利用这种影响力帮助您的领域进入 21 世纪。

如果你是学生，或者指导学生，你应该知道获得终身教职是很难的。因此，一个理性的人会在攻读博士学位期间寻求发展多样化的技能。他们说 Github 是新的简历。拥有可靠的、经过单元测试的、文档化的代码是替代学术轨道（研究程序员）以及行业和政府的一个有价值的指标。将其用作自己和他人的胡萝卜。

正如 JOSS 指南所说，您应该为您的项目制定一份贡献者指南，也许还有一个PR 模板。如果你想要好的代码，你需要让人们更容易帮助你构建它。如果您处于高级职位，您还需要一种方法来教育您的学员，尤其是您自己。像Software Carpentry这样的程序可以帮助解决这个问题。

简而言之，除了一些显着的例外，软件的好坏取决于产生它的激励措施。

我还强烈推荐论文“科学计算中足够好的实践”。

我维护（并且是主要编码人员）一个已经开发了大约 8 年并被数百人使用的模拟软件。这一切都始于我攻读博士学位期间的一个附带项目，而且它显然已经超出了自己的规模。它既过度设计又设计不足：某些部分的架构对于它们自身而言过于复杂，而其他一些部分（其重要性随着时间的推移而增加）在开始时设计得不够仔细。我将尝试将我的经验总结为几点/指南，当一切开始时我很想被告知：

• 一旦你的代码可用（也就是说，它可以用于研究项目），就开始编写使用示例和用户手册。让它们保持更新将是很多工作，但它会让您以后的生活更轻松。
• 关于源内文档：使 doxygen 的东西保持最新将需要比人们天真的预期更多的工作。确保有一个热衷于保持更新的开发人员团队。
• 从一开始就征求用户反馈，并准备好在增加功能时调整架构。
• 同样，准备好经常重构代码，至少在早期阶段是这样。我认为一开始过度设计的风险非常高。如果您不能 100% 确定自己需要什么，最好先从轻量级代码开始，然后再对其进行重构，而不是从以后很难触及的庞然大物架构开始。这是我现在正在努力解决的一个问题：我一开始就做出的决定确实损害了我添加我非常需要的功能的能力。
• 添加依赖项时要小心：成功的模拟代码会持续很多年，而您可能想要包含的小型库以避免编写一些代码可能不会那么长久。此外，模拟代码通常面向性能：如果您想在内核中包含库，请确保它们的性能能够胜任任务。

tl;dr：看看我们的领域之外，首先遵循Linux 基金会核心基础设施倡议徽章指南，然后也许还可以看看 HPC 模拟软件的xSDK 政策。

这个问题真的很好，因为它描述了每个研究软件开发人员发现改进其软件的非功能方面的新可能性时的恐慌。

我认为我们应该避免仅仅复制其他科学计算项目的实践。是的，你肯定会在几个（非常重要和成功的）项目中找到好的实践，但我们的领域通常是一位同事过去介绍的想法的回音室，他们工作了一段时间，但我们领域以外的人没有评估。是的，我们的项目确实有一些特殊的需求，但是对于很多问题，目前主流的解决方案已经足够好了。

示例案例：OpenFOAM 可能是目前最常用的免费/开源模拟框架。但我确实只是在尝试查找是否有人提出 OpenFOAM 的自动代码格式化时发现了这个问题。在那个社区中，“干净的代码”仍然包括“它遵循样式指南”，这需要手动完成。几分钟前，我试图让我的 IDE 找到标头，因为 OpenFOAM 不使用通用的构建配置系统（出于历史和向后兼容性的原因）。

遵循原始问题和其他答案中引用的指南列表已经是一个非常好的步骤，请记住，其中一些可能正在研究特定领域或用例。

如果您正在寻找更一般的最佳实践的概述，以及来自不同领域的数千个项目（不仅是研究软件），您可以关注Linux 基金会 (LF) 核心基础设施倡议 (CII) 最佳实践徽章。

对于模拟软件，您可能还需要查看xSDK 政策，以获取有关科学软件和专门针对高性能计算的更多技术指南。

对于当今任何规模的大多数健康项目来说，获得“通过”级别应该很容易。对于有多个开发人员和用户的项目来说，进入更高的级别可能是有意义的，而研究软件通常不是这种情况。