我经常编写一次性代码（在research environment 中）——例如探索科学属性或过程的算法或模型。许多这些“实验”是一次性的，但有时我发现我需要稍后再使用一些。例如，我刚刚发现了 7 年前编写的字符串匹配代码（由于其他优先事项而停止），但现在对于同事的项目很有价值。看过它（我真的写了这么难以理解的代码吗？）我意识到当我重新启动“项目”时，我可以做一些事情来帮助我（“实验”仍然是一个更好的词）。早期的实验“奏效”了，但我知道当时我没有时间进行重构，因为我的优先事项放在其他地方。
在挖掘和重复使用此类工作方面，哪些方法具有成本效益？
编辑：我已经回答了我自己的问题（如下），因为存在超出实际来源本身的问题。
【问题讨论】：
标签： reusability throwaway
不，不，不，不，不！
即使在研究环境中也不要编写一次性代码。请！
目前我正在处理这样一个“一次性代码”，即 BLAST 项目。问题是它开始是一个游乐场，但后来碰巧变得有些成功，现在它是一个实现了许多概念的简洁工具，但代码几乎无法维护。但这不是重点。
重点是，您为工程师进行研究，以便日后从您的发现中受益。在完成了关于一般概念的良好科学工作并编写了一个证明这一点成功的工具之后，您很容易忘记您这样做并不是为了发表文章和获得博士学位。你这样做是为了人类的利益。您的代码可能包含一堆难以调试的“特殊情况”、一组不适合任何会议文章的怪癖和技巧。在整个代码中记录和注释此类内容尤为重要。
如果开发人员决定在商业产品中实现您的概念，他可能已经研究了您代码中的怪癖和技巧，并且实现过程中的错误将比实际情况少十个。每个人都说“哇，他对A的研究真的很有用！”但如果你写“一次性”，他们会说“他的概念在纸上看起来不错，但 X 试图实现它并淹没在一堆错误中”。
（编辑：取自下面的 cmets）为了帮助您的代码库的未来开发人员，您不需要太多。首先，评论每个函数的作用。其次，确保对棘手错误的每个非显而易见的修复都放在修订控制系统中的单独提交中（当然，带有适当的注释）。这已经足够了。而且，如果您甚至将事物模块化（即使它们还没有准备好进行彻底的重复使用——根据 Brooks 的说法，成本会高出三倍），您将会受到实施您研究的工程师的喜爱。
我认为，如果研究人员摒弃傲慢，不再傲慢地认为他们不是这些肮脏的编码人员，只是为了编写好代码而做着卑微的工作，那么世界将会变得更美好。编写好的代码不仅仅是这些愚蠢的程序员的工作。这是每个人都应该努力的真正有价值的事情。没有这个，你的实验场、你的代码、你的创意都将死去。
【讨论】：
svn blame)。这只会让人们重复使用你的作品，从而给你一个荣誉和归属。
我认为最重要的事情（如果你不重构它就不会发生）是评论并记录你当时的思考过程。这将有助于使代码不那么难以理解，并帮助您在需要时找到好的部分。
【讨论】：
正如您在other post 中的出色回答所表明的那样，根据我自己的经验，用于研究的软件和已设计的软件之间存在难以跨越的差距。在我看来，Code Complete 可能会有所帮助，但作用不大。作为一个经济问题，与偶尔为某事找到以后的用途而获得奖励相比，重构所有内容以供重用是否值得？您的平衡点可能会有所不同。
这是存储 sn-ps 的实用技巧。代替成熟的 cmets，输入一些关键字：
然后将代码放在 Google 可搜索的位置，例如 GMail 帐户。
编辑：我可以补充一点，免费的 Google 协作平台是真正可搜索的 wiki，是放置代码的好地方，无论是附件形式还是粘贴形式。
另外，我应该说我是 Code Complete 的粉丝，并且已经为研究生提供了几年来为科学研究编写软件的副本。这是一个好的开始，但没有灵丹妙药。我现在正在写一篇关于使用开源框架解决科学数据管理问题的论文，其中一个结论是，一些软件工程专业知识对于长期运行的系统是必不可少的。许多科学项目可能应该从一开始就为此进行预算。
【讨论】：
我可能错过了整个讨论的重点，我经常这样做，但这里是邀请砖块和投反对票......
如果是一次性代码，就把它扔掉！
如果您不想扔掉它，请遵循上面的好建议。对我来说，我写了相当多的一次性代码，它是被丢弃还是进入可重用状态并以防万一的问题归结为经济学。
我能否预见到这段代码将再次有用的情况？千载难逢，一年两次，每月一次？
我能否在比使其可重用所需的时间更短的时间内重写此代码？如果这个问题的答案是否定的，那么我必须重复使用多少次才能使其在增强它的同时变得有价值？ （回到上一个问题。）
如果我确实让这段代码可重用，我下次想要它时还能再次找到它吗？ （任何人都曾有过这样的经历，可以绝对肯定地知道，在您的代码存储库中的某个地方只有您想要的片段，但不知道它叫什么，也不知道在哪里寻找或用 grep 查找什么？）
最后，让快速编写的代码可重用的 3 步方法。在您喜欢的任何这些步骤之后停止：
1) 将代码记录为黑盒。输入、输出、操作。仔细归档此文件。
2) 编写有关如何构建/解释/安装代码的说明，以防您必须移植它。仔细归档这些说明。
3) 只有在值得努力的情况下——提高源代码质量以使代码在未来可维护。确保源代码在源代码控制系统中并且可以找到。
问候
标记
【讨论】：
您还可以从 TDD（测试驱动开发）人员那里借用单元测试的想法。您需要确保一次性代码实际上可以正常工作，那么为什么不将检查链接表达为一个小单元测试呢？这有两个好处：
阅读测试代码可以非常清楚地传达一次性的意图：毕竟它用相同的语言表达了它的期望：代码。
这也有助于解决您自我回复的第四个问题：“它仍然有效吗？”。嗯，这很简单：只需运行单元测试，它们就会告诉你什么和在哪里（运气好的话）为什么（它）不起作用。
【讨论】：
[回答自己的问题] 该问题还有其他几个方面尚未提出，并且在重新审视它时我会发现它们很有用。其中一些可能是“不言而喻的”，但请记住此代码是 SVN 和 IDE 之前的代码。
DynamicAligner），但有些是不透明的（MainBox，因为它扩展了一个 Swing Box 而得名）。有四个main() 程序，实际上分发中大约有3 个子项目。因此，拥有一个关于组件实际是什么的外部清单至关重要。main() 将提供一个简短的命令行用法（例如DynamicAligner file1 file2），但它并没有说明文件内容的实际样子。我当时当然知道这一点，但现在不知道。所以在同级目录中应该有关联的 example 文件。这些比尝试记录文件格式更有价值。那么我和同事如何才能避免将来出现问题？我认为第一步是在创建代码时应该有一个创建“项目”（无论多么小）的纪律，并且这些项目应该受到版本控制。这对你们中的一些人来说可能听起来很明显，但在某些环境（学术界、国内）中，建立项目管理系统会产生很大的开销。我怀疑大部分学术代码不受任何版本控制。
然后是如何组织项目的问题。默认情况下，它们不能在 Sourceforge 上，因为代码 (a) 微不足道，并且 (b) 默认情况下不打开。我们需要一个服务器，其中可以有公共项目和私人项目。我会计算出设置和运行它的工作量约为 0.1 FTE - 每年 20 天来自各方（安装、培训、维护） - 如果有更简单的选项我想知道，因为这是一个大某些情况下的费用 - 我是花时间设置服务器还是写论文？
该项目应尽量鼓励良好的纪律。这确实是我希望从这个问题中得到的。它可能包括：
我知道但没有使用过 GIT 和 Mercurial 和 GoogleCode。我不知道这些需要付出多少努力，以及他们回答了多少我的担忧。如果有一个 IDE 插件可以帮助创建更好的代码（例如“方法名称选择不当”），我会很高兴。
对于那些不具备良好代码纪律并且值得付出努力的人来说，他们必须自然而然地采用任何方法。
【讨论】：
我会回应其他人所说的，就评论为什么编写代码及其预期用途的“原因”，但我也会添加以下内容：
即使您只是在胡闹，也可以像计划将其投入生产一样编写代码。代码：
我要特别强调第一点，但其他点也很重要。我发现如果我以后使用“测试代码”，我倾向于只在它有效的情况下使用它，而不是重构它。
【讨论】：
我不同意“写 cmets”的所有答案。这是作为一个包罗万象的代码本身无法理解的。
为自己获取一份Code Complete（Steve McConnell，第 2 版）的副本。如果你一开始就学会了编写可维护代码的技巧，就不会花费你更多的时间，而且你以后可以更轻松地回到你的工作中。
你更喜欢哪个：
我更喜欢后者，因为在未注释神秘代码的情况下，OK 代码更容易理解，而 cmets 是原始开发人员可能犯错误的另一个地方。代码可能有错误，但绝不会错误。
一旦您对 Code Complete 感到满意，我会推荐 The Pragmatic Programmer，因为它提供了更高级别的软件开发建议。
【讨论】：
评论 - 描述您的想法以及您选择以某种方式实施某事的原因，包括您考虑过的替代方案。可能有各种奇特的解决方案，但在编写代码时正确注释代码似乎效果最好。
【讨论】：
一些策略：
【讨论】：