Datenbank "Softwareteile"

Question

Ich leite ein kleines Team von .net-Entwicklern in einem Unternehmen, das hauptsächlich aus Mainframes besteht. Mein Chef versucht, mein Team enger mit den anderen Entwicklungsteams zu integrieren. Ein Problem, das aufgetaucht ist, ist, dass die Mainframe-Programmierer eine so genannte "Teile"-Datenbank haben. Dabei handelt es sich um eine einfache Datenbank, in die man einen Softwareteil (Objekt, Einheit, Bericht, Funktion usw.) eingibt, und das System vergibt eine Teilenummer, die zum Dateinamen der ausführbaren Datei wird. Das System dient zwei Zwecken: Es gibt eine Teilenummer/einen Namen aus, die bzw. der intelligent genug ist, um festzustellen, von welchem Team sie verwaltet wird, zu welchem Programmteilsystem sie gehört usw. Der Mainframe hat einen flachen Namensraum, so dass diese Namen verwendet werden, um zu vermeiden, dass ein Modulname verwendet wird, der bereits existiert. Zweitens können Sie auch einige Kommentare zu dem Teil eingeben. Angeblich kann man damit anderen mitteilen, wie das betreffende "Teil" zu verwenden ist, ob es auf andere externe Technologien angewiesen ist usw., aber als ich nach nützlichen Beispielen dafür fragte, konnte man mir keine zeigen.

Da wir in .net keinen flachen Namensraum haben, wehre ich mich gegen den Vorschlag, die Objekte meines Teams in einem Format von AAAA9999 zu benennen. Als ich dies mit meinem Manager besprach, wollte er wissen, wie wir solche Dinge in der "intel"-Welt verfolgen. Meiner Erfahrung nach werden solche Details entweder als Kommentare im Code oder in Hilfedateien oder in Handbüchern/Dateien usw. festgehalten, die wir ohnehin pflegen müssen. Ich bin skeptisch, ob es sinnvoll ist, dass meine Entwickler die Daten auch in einer Datenbank pflegen. Mein Chef sagt, er wolle mich bei Bedarf um solche Dinge bitten können. Tatsächlich hat er mich in den letzten drei Jahren nur einmal um so etwas gebeten. Ich habe ihm gesagt, dass es sich bei dieser Menge an Datenverkehr nicht lohnt, meine Entwickler eine Datenbank pflegen zu lassen. Es wäre besser, sich einfach mit dem Team zu beraten und/oder den Quellcode zu durchsuchen, wenn die Anfrage kommt.

Meine Frage ist also: Ist eine Datenbank, die die internen technischen Details der verschiedenen Software-Entitäten, die in einer Organisation existieren, dokumentiert (zusätzlich zu Dokumentationshandbüchern, Online-Hilfe usw.), nützlich und praktisch? Hat jemand so etwas schon einmal bei seiner Arbeit verwendet?

Answer 1

Namensräume, Bibliotheken, Dokumentation In einer Nicht-Mainframe-Welt sind ausführliche oder zumindest beschreibende Namen in prägnant benannten Namespaces, die möglicherweise in logische Bibliotheken aufgeteilt sind, fast selbstdokumentierend in Bezug auf Verwendung, Art und Entwickler. Natürlich ist eine aktuelle Dokumentation, die die Programme und Bibliotheken ergänzt, immer eine gute Sache.

Ich glaube nicht, dass es für Sie vorteilhaft wäre, die Konvention für Teile/Nummern zu übernehmen, aber ich kenne ja auch nicht alle Interna Ihres Unternehmens.

Answer 2

Ein Überblick über die Architektur ist entscheidend für den Erfolg.

In der Mainframe-Welt, in der die Dinge aus historischen Gründen flach gehalten werden, erfinden die Leute Wege, um damit umzugehen, und die XXXyyy-Namenskonventionen sind allgegenwärtig.

In der Mainframe-Welt ist die Auswahl an Technologien begrenzt. Im Moment sind sie weitgehend festgelegt. Das Tempo des Wandels ist eisig. Daher ist eine stabile Datenbank, in der die Beschreibungen einer stabilen Liste von Technologieelementen aufgeführt sind, sinnvoll.

[Da außerdem fast alles ein "Programm" ist, ist es schwierig, über Softwarekomponenten zu diskutieren, die keine Programme sind. Schlimmer noch, wenn Sie eine Architektur haben, bei der Sie eine zusammengesetzte Anwendung aus anderen Anwendungen erstellen können, werden die Mainframe-Leute sehr verwirrt. Das ist bei Python normal und bei Java relativ einfach].

In der Welt der Nicht-Mainframes, in der die Dinge aus historischen Gründen hierarchisch sind, erfinden die Leute Wege, damit umzugehen.

In der Windows-Welt, in der technologische Veränderungen eher zufällig erfolgen, brauchen Sie einen anderen Bewältigungsmechanismus. [In der Open-Source-Welt ist es noch schlimmer.]

Die beste Praxis ist es, einen vernünftigen, brauchbaren Überblick über die Architektur zu geben, der jede Quellcodekomponente in einen "Gesamtkontext" stellt. Sie sind verpflichtet, dies (schriftlich) zu tun. Wenn Sie im Lotto gewinnen und morgen weggehen, was wird dann aus Ihrer .Net-Architektur? Die Geschäftsleitung (und Ihr Nachfolger) wollen sich damit nicht abfinden. Sie wollen etwas Stabiles und Schriftliches.

Datenbank, vielleicht auch nicht.

Stabil und schriftlich, ja.

In der Python-Welt verwenden wir Sphinx (mit .. automodule ), um Dokumentation aus der Quelle zu erstellen.

In der Java-Welt verwenden wir JavaDoc, um Dokumentation aus dem Quellcode zu erstellen.

Am besten erstellen Sie ein JavaDoc- (oder Sphinx-ähnliches) Masterdokument aus der Quelle. Ich bin sicher, dass es dafür entsprechende .Net-Tools gibt. Wenn nicht, lesen Sie sich in JavaDoc ein, schmücken Sie Ihre Kommentarblöcke mit einer sehr einfachen Auszeichnungssprache und erstellen Sie Ihre eigene Dokumentation aus Ihrem eigenen Quellcode.

Answer 3

Ich kann den Wert eines solchen Ansatzes nicht erkennen, da die Umwelt diese Informationen direkt unterstützen wird. In C# können Sie beispielsweise xml-Kommentare verwenden, um eine Dokumentation für Ihren gesamten Quellcode zu erstellen, die dann in einem leicht zu durchsuchenden Format vorliegt. Die Informationen, die Sie über den Code suchen, befinden sich in dieser Dokumentation.

Sie haben Recht, dass die Unterhaltung einer separaten Datenbank keinen Mehrwert bringt.

Answer 4

Werden Sie von Wirtschaftsprüfern kontrolliert? Wenn ja, dann wäre die Datenbank jedes Mal praktisch, wenn Prüfer vorbeikommen. In diesem Fall kann die "Datenbank" genauso gut ein Wiki mit einem kurzen Eintrag zu jeder Anwendung sein. Das kann sich auch als hilfreich erweisen, wenn jemand Neues die Software warten muss, insbesondere wenn ein Fehler auftritt und Sie nicht sicher sind, welche Anwendung das Problem verursacht hat (hoffentlich haben Sie eine ausreichend gute Protokollierung, damit das nicht passiert :-) ).