Gibt es ein Programmierparadigma, das Abhängigkeiten für andere Programmierer extrem offensichtlich macht?

Ich arbeite in einem Data Warehouse, das über viele Streams und Layer mit labyrinthartigen Abhängigkeiten, die verschiedene Artefakte verbinden, mehrere Systeme beschafft. Ziemlich jeden Tag stoße ich auf Situationen wie diese: Ich führe etwas aus, es funktioniert nicht, ich gehe eine Menge Code durch, aber Stunden später merke ich, dass ich es geschafft habe, die Prozesslandkarte eines winzigen Teils dessen, was ich jetzt weiß, zu konzipieren Da dies später am Tag erforderlich ist, frage ich jemanden und er teilt mir mit, dass dieser andere Stream zuerst ausgeführt werden muss. Wenn ich dies hier überprüfe (was auf einen scheinbar willkürlichen Teil eines enormen Stapels anderer codierter Abhängigkeiten hinweist), hätte ich dies getan das gesehen. Es ist unglaublich frustrierend.

Wenn ich dem Team vorschlagen könnte, dass es vielleicht eine gute Idee wäre, mehr zu tun, um die Abhängigkeiten zwischen Objekten sichtbarer und offensichtlicher zu machen, anstatt sie tief in rekursive Codeebenen oder sogar in die Daten, die diese enthalten, einzubetten muss vorhanden sein, weil es von einem anderen Stream bevölkert wird, vielleicht unter Bezugnahme auf ein bekanntes, erprobtes Software-Paradigma - dann kann ich möglicherweise meine Arbeit vereinfachen und alle anderen sind viel einfacher.

Es ist ziemlich schwierig, meinem Team die Vorteile davon zu erklären. Sie neigen dazu, Dinge einfach so zu akzeptieren, wie sie sind, und „denken nicht groß“, um die Vorteile einer neuen Konzeptualisierung des gesamten Systems zu erkennen - sie sehen das nicht wirklich, wenn Sie ein riesiges System modellieren können Effizient dann macht es es weniger wahrscheinlich, dass Sie auf Speichereffizienzen stoßen, eindeutige Einschränkungen und doppelte Schlüssel stoppen, Daten unsinnig machen, weil es viel einfacher ist, sie in Übereinstimmung mit der ursprünglichen Vision zu entwerfen, und Sie werden später nicht auf all diese Probleme stoßen, die Wir erleben jetzt, was ich aus früheren Berufen als ungewöhnlich kenne, was sie aber für unvermeidlich halten.

Kennt jemand ein Software-Paradigma, das Abhängigkeiten betont und ein gemeinsames konzeptionelles Modell eines Systems fördert, um die langfristige Einhaltung eines Ideals sicherzustellen? Im Moment haben wir so ziemlich ein riesiges Durcheinander und die Lösung für jeden Sprint scheint zu lauten: "Fügen Sie einfach hier und hier und hier etwas hinzu."

Auffindbarkeit

Seine Abwesenheit plagt viele Organisationen. Wo ist das Werkzeug, das Fred wieder gebaut hat? Sicher im Git-Repository. Woher?

Das Software-Muster, an das ich denke, ist Model-View-ViewModel. Für die Uneingeweihten ist dieses Muster ein Rätsel. Ich erklärte es meiner Frau als "fünf Widgets, die über dem Tisch schwebten und über eine mysteriöse Kraft miteinander sprachen". Verstehen Sie das Muster und Sie verstehen die Software.

Viele Softwaresysteme können ihre Architektur nicht dokumentieren, weil sie davon ausgehen, dass sie selbsterklärend ist oder sich auf natürliche Weise aus dem Code ergibt. Ist es nicht und tut es nicht. Wenn Sie keine genau definierte Architektur verwenden, gehen neue Leute verloren. Wenn es nicht dokumentiert ist (oder nicht bekannt ist), gehen neue Leute verloren. Und Veteranen werden auch verloren gehen, wenn sie ein paar Monate nicht mehr mit dem Code zu tun haben.

Es liegt in der Verantwortung des Teams, eine vernünftige Organisationsarchitektur zu entwickeln und diese zu dokumentieren. Dazu gehören Dinge wie

• Ordnerorganisation
• Projektreferenzen
• Klassendokumentation (was es ist, was es tut, warum es existiert, wie es benutzt wird)
• Projekt, Modul, Montage, welche Dokumentation auch immer.

