“软件部件”数据库

Question

我管理一个小型的.net开发团队，主要是大型机商店。我的老板正试图将我的团队与其他开发团队更紧密地整合在一起。已经出现的一个问题是大型机程序员拥有他们所谓的“部件”数据库。这是一个简单的数据库，您可以在其中输入软件部分（对象，单元，报告，函数等），系统会向您发送一个部件号，该部件号将成为可执行文件的文件名。该系统有两个目的;它会向你发出一个部件号/名称，它内置了智能，告诉你它所维护的团队以及它所属的程序子系统等。大型机有一个扁平的名称空间，所以他们使用这些名称来避免使用已存在的模块名称。其次，您还可以输入有关该部分的一些评论。据说这可以用来告诉别人如何使用有问题的“部分”，如果它依赖于其他外部技术等等，但是，当我要求查看有用的例子时，他们无法向我展示。

由于我们在.net中没有平面名称空间，因此我反对以AAAA9999格式命名我的团队对象的提议。在与我的经理讨论这个问题时，他想知道我们如何在“英特尔”世界中跟踪这些事情。根据我的经验，这些细节可以作为代码或帮助文件中的注释，或者我们必须维护的doc手册/文件等。我怀疑开发人员在数据库中维护数据的功效。我的老板说他希望能够在他需要的时候问我这些事情。实际上他曾在三年内问过我这样的事情。我告诉他这个流量，让我的开发人员维护一个数据库是不值得的。在查询进入时，最好只与团队协商和/或搜索源代码。

所以我的问题是：数据库是否记录组织中存在的不同软件实体的内部技术细节（除了文档手册，在线帮助等）有用和实用？有没有人在他们的工作中使用过这样的东西？

Answer 1

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

我认为采用部分/编号惯例对您不利，但我再也不知道您所有业务的内部情况。

Answer 2

架构概述对成功至关重要。

在大型机世界中，由于历史原因，事物保持平稳，人们发明了应对的方法，并且XXXyyy命名惯例无处不在。

在大型机领域，技术选择有限。在这一点上，他们基本上是固定的。变化的步伐是冰冷的。因此，列出稳定技术元素列表描述的稳定数据库是有道理的。

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

在非大型机世界中，由于历史原因，事物是等级的，人们会发明应对的方法。

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

最佳做法是提供合理，可用，体系结构的概述，将每个源代码组件放入一些“大图”上下文中。您有义务提供（以书面形式）。如果你赢了彩票并明天离开，你的.Net架构会变成什么样？管理（和你的替代）不想应付。他们想要一些稳定和书面的东西。

数据库，也许不是。

稳定和书面，是的。

在Python世界中，我们使用Sphinx（带.. automodule）从源代码创建文档。

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

您最好的方法是从源创建一个JavaDoc（或类似Sphinx）的主文档。我确信有适合的.Net工具。如果没有，请阅读JavaDoc，使用Very Simple标记语言修饰您的注释块，并从您自己的源代码中剔除您自己的文档。

Answer 3

我无法看到这种方法的价值，因为环境将直接支持这些信息。例如，在C＃中，您可以使用xml注释生成所有源代码的文档，然后以易于搜索的格式生成。您搜索的有关代码的信息在该文档中。

维护一个单独的数据库是不对的。

Answer 4

您是否需要接受审核员检查？如果是这样，那么每次审计员通过时，数据库都会很方便。在这种情况下，“数据库”可以很容易地成为Wiki，每个应用程序都有一个简短的条目。当有人需要维护软件时，这也可以证明是有用的，特别是如果发生错误并且您不确定哪个应用程序导致了问题（希望您有足够好的日志记录，但这不会发生:-)）。 / p>