研究时应该遵循哪种软件方法？

我通常会分析实验数据，尽管我有一个大致的步骤计划，但可能需要根据实验的具体细节或后面的问题进行调整。我通常是唯一的一种编码。

我看了维基百科，但不确定要使用哪种方法，部分是因为我从未使用过任何方法，部分是因为我有时只是探索数据，看其外观，而其他时候我只想找到答案。（并且因为我不太希望测试或在代码上具有一定的素质）

一两个小时后，系统提示我问这个问题，因为发现r函数table依赖于向量的顺序，而不是要与之进行比较的元素名称。然后，尽管我应该在使用某些模拟数据的地方测试行为和功能。但是我在其他分析之后使用表格导致信息不足，因此我无法遵循测试驱动的开发方法（如果我理解正确的话）。但是，我觉得通过改进项目的处理方式，我可以提高效率，除了可以更快地发现错误之外，还可以找到错误的内容和方式，以防万一我对结果有所怀疑，所以请不要仅仅关注这个例子的错误。

哪种软件方法最适合研究？

我基本上是在问如何确保质量和时间进度以及保持研究的特异性。

我的工作方式示例：

一位生物学家想到了一个问题，并且知道进行一项实验会获得感兴趣的数据（即，两种条件下的基因表达水平），然后她/他进行了实验并从10个人/小鼠/大鼠中收集了样本。现在，我必须使用现有的库和测试（或实施新的测试）来分析那10个样本的数据，但要考虑到生物学家所考虑的问题（即，一种基因比另一种基因表达更多的基因）。其结构与先前的实验相同（涉及6种条件和另一只动物），但统计检验，规范化，数据结构可能会发生变化。因此，我通常会复制以前的版本，并使其适应当前的需求。

可能需要的不是软件方法论，而是学术界的政治变革，该变革解决了人们对科学软件开发所扮演的角色缺乏认识的问题。

该软件可持续性协会（UK）是最接近你在找什么机构：如何主张科学研究更加自觉利用计算机编程的。

它还为那些对软件开发方法学感兴趣的人提供了信息指针。

但是，我必须指出，方法论通常通过迭代和逐步完善项目目标来支配软件程序员团队，并且可以与长期稳定的代码库协同工作。它们用于比您正在做的事情复杂几个数量级的项目。

关于为什么这个非常明显正确的事情（在科学研究中更加认真地使用计算机程序）尚未实现并始终得到支持，这是一个不便的事实：在学术管理环境中，可以看到科学家降低了计算机的重要性。编程。有时可以看到它们团结在一起，否认对参与软件的人员所做贡献的认可，即使这种贡献的性质符合科学学科的要求。

• http://www.scientific-computing.com/news/news_story.php?news_id=2737
• https://news.ycombinator.com/item?id=10553837

在您的工作场所中，有些事情丢失了，您可以做。

缺少的东西：

• 缺乏指导方针
• 缺乏监督或有人问问题
• 缺乏对您使用的工具（例如R）有所了解的指导者或计算机程序员
• 缺乏软件重用性，存档，版本控制或以前开发的软件的文档，以实现可重复性和学习目的

简而言之，总体文化是所涉人员并不真正感兴趣……您猜到了……在科学研究中更加认真地使用计算机编程。

您可以做的事情：

• 花更多时间学习您的工具。
  • 花更多时间阅读编程语言的文档和代码示例
  • 您将必须学习热爱所使用的工具。
• 尝试写下一些东西，以利于下一个计算机程序员的利益，该程序员将在未来几年内被奴役到同一批人中
  • 维基将是极好的。
• 尝试设置源版本控制
  • 能够检索常用的代码段
  • 能够保存特定实验中使用的代码的快照

对于职业软件开发人员，可以在以下位置找到这种性质的准则：

• Joel测试：Joel Spolsky编写更好代码的12个步骤

这些被认为是运行软件开发业务的基本要求。但是，当您独自进行冷漠战争时，您需要确定优先级。使用这些工具变得更好，编写和维护信息，保留源代码的版本是唯一环境的最低要求。

不要太在意方法论，而是尝试将更多的精力集中在软件开发本身需要跟踪的需求和需求上。

我可以从我的个人经验中提取一个短暂的职位，与您在这里的职位相对类似。

算法准确性

也许是最重要的方面，您应该能够证明您的软件能够完成其设计工作。在这里，自动化测试是您最好的盟友。我意识到没有适当的数据集可能很难做到，但是实际上您应该养成创建自己的数据集的习惯。但是，它们的目的有些不同，您不是要从数据中提取趋势，而是要确保软件从已知数据集中产生可预测的正确结果。因此，例如，对于模式识别，您不需要多次演出的基因构成，仅需几行文本就可以确保算法检测到模式。

我曾经用我的数据来表示极端情况，不可能的情况。我倾向于将重点更多地放在极端而非预期的规范上。很多时候，我记得做过一些不可能的测试，只是看到这种情况在实际数据集中出现了。如果没有对此进行测试，就不会进行必要的错误检测和日志记录，以识别数据集中的潜在损坏或错误。TDD非常适合此部分，尽管我认为无论您在实际代码之前还是之后创建一个良好的测试集，它都更为重要。

版本控制

这部分经常被遗漏。为您的代码和生成的程序包/可执行文件提供良好的版本控制架构将极大地帮助您保持进度。为了能够准确地恢复以前创建结果所使用的代码，在跟踪错误或差异时会有所帮助。在尝试不同的方法或算法时，分支也可以提供帮助。

确保标记用于实际计算的代码，如果需要命名版本方面的帮助，请查看语义版本控制。

自动构建

推论到上述观点。确保尽可能自动地构建和打包软件。您无需全力以赴，仅需使其变得微不足道即可从源代码和依赖项创建最终系统。这样做的目的是节省您的时间，同时又具有可重现的手段，可以从源头（包括依赖项和其他外部组件）重新创建软件。Groovy，Maven，ant，Scons和cmake只是构建自动化工具和可以提供帮助的脚本系统的一小部分。

如果您想加倍努力，请安装Jenkins或teamcity或任何其他持续集成系统。如果您必须维护多台服务器或多个工作人员以进行分布式计算，则可以增加奖励。这些系统中的大多数将具有帮助维护的手段。另外，您将能够完全自动化测试运行，因此您无需等待结果就可以继续操作，只需提交并稍后再接收邮件即可。我有一个系统，要花几个小时才能通过测试集。设置这种自动化是我那段时间最好的投资。特别是如果您已经拥有用于构建所有内容的脚本，则尤其如此。

环境隔离

研究人员花费大量时间通过协议从复杂系统中分离出一组感兴趣的变量或一小部分。这也应扩展到您的软件开发实践。您还可以使用Docker或Vagrant检查容器化。它可以使您更好地控制运行该软件的环境。

您无需拥有一支庞大的团队就可以得到回报，大多数时候我独自一人，但是受益匪浅。省时省心，省心，远远超过了我为此付出的开销。

1. 可以使用R吗？那就是它的目的。

2. 保持代码简单。追求可读性，除非有问题，否则不要担心性能。存在一些方法来尝试阻止程序员团队在彼此的代码中放入错误，即使团队是一个人也是如此。

3. 就是说，编码纪律非常重要。我看过训练有素的高级科学家和数学家的代码，这太糟糕了。他们完全忽略格式。他们像真空包装一样将代码压缩在一起。它们的变量名是完全神秘的。他们不写注释，或者写难以理解的注释，或者注释说一件事，而代码说另一件事。不要做那些事。始终思考未来您或其他人可能需要做出的更改。