documentation - 处理大量业务逻辑规则时的项目文档。如何组织它？

Question

就业务逻辑数量和组件数量而言，我正在从事相当复杂的项目。

每个开发人员主要在“他自己的”组件上工作。我知道这不是很跨功能，但不可能知道每个组件的详细信息。

团队 sostav 不时更改。因此，我们会遇到一个人必须处理“其他人的组件”的情况。这可以在定期地下室，所以你可以在一个月后回到这个问题 - 在那个时候你可以一次又一次地向组件业务逻辑的所有者询问相同的问题，因为你可能会忘记一个月内一些微小但重要的细节之后。

这种情况有时很烦人。

我们每天都有站立会议，当人们讲述他已经做了什么和打算做什么时。我们有项目的wiki FAQ页面——我们提取了最常见的问题。

你怎么看这个问题？

你会建议我们如何解决它？

Answer 1

鉴于我要使用的组件性质：

1.) 指定应用程序目的、设置、要求等的框架文档。 2.) 每个组件的模块文档采用通用格式并按名称索引。

查看http://docs.python.org以获得一般文档的好示例，查看http://docs.python.org/modindex.html以获得模块/组件文档的好示例

哦，日常会议通常很糟糕，它们会占用大量时间并且会忘记答案。新人或生病的人错过了会议，必须重新听取简报。除非需要讨论/反馈，否则将所有内容写下来并保留纸质/电子邮件记录会好 100 倍。