开发一次性代码的好策略？

Question

我经常编写一次性代码(在研究环境中) - 例如,探索科学属性或过程的算法或模型.许多这些"实验"都是一次性的,但有时我发现我需要稍后使用一些.例如,我刚刚发掘了7年前写的字符串匹配代码(由于其他优先级而停止)但现在对于同事的项目很有价值.看了之后(我真的写了这样难以理解的代码吗？)我意识到当我重新启动"项目"时,我可以做一些事情来帮助我("实验"仍然是一个更好的词).早期的实验"有效"但我知道当时我没有时间重构,因为我的优先事项在其他地方.

哪些方法在挖掘和重复使用这些工作方面具有成本效益？

编辑:我已经回答了我自己的问题(下面),因为除了实际的来源本身之外还有一些问题.

Answer 1

我不同意所有说"写评论"的答案.这是代码本身不可理解的全面提供.

给自己一份Code Complete(Steve McConnell,第2版).如果您首先学习编写可维护代码的技巧,那么您将不会花费更多时间,并且您将能够以更少的麻烦返回工作岗位.

你更喜欢哪个:

• 带注释的隐秘代码？
• 大多数OK代码没有？

我非常喜欢后者,因为在隐藏代码被取消注释的情况下,OK代码更容易理解,而注释是原始开发人员可能犯错误的另一个地方.代码可以是越野车,但它永远不会出错.

一旦你对Code Complete感到满意,我就会推荐The Pragmatic Programmer,因为它提供了更高级别的软件开发建议.

Answer 2

[回答自己的问题]问题还有其他几个方面尚未提出,在重新审视时我会觉得有用.其中一些可能是"不言而喻"的,但请记住这段代码是SVN和IDE之前的版本.

• 可发现性.实际上很难找到代码.我相信它在我的SourceForge项目中,但有7年多的版本和分支,我找不到它.所以我必须有一个搜索代码的系统,直到IDE出现我认为没有.
• 它有什么作用？.当前结账包含大约13个类(所有在一个包中,因为当时不容易重构).有些是clear(DynamicAligner)但有些是不透明的(MainBox因为它扩展了Swing Box而命名).有四个main()程序,分布中实际上有大约3个子项目.因此,关于组件实际是什么,有一个外部清单是至关重要的.
• 有关如何运行它的说明.在运行程序时,main()将提供简短的命令行用法(例如DynamicAligner file1 file2),但它没有说明文件的内容实际上是什么样的.我当时知道这一点,当然不是现在.因此兄弟目录中应该有关联的示例文件.这些比尝试记录文件格式更有价值.
• 它仍然有效吗？.应该可以不假思索地运行每个示例.第一个问题是相关的库,运行时等是否仍然相关且可用.一位前同事写了一个系统,该系统只运行特定版本的Python.唯一的答案是重写.所以我们当然应该尽可能避免任何锁定,而且我已经训练过自己(虽然不一定是同事)来做这件事.

那么我和同事怎么能避免将来出现问题呢？我认为第一步是在创建代码时应该有一个创建"项目"(无论多小)的规则,并且这些项目应该受版本控制.对于你们中的一些人来说这听起来很明显,但在某些环境(学术界,国内)中,建立项目管理系统会产生巨大的开销.我怀疑大多数学术代码都没有任何版本控制.

然后是关于如何组织项目的问题.默认情况下,它们不能在Sourceforge上,因为代码是(a)无关紧要,(b)默认情况下不打开.我们需要一个可以同时存在公共项目和私有项目的服务器.我会计算出设置和运行它的努力大约是0.1 FTE - 一年20天来自各方(安装,培训,维护) - 如果有更容易的选择我想知道因为这是一个很大的在某些情况下的费用 - 我是否花时间设置服务器或写论文？

该项目应该努力鼓励良好的纪律.这真的是我希望从这个问题中获得的.它可能包括:

1. 所需组件的模板(清单,自述文件,提交日志,示例,所需库等.并非所有项目都可以在maven下运行 - 例如FORTRAN).
2. 一种搜索大量(至少数百个)小项目用于助记符字符串的方法(我喜欢在Googledocs中转储代码的想法,这可能是一个富有成效的途径 - 但这是额外的维护工作).
3. 明确命名约定.这些比评论更有价值.我现在经常使用iterateOverAllXAndDoY类型的名称.当例程实际创建信息时,我尝试使用createX()而不是getX().我养成了调用例程process()而不是convertAllBToY()的坏习惯.

我知道但没有使用过GIT和Mercurial以及GoogleCode.我不知道这些设置需要付出多少努力以及他们回答了多少我的担忧.如果有一个IDE插件可以帮助创建更好的代码(例如"方法名称选择不当"),我会很高兴.

无论他们采取何种方法,他们都应该自然而然地得到那些不具备良好代码规范并值得付出努力的人.