Es liegt in der Verantwortung des Teams, die Dinge so zu organisieren und erkennbar zu machen, dass das Team das Rad nicht ständig neu erfindet.

Übrigens ist der Begriff "Code sollte sich selbst dokumentieren" nur teilweise richtig. Zwar sollte Ihr Code klar genug sein, damit Sie nicht jede Codezeile mit einem Kommentar erläutern müssen, die Beziehungen zwischen Artefakten wie Klassen, Projekten, Assemblys, Schnittstellen und dergleichen sind jedoch nicht offensichtlich müssen dokumentiert werden.

Der beste Weg, um diese Art von Problemen anzugehen, ist inkrementell. Seien Sie nicht frustriert und schlagen Sie umfassende architektonische Änderungen vor. Diese werden niemals genehmigt und der Code wird sich niemals verbessern. Vorausgesetzt, Sie können sogar die korrekten umfassenden architektonischen Änderungen bestimmen, die unwahrscheinlich sind.

Was ist wahrscheinlich, dass Sie eine kleinere Veränderung feststellen konnte , die Sie mit dem spezifischen Problem geholfen haben , würden Sie nur gelöst. Vielleicht einige Abhängigkeiten umkehren, Dokumentation hinzufügen, eine Schnittstelle erstellen, ein Skript schreiben, das vor einer fehlenden Abhängigkeit warnt, usw. Schlagen Sie stattdessen diese kleinere Änderung vor. Je nach Unternehmenskultur kann es sogar sein, dass sie solche Verbesserungen als Teil Ihrer ursprünglichen Aufgabe tolerieren oder sogar von Ihnen erwarten.

Wenn Sie diese kleineren Änderungen zu einem regelmäßigen Bestandteil Ihrer Arbeit machen und durch Ihr Beispiel andere dazu ermutigen, summieren sich diese im Laufe der Zeit. Viel effektiver als über einzelne größere Änderungen zu jammern, die Sie nicht vornehmen dürfen.

Die Architektur.

Es gibt kein einzelnes, spezifisches, universelles Prinzip oder Verfahren, das die Probleme der Auffindbarkeit und Wartbarkeit löst, die für alle Aspekte der gesamten Software gelten. Aber der allgemeine Begriff für das, was ein Projekt vernünftig macht, ist Architektur.

Ihre Architektur ist die Gesamtheit aller Entscheidungen in Bezug auf jeden Punkt potenzieller (oder historischer) Verwirrung - einschließlich der Festlegung, wie Architekturentscheidungen getroffen und dokumentiert werden. Alles, was sich auf den Entwicklungsprozess, die Ordnerstruktur, die Codequalität, Entwurfsmuster usw. bezieht, kann in Ihre Architektur einfließen, aber keine davon ist eine Architektur.

Im Idealfall werden diese Regeln durch eine Singularität des Geistes vereinheitlicht .

Ein kleines Team kann sicherlich gemeinsam Architektur schaffen. Bei unterschiedlichen Meinungen kann dies jedoch schnell zu einer sehr schizophrenen Architektur führen, die nicht dazu dient, Ihre geistige Gesundheit zu erhalten. Der einfachste Weg, um sicherzustellen, dass Ihre Architektur und die vielen TLAs und Muster darin dem Erfolg des Teams mit einer Singularität des Geistes dienen, besteht darin , einen einzelnen Geist für sie verantwortlich zu machen.

Nun, das erfordert nicht unbedingt einen "Architekten" zum Pontifikieren . Und während einige Teams vielleicht möchten, dass eine erfahrene Person nur diese Entscheidungen trifft, ist der wichtigste Punkt, dass jemand die Architektur besitzen muss, insbesondere wenn das Team wächst. Jemand hat den Finger am Puls des Teams, moderiert Architekturdiskussionen, dokumentiert Entscheidungen und überwacht Entscheidungen und arbeitet weiter an der Einhaltung der Architektur und ihres Ethos.

Ich bin kein großer Fan von jemandem, der alle Entscheidungen trifft. Die Identifizierung eines "Architekten" oder "technischen Produktbesitzers", der für die Moderation von Architekturdiskussionen und die Dokumentation von Entscheidungen verantwortlich ist, bekämpft jedoch ein größeres Übel: Die Diffusion von Verantwortung, die zu keiner erkennbaren Architektur führt.

Willkommen bei Software Engineering (in beiden Richtungen);) Dies ist eine gute Frage, aber es gibt wirklich keine einfachen Antworten, wie Sie sicher wissen. Es geht wirklich darum, sich im Laufe der Zeit zu besseren Praktiken zu entwickeln und die Menschen darin zu schulen, geschickter zu sein (per Definition sind die meisten Leute in der Branche mittelmäßig kompetent) ...

