困难的代码包装设计

Question

我使用静态站点生成器编写大学课程的工具构建了一个奈米。Nanoc是一个很好的基于Ruby的包，它是作为一个宝石分发的。

我安装了gem，并使用“new”命令创建了基本目录结构。在这个目录结构中，我编写了一些定制的ruby代码，以及大量的标记文件来定义我的第一个课程。这是建好的课程。

我上面展示的代码，在git中，对应于这一工作的结果，nanoc + my定制。有一个绑定文件，必须运行，以带来我的额外宝石以及。

让我们将个别课程称为"cosi235a.course“，并将我的工具称为”纳米课程“。我将称cosi235a.course的作者为“作者”，我将称“毫微课程”的维护者为“我”。

我寻求帮助的是一个很好的设计，使纳米课程与cosi235a.course脱钩。换句话说，我想将我定制的基于纳米的工具与一门课程的内容分开。

这样的话，如果我想为第二门课程设计课程，我可以创建它，但仍然需要对通用代码进行更新。不仅如此，另一位作者可以在他们的网站上创建一个新的课程，并为自己使用纳米课程，并从我对该工具的更新中获益。

我一直在想这个设计问题，我没有找到我喜欢的想法。到目前为止，这里有一些半生不熟的想法：

1. 让Git上的纳米课程包含除所有标记、HTML和其他内容文件之外的所有内容。它们恰好都生活在一个名为./content的子目录中。Git上的目录是空的。添加一些Rake任务，以创建包含cosi235a.course文件的单独目录的符号链接。通过这种方式，作者可以对其内容文件进行处理，并在任何时候对毫微课程的任何更新进行git操作。这是一个干净的分离，但很笨重。
2. 使纳米课程成为与纳米一起使用的宝石。换句话说，作者安装了nanoc，对nanoc课程进行了gem安装(或bundler安装)，并在nanoc的库中添加了一两行代码来整合逻辑。这种分离不那么完整，需要作者(不一定是Ruby程序员)修改代码。同时，它对于纳米碳的变化也是脆弱的。

你有什么想法吗？

Answer 1

也有同样的问题。选项1似乎是最明显的，但是它需要作者理解git的复杂之处--我可以很容易地看到这一点。

我倾向于修改2，其中您有一个基于nanoc的定制宝石，但是将它锁定到宝石规范中的特定版本。“课程”只需包含几个基本要素，例如：

/content

/output

Gemfile <==包含您的“纳米课程”创业板。

Gemfile.lock

为课程作者提供一个模板项目，您只需教作者如何使用bundler即可。