【问题标题】:Collaborative Coding and Documentation协作编码和文档
【发布时间】:2010-06-27 21:25:46
【问题描述】:

在一项新的研究工作中,我将参与清理相当广泛的 Java 代码库(7 年以上的开发)的长期工作。它目前驻留在 SVN 上,但我正在考虑 Mercurial。

可能有两种类型的人在项目上进行合作。类型 1:将开发大量代码和编写文档的人。类型 2:是代码的用户,并且对文档和可用性有很好的建议。

我想像这样的工作流程:

  1. 开发人员审查一段代码并(重新)编写文档(代码内 Javadoc/Doxygen 样式)
  2. 开发者提交代码
  3. 版本控制服务器更新 HTML 文档
  4. 类型 2 用户可以查看文档并在文档页面本身上创建 cmets(wiki 样式?)。合作者可以在这里进行讨论。
  5. 开发人员查看 cmets 并转到第 1 步。

我正在寻找有关拟议工作流程的任何建议以及有关有助于完成它的工具的想法。谢谢!

【问题讨论】:

  • 在从 SVN 迁移到 hg 之前,请确保您已经让每个人都参与进来。我在从 CVS 迁移到 SVN 时遇到了麻烦,因为我没有做足够的工作来找出人们喜欢从我们的 CVS 配置中得到什么,以及如何从 SVN 中获得类似的结果。确保每个人都知道您为什么要进行更改,以及如何替换他们的常见任务。

标签: collaboration documentation-generation svn


【解决方案1】:

我强烈建议使用提交邮件列表:通过使每个人都可以轻松地看到更改,因为它们发生了,我们的代码审查明显更好:更早发现错误,在代码仍然在开发人员脑海中新鲜时提出建议,并且每个人都更加了解团队中的其他人在做什么。

【讨论】:

    【解决方案2】:

    我建议你让类型 2(客户?)的人直接成为团队的一部分,这样他们就可以立即帮助开发人员,而不必编写文档。

    这应该会更快,因为它增加了沟通并极大地缩短了反馈循环。

    【讨论】:

    • 我认为这是个好主意。我并不是要给人一种印象,即提出建议的人永远不会直接修改代码/文档。就个人而言,我会考虑做出改变,但只有在讨论之后。换句话说,我(和许多其他人)不想在没有听取其他人意见的情况下做出一些更改。
    猜你喜欢
    • 2016-01-23
    • 1970-01-01
    • 1970-01-01
    • 2010-10-07
    • 2020-09-03
    • 2010-11-03
    • 1970-01-01
    • 2011-09-13
    • 1970-01-01
    相关资源
    最近更新 更多