Die Softwareentwicklung als Disziplin leidet darunter, dass sie zuerst erstellt und nach dem Mentalitätsprinzip entwickelt wird, zum Teil aus Gründen der Zweckmäßigkeit und zum Teil aus Gründen der Notwendigkeit. Es ist nur die Natur des Tieres. Und natürlich bauen Hacks im Laufe der Zeit auf Hacks auf, da die oben genannten Codierer schnell funktionierende Lösungen implementieren, die den kurzfristigen Bedarf häufig auf Kosten der Einführung technischer Schulden lösen.

Das Paradigma, das Sie verwenden müssen, besteht im Wesentlichen darin, bessere Leute zu finden, die Leute zu schulen, die Sie gut haben, und zu betonen, wie wichtig es ist, sich Zeit für Planung und Architektur zu nehmen. Man kann nicht einfach so "agil" sein, wenn man mit einem monolithischen System arbeitet. Es kann eine beträchtliche Planung erfordern, auch kleine Änderungen vorzunehmen. Wenn Sie einen hervorragenden Dokumentationsprozess auf hoher Ebene einrichten, können Sie auch wichtige Personen dabei unterstützen, den Code schneller in den Griff zu bekommen.

Die Ideen, auf die Sie sich konzentrieren könnten, wären (im Laufe der Zeit, schrittweise) das Isolieren und Umgestalten wichtiger Teile des Systems auf eine Weise, die sie modularer und entkoppelter, lesbarer und wartbarer macht. Der Trick besteht darin, dies auf die bestehenden Geschäftsanforderungen abzustimmen, sodass die Reduzierung der technischen Schulden gleichzeitig mit der Erzielung eines sichtbaren Geschäftswertes erfolgen kann. Die Lösung besteht zum einen darin, Praktiken und Fähigkeiten zu verbessern und zum anderen, wie ich Ihnen bereits sagen kann, mehr auf ein langfristiges architektonisches Denken hinzuarbeiten.

Beachten Sie, dass ich diese Frage aus der Perspektive der Softwareentwicklungsmethodik und nicht aus der Perspektive der Codiertechnik beantwortet habe, da dies in Wirklichkeit ein Problem ist, das viel größer ist als die Details der Codierung oder sogar des Architekturstils. Es ist wirklich eine Frage, wie Sie Veränderungen planen.

Ich mag @ RobertHarveys Vorstellung von Konventionen und denke, sie helfen. Ich mag auch die Idee von @ KarlBielefeldt, "Document as you go" zu machen und zu wissen, dass dies wichtig ist, weil nur so die Dokumentation auf dem neuesten Stand bleibt. Aber ich denke, die übergreifende Idee ist, dass es wichtig ist, zu dokumentieren, wie Sie alle Teile Ihres Codes finden, erstellen und bereitstellen können!

Ich habe kürzlich ein bedeutendes Open Source-Projekt per E-Mail verschickt, das eine XML-Konfiguration hatte, bei der der generierte Code vollständig undokumentiert war. Ich fragte den Betreuer: "Wo ist dieser XML-Codegenerierungsprozess dokumentiert? Wo ist das Setup der Testdatenbank dokumentiert?" und er sagte: "Es ist nicht." Es handelt sich im Grunde genommen um ein Einzelprojekt, und jetzt weiß ich, warum.

Schauen Sie, wenn Sie diese Person sind und dies lesen, weiß ich wirklich zu schätzen, was Sie tun. Ich verehre praktisch die Früchte Ihrer Arbeit! Aber wenn Sie eine Stunde damit verbracht haben, zu dokumentieren, wie Ihre wirklich kreativen Dinge zusammengesetzt sind, könnte ich ein paar Tage damit verbringen, neue Funktionen zu programmieren, die Ihnen helfen könnten. Wenn ich mit der Ziegelmauer konfrontiert werde, dass "Mangel an Dokumentation kein Problem ist", werde ich es nicht einmal versuchen.

In einem Unternehmen ist ein Mangel an Dokumentation eine enorme Zeit- und Energieverschwendung. Projekte wie dieses werden oft an Berater vergeben, die noch mehr kosten, nur damit sie grundlegende Dinge herausfinden können wie "Wo sind alle Teile und wie passen sie zusammen?".

Abschließend

Was benötigt wird, ist nicht so sehr eine Technologie oder Methodik, sondern ein Kulturwandel. eine gemeinsame Überzeugung, dass es wichtig ist, zu dokumentieren, wie Dinge gebaut werden und warum. Es sollte Teil der Codeüberprüfung sein, eine Voraussetzung für die Umstellung auf die Produktion, die an Erhöhungen gebunden ist. Wenn jeder das glaubt und danach handelt, werden sich die Dinge ändern. Ansonsten wird es so sein, als wäre mein Open-Source-Beitrag gescheitert.

Um die Frage so zu beantworten, wie sie gestellt wird (anstatt Ihnen Ratschläge für Ihre spezielle Situation zu geben):

Das als reine Funktionsprogrammierung bekannte Programmierparadigma erfordert, dass in Eingabeparametern alles angegeben wird, was die Ausgabe einer Funktion beeinflusst. Es gibt keine versteckten Abhängigkeiten oder globalen Variablen oder andere mysteriöse Kräfte, die unsichtbar in der Codebasis wirken. Es gibt keine zeitliche Kopplung "Sie müssen dies zuerst tun".

Jedes Data Warehouse ist anders, aber Sie können eine Menge tun, um sich die Arbeit zu erleichtern.

Für den Anfang hatte jede Zeile in der Datenbank ein DATE_ADDED und ein DATA_UPDATED Spalte, sodass wir sehen konnten, wann sie der Datenbank hinzugefügt und wann sie geändert wurde. Wir hatten auch eine SOURCE_CODE- Spalte, damit wir verfolgen konnten, wo jedes Datenbit in das System einging.

Als Nächstes hatten wir gemeinsame Tools, die in allen unseren Data Warehouses zum Einsatz kamen, z. B. Sortierungen, Tabellenübereinstimmungen, Slicer und Dicer usw.

Der maßgeschneiderte Code wurde auf ein absolutes Minimum beschränkt und musste selbst dann verschiedene Codierungs- und Berichtsstile bestätigen.

Ich gehe davon aus, dass Sie mit ETL bereits vertraut sind Suiten . Es gibt eine Menge Funktionen, die du heutzutage kostenlos bekommst und die ich vor ungefähr einem Jahrzehnt noch nicht im Spiel hatte.

Vielleicht möchten Sie sich auch Data Marts ansehen, um eine benutzerfreundlichere , bereinigte Version Ihres Data Warehouse zu präsentieren. Das ist natürlich keine Silberkugel, könnte aber bei bestimmten Problemen helfen, anstatt Ihr Data Warehouse neu aufzubauen / zu korrigieren.

Ich weiß nicht, wie wichtig es für Ihren Fall ist, es gibt einige Strategien, um Abhängigkeiten sichtbarer zu machen und die allgemeine Pflege von Code-

• Vermeiden Sie globale Variablen, verwenden Sie stattdessen Parameter. Dies gilt auch für sprachübergreifende Anrufe.
• Vermeiden Sie es, die Werte der Variablen so oft wie möglich zu ändern oder zu verändern. Erstellen Sie eine neue Variable und verwenden Sie, wenn möglich, wenn Sie den Wert ändern müssen.
• Machen Sie den Code modular. Wenn es nicht möglich ist, in einem einfachen Satz zu beschreiben, was (nicht wie) der Teil tatsächlich tut, teilen Sie ihn in Module auf, die die Bedingung erfüllen.
• Nennen Sie Ihre Code-Teile richtig. Wenn Sie in einfachen Worten beschreiben können, was ein Teil des Codes tut, werden diese Begriffe zum Namen des Teils. Auf diese Weise wird der Code durch die Namen der Module / Klassen / Funktionen / Prozeduren / Methoden usw. selbstdokumentierend.
• Testen Sie Ihren Code. Testen Sie, ob die Entitäten in Ihrem Code ihre Namen rechtfertigen (siehe oben).
• Ereignisse im Code protokollieren. Mindestens zwei Protokollebenen beibehalten. Erstens ist immer einer aktiviert (auch in der Produktion) und protokolliert nur kritische Ereignisse. Und mit dem anderen kann im Grunde alles protokolliert, aber ein- oder ausgeschaltet werden.
• Finden und verwenden Sie geeignete Tools zum Durchsuchen, Verwalten und Entwickeln Ihrer Codebasis. Sogar eine einfache Option "Alles durchsuchen" von Visual Studio Code hat mir das Leben in bestimmten Fällen erheblich erleichtert.