База данных "Программные части"

Question

Я управляю небольшой командой разработчиков .net, которая в основном является магазином мэйнфреймов. Мой босс пытается более тесно интегрировать мою команду с другими командами разработчиков. Одна проблема, которая возникла, состоит в том, что у программистов мэйнфреймов есть то, что они называют «базой данных». Это простая база данных, в которой вы вводите программную часть (объект, единицу, отчет, функцию и т. Д.), И система выдает вам номер детали, который становится именем файла исполняемого файла. Система имеет две цели; он выдает вам номер детали / имя, в которое встроен интеллект, чтобы сообщить вам, к какой команде он принадлежит и к какой программной подсистеме он принадлежит, и т. д. Мэйнфрейм имеет плоское пространство имен, поэтому они используют эти имена, чтобы избежать использования имя модуля, которое уже существует. Во-вторых, и вы также можете ввести некоторые комментарии о части. Предположительно, это может быть использовано, чтобы рассказать другим, как использовать данную «деталь», если она опирается на другие внешние технологии и т. Д., Хотя, когда я попросил увидеть полезные примеры этого, они не смогли показать мне ничего.

Поскольку у нас нет плоского пространства имен в .net, я сопротивляюсь предложению именовать объекты моей команды в формате AAAA9999. Обсуждая это с моим менеджером, он хотел знать, как мы отслеживаем такие вещи в мире «Intel». По моему опыту, такие подробности хранятся либо в виде комментариев в коде или файлах справки, либо в руководствах / файлах документации и т. Д., Которые мы уже должны поддерживать. Я сомневаюсь в эффективности того, чтобы мои разработчики хранили данные в базе данных. Мой босс говорит, что хочет, чтобы он мог спрашивать меня о таких вещах, когда ему это нужно. На самом деле он спрашивал меня об этом раз в три года. Я сказал ему об этом количестве трафика, потому что мои разработчики поддерживали базу данных, это не стоило того. Было бы лучше просто проконсультироваться с командой и / или поискать исходный код при поступлении запроса.

Итак, мой вопрос: полезна и практична ли база данных, которая документирует внутренние технические детали различных программных сущностей, существующих в организации (в дополнение к руководствам по документации, онлайн-справке и т. Д.)? Кто-нибудь когда-нибудь использовал такую ​​вещь в своей работе?

Answer 1

Пространства имен, библиотеки, документация. В мире без мэйнфреймов подробные или хотя бы описательные имена в кратко именованных пространствах имен, возможно, разделенных на логические библиотеки, почти самодокументированы в том, что касается использования, природы и разработчика. Конечно, актуальная документация, дополняющая программы и библиотеки, - это всегда хорошо.

Я не думаю, что для вас было бы выгодно принять соглашение о детали / номера, но, опять же, я не знаю всех деталей вашего бизнеса.

Answer 2

Архитектурный обзор имеет решающее значение для успеха.

В мире мэйнфреймов, где вещи по историческим причинам остаются неизменными, люди придумывают способы справиться с ситуацией, а XXXyyy-соглашения о присвоении имен повсеместны.

В мире мэйнфреймов выбор технологий ограничен. На данный момент они в основном исправлены. Темпы перемен ледниковые. Таким образом, стабильная база данных для перечисления описаний стабильного списка технологических элементов имеет смысл.

[Кроме того, поскольку почти все является «программой», обсуждать программные компоненты, которые не являются программами, сложно. Хуже того, если у вас есть архитектура, в которой вы можете создавать составные приложения из других приложений, люди из мэйнфреймов очень запутываются. Это нормально для Python и относительно просто для Java.]

В мире без мэйнфреймов, где вещи исторически сложились иерархически, люди изобретают способы справиться с ситуацией.

В мире Windows, где технологические изменения происходят совершенно бессистемно, вам нужен другой механизм преодоления. [В мире открытого кода это еще хуже.]

Лучшей практикой является предоставление разумного, полезного, архитектурного обзора, который помещает каждый компонент исходного кода в некоторый контекст "большой картинки". Вы обязаны предоставить это (в письменном виде). Если вы выиграете в лотерею и уйдете завтра, что станет с вашей .Net-архитектурой? Менеджмент (и ваша замена) не хотят с этим справляться. Они хотят что-то стабильное и написанное.

База данных, возможно нет.

Стабильно и письменно, да.

В мире Python мы используем Sphinx (с .. automodule) для создания документации из источника.

В мире Java мы используем JavaDoc для создания документации из исходного кода.

Ваш лучший подход - создать главный документ JavaDoc (или Sphinx-подобный) из исходного кода. Я уверен, что для этого есть соответствующие инструменты .Net. Если нет, прочитайте JavaDoc, украсьте свои блоки комментариев с помощью языка очень простой разметки и отберите собственную документацию из собственного источника.

Answer 3

Вы подвергаетесь аудиторским проверкам? Если это так, то база данных будет полезна каждый раз, когда проходят аудиторы. В этом случае «база данных» также может быть вики с краткой записью о каждом приложении. Это также может оказаться полезным, когда кому-то новому нужно поддерживать программное обеспечение, особенно если возникает ошибка, и вы не уверены, какое приложение вызвало проблему (надеюсь, у вас достаточно хорошая регистрация, хотя этого не произойдет :-)).

Answer 4

Я не вижу смысла в таком подходе, поскольку среда будет напрямую поддерживать эту информацию. Например, в C # вы можете использовать xml комментарии для создания документации для всего вашего исходного кода, который затем будет в удобном для поиска формате. Информация, которую вы запрашиваете о коде, содержится в этой документации.

Вы правы в том, что ведение отдельной базы данных не добавляет ценности.