协作编码和文档
在一项新的研究工作中,我将参与清理相当广泛的 Java 代码库(7 年多的开发)的长期工作。它目前驻留在 SVN 上,但我正在考虑使用 Mercurial。
可能有两种类型的人在该项目上进行合作。第一类:将开发大量代码和编写文档的人。类型 2:代码的用户,对文档和可用性有很好的建议。
我想象这样的工作流程:
- 开发人员审查一段代码并(重新)编写文档(代码内 Javadoc/Doxygen 样式)
- 开发人员提交代码
- 版本控制服务器更新 HTML 文档
- 类型 2 用户可以审查文档并对文档发表评论页面本身(维基风格?)。合作者可以在这里进行讨论。
- 开发人员查看评论并转到步骤 1。
我正在寻找有关拟议工作流程的任何建议以及有助于完成该工作流程的工具的想法。谢谢!
At a new research job, I will be part of a long-term effort to clean up a pretty extensive Java codebase (7+ years of development). It currently resides on SVN, but I am considering Mercurial.
There are perhaps two types of people collaborating on the project. Type 1: people who will be developing a lot of code and writing documentation. Type 2: people who are users of the code and have very good suggestions about documentation and usability.
I imagine a workflow like so:
- A developer reviews a section of code and (re)writes documentation (in-code Javadoc/Doxygen style)
- Developer commits code
- Versioning server updates HTML documentation
- Type 2 users can review the documentation and make comments on the documentation page itself (wiki style?). Collaborators can have a discussion here.
- Developers look at the comments and go to step 1.
I am looking for any suggestions about the proposed workflow and ideas about tools which will help accomplish it. Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我强烈建议建立一个提交邮件列表:通过让每个人都可以轻松地看到所做的更改,当它们发生时,我们的代码审查明显更好:更早地发现错误,在代码在开发人员的头脑中仍然新鲜的时候提出建议,并且每个人都感觉到更加了解团队中其他人正在做什么。
I strongly suggest a commits mail list: by making the changes easily visible to everyone, as they happened, our code review was significantly better: errors were caught earlier, suggestions were made while the code was still fresh in the developer's mind, and everyone felt more aware of what everyone else in the team was working on.
我建议您让第 2 类(客户?)人员直接成为团队的一部分,这样他们就可以立即帮助开发人员,而不必编写文档。
这应该会使速度更快,因为它增加了沟通并极大地缩短了反馈循环。
I suggest that you make the type 2 (customers?) people part of the team directly so they can help the developers right away, instead of having to write documents.
That should make this much quicker since it increases communication and shortens the feedback loop immensely.