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