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

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

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

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

10.11.2009 20:05:46
4 ОТВЕТА
РЕШЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

2
11.11.2009 02:18:04

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

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

4
10.11.2009 20:10:15

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

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

1
10.11.2009 20:18:43

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

1
10.11.2009 22:15:54