我在主要是大型机商店的地方管理一个由 .net 开发人员组成的小团队。我的老板正试图将我的团队与其他开发团队更紧密地整合在一起。出现的一个问题是大型机程序员拥有他们所谓的“部件”数据库。这是一个简单的数据库，您可以在其中输入一个软件部件(对象、单元、报告、函数等)，系统会向您发送一个部件号，该部件号将成为可执行文件的文件名。该系统有两个目的；它会给你一个部件号/名称，它内置了智能，可以告诉你它由哪个团队维护，它属于哪个程序子系统，等等。大型机有一个平面 namespace ，所以他们使用这些名称来避免使用一个已经存在的模块名称。其次，你也可以输入一些关于零件的评论。据说这可以用来告诉其他人如何使用有问题的“部分”，如果它依赖于其他外部技术等，但是，当我要求查看有用的示例时，他们无法向我展示任何示例。
由于我们在 .net 中没有平面命名空间，我反对以 AAAA9999 格式命名我团队的对象的提议。在与我的经理讨论这个问题时，他想知道我们如何在“情报”世界中跟踪此类事情。根据我的经验，这些细节要么作为注释保存在代码或帮助文件中，要么作为我们已经必须维护的文档手册/文件等。我怀疑让我的开发人员也在数据库中维护数据的有效性。我的老板说他希望在需要的时候能够问我这样的事情。事实上，他三年一次这样问过我。我告诉他，对于那么大的流量，让我的开发人员维护数据库是不值得的。最好在有查询时咨询团队和/或搜索源代码。
所以我的问题是:记录组织中存在的不同软件实体的内部技术细节的数据库(除了文档手册、在线帮助等)是否有用且实用？有没有人在他们的工作中使用过这样的东西？
最佳答案
命名空间、库、文档.. 在非大型机世界中，简洁命名的命名空间中冗长的或至少是描述性的名称可能会拆分成逻辑库，在使用、性质和开发人员方面几乎是 self 记录的。当然，补充程序和库的实际文档总是一件好事。
我不认为采用零件/编号约定对您有利，但话又说回来，我不了解您业务的所有内部结构。
关于.net - "Software Parts"数据库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1710821/