“软件部件”数据库

命名空间、库、文档。在非大型机世界中,简洁命名的命名空间中的冗长或至少是描述性的名称——可能被拆分为逻辑库——在使用、性质和开发人员方面几乎都是自文档化的。当然,实际的文件补充了程序和;图书馆总是一件好事。

我认为采用零件/编号惯例对你没有好处,但话说回来,我并不了解你业务的所有内部。

在大型机世界中,由于历史原因,事情保持不变,人们发明了应对的方法,XXXyyy命名约定无处不在。

在大型机领域,技术选择是有限的。在这一点上,它们基本上是固定的。变化的速度非常缓慢。因此,一个稳定的数据库来列出技术元素的稳定列表的描述是有意义的。

[此外,由于几乎所有东西都是“程序”,讨论非程序的软件组件很难。更糟糕的是,如果你有一个架构,可以从其他应用程序构建复合应用程序,大型机人员会非常困惑。这对Python来说很正常,对Java来说相对容易。]

在Windows世界中,技术变化以相当随意的方式发生,你需要一种不同的应对机制。[在开源世界,情况甚至更糟。]

最佳实践是提供一个合理、可用的架构概述,将每个源代码组件放入一些“大局”上下文中。您有义务(以书面形式)提供此信息。如果你中了彩票,明天就走了,你会变成什么样子。网络架构?管理层(以及你的继任者)不想应对这种情况。他们想要一些稳定和书面的东西。

在Python世界中,我们使用Sphinx( .. automodule

在Java世界中,我们使用JavaDoc从源代码创建文档。

我看不出这种方法的价值,因为环境会直接支持这些信息。例如,在C#中,您可以使用xml注释为所有源代码生成文档,这些文档将以易于搜索的格式呈现。您所寻求的有关代码的信息在该文档中。

你说得对,维护一个单独的数据库并不会增加价值。

您是否受到审计员的检查?如果是这样,那么每次审计员来时,数据库都会很方便。在这种情况下,“数据库”可以很容易地成为一个维基,每个应用程序上都有一个简短的条目。当新用户需要维护软件时,这也很有帮助,特别是当出现错误并且您不确定是哪个应用程序导致了问题时(希望您有足够好的日志记录,这样就不会发生这种情况:-)。