it-swarm.com.de

Ratschläge zum Entwerfen von Webanwendungen mit einer Lebensdauer von mehr als 40 Jahren

Szenario

Derzeit bin ich Teil eines Gesundheitsprojekts, dessen Hauptanforderung darin besteht, Daten mit unbekannten Attributen mithilfe von benutzergenerierten Formularen von Gesundheitsdienstleistern zu erfassen. Die zweite Anforderung ist, dass die Datenintegrität der Schlüssel ist und dass die Anwendung über 40 Jahre lang verwendet wird. Derzeit migrieren wir die Kundendaten der letzten 40 Jahre aus verschiedenen Quellen (Papier, Excel, Access usw.) in die Datenbank. Zukünftige Anforderungen sind:

  • Workflow-Management von Formularen
  • Planen Sie die Verwaltung von Formularen
  • Sicherheits-/rollenbasiertes Management
  • Berichts-Engine
  • Mobile/Tablet-Unterstützung

Situation

Nur 6 Monate später hat der derzeitige (vertraglich vereinbarte) Architekt/leitende Programmierer den "schnellen" Ansatz gewählt und ein schlechtes System entworfen. Die Datenbank ist nicht normalisiert, der Code ist gekoppelt, die Ebenen haben keinen bestimmten Zweck und Daten gehen verloren, da er einige Beans entworfen hat, um "Löschvorgänge" für die Datenbank durchzuführen. Die Codebasis ist extrem aufgebläht und es gibt Jobs nur zum Synchronisieren von Daten, da die Datenbank nicht normalisiert ist. Sein Ansatz bestand darin, sich auf Sicherungsjobs zu verlassen, um fehlende Daten wiederherzustellen, und scheint nicht an ein Re-Factoring zu glauben.

Nachdem der Architekt dem Premierminister meine Ergebnisse vorgelegt hat, wird er entfernt, wenn sein Vertrag endet. Ich habe die Aufgabe erhalten, diese Anwendung neu zu gestalten. Mein Team besteht aus mir und einem Junior-Programmierer. Wir haben keine anderen Ressourcen. Wir haben ein 6-monatiges Einfrieren der Anforderungen erhalten, in dem wir uns auf den Wiederaufbau dieses Systems konzentrieren können.

Ich schlug vor, ein CMS-System wie Drupal zu verwenden, aber aus politischen Gründen in der Organisation des Kunden muss das System von Grund auf neu erstellt werden.

Dies ist das erste Mal, dass ich ein System mit einer Lebensdauer von über 40 entwerfe. Ich habe nur an Projekten mit einer Lebensdauer von 3-5 Jahren gearbeitet, daher ist diese Situation sehr neu und dennoch aufregend.

Fragen

  • Welche Designüberlegungen machen das System "zukunftssicherer"?
  • Welche Fragen sollten an den Kunden/PM gestellt werden, um das System "zukunftssicherer" zu machen?
73
Pete

Daten sind König

Ich halte es für etwas unvernünftig, zu erwarten, dass eine Webanwendung um 2013 noch verfügbar und funktionsfähig sein wird. Die Technologien werden sich ändern. Plattformen werden kommen und gehen. HTML kann bis dahin eine kuriose Erinnerung sein. Ihre Daten bleiben jedoch erhalten.

Daten stehen also im Vordergrund. Solange Ihre Daten noch vorhanden sind, können sich die Benutzer an die neuen Technologien anpassen. Stellen Sie sicher, dass Ihre Datenschemata gut durchdacht und für die Erweiterung gut geeignet sind. Nehmen Sie sich Zeit, um sie zu spezifizieren.

In Bezug auf die tatsächlichen Anwendungen hat Ihr Unternehmen hier wahrscheinlich Recht, wenn es eine Direktive von Grund auf neu erstellt. Ich verwalte ein paar über 10 Jahre alte Web-Apps und bin sehr froh, dass sie nicht an die vorherrschenden CMS-Systeme von 2003 gebunden sind. Sie verwenden selbst entwickelte, sehr einfache Frameworks. Ich denke, für so etwas sind Sie mit einem sehr grundlegenden Rahmen besser dran, den Sie speziell für die Bedürfnisse des Projekts erstellen.

In Wirklichkeit wird das Unternehmen in über 40 Jahren (hoffentlich) einige Front-End- und Back-End-Services bereitstellen, um sich an sich weiterentwickelnde Plattformen anzupassen. Angesichts dessen würde ich eine Lebensdauer von 5 bis 10 Jahren für einzelne Anwendungen mit Benutzerkontakt anstreben.

132
GrandmasterB

Wir produzieren Software, die seit über 20 Jahren von zahlenden Kunden verwendet wird. Die Codebasis hat mehrere Generationen von Versionsverwaltungswerkzeugen überdauert. Unsere Software trifft alle Ihre Stichpunkte mit Ausnahme des Tablets.

Einige der Bedenken umfassen ESIGN und UETA . Unsere Anwälte glauben, dass wir elektronische Aufzeichnungen mindestens 10 Jahre lang lesbar halten müssen. Für Dokumente, die als Ganzes beibehalten werden, sollten Sie sich PDF/A ansehen.

Sorgen Sie sich für Ihre Datenbank nicht zu sehr um die Normalisierung. Stattdessen sollten Sie sich Gedanken darüber machen, alles zu protokollieren und Audittabellen zu haben, die Änderungen/Löschungen in Daten verfolgen. Planen Sie beim Aktualisieren von Versionen genügend Zeit, um neue Versionen parallel zu testen, um sicherzustellen, dass Ihre Daten migriert wurden. Dieses Testen neuer Versionen umfasst auch neue Betriebssysteme - wir hatten im Laufe der Jahre einige sehr unangenehme Überraschungen. Bewahren Sie Installationsmedien und Lizenzschlüssel für den Fall auf, dass ein Rollback durchgeführt werden muss. Testen Sie Backups. Wenn Sie Objekte serialisieren möchten, die in der Datenbank gespeichert werden sollen, tun Sie dies als XML anstelle der von Ihrem Entwicklungsframework bereitgestellten Serialisierung.

Für Ihre Personalausstattung benötigen langfristige Codebasen ein Langzeitgedächtnis. Idealerweise möchten Sie Leute, die schon lange da sind. Wenn das institutionell unmöglich ist, müssen Sie alles in so etwas wie einem Wiki dokumentieren. Und mein Rat ist ein Wiki, das sich in Ihr Bug-Tracking-System einfügt.

Stellen Sie für Ihre Codebasis sicher, dass Ihr Code Kommentare enthält. Bei der Migration von einem Versionskontrollsystem zu einem anderen gehen fast immer Ihre Check-in-Kommentare verloren. Ich bin ein Fan von Benennungs-Unit-Tests nach Spezifikations- und Fehlernummern. Auf diese Weise wissen Sie, was und wo Sie herausfinden müssen, was getestet werden soll, wenn der Komponententest Test_Bug_1235 Abbricht. Es ist nicht so "sexy" wie das Benennen Ihrer Tests Check_File_Save_Networked_Drives, Aber diese Art von Test ist im Gegensatz zu Test_requirement_54321_case_2 Schwer auf Spezifikationen, Anforderungen oder Fehler zurückzuführen.

40
Tangurena

Anstatt herauszufinden, wie diese Anwendung in 20 Jahren noch in Betrieb sein wird, sollten Sie Ihre sechs Monate damit verbringen, die Probleme zu beheben, die der ursprüngliche Architekt verursacht hat, eine vernünftige, robuste Architektur einzurichten und von dort vorwärts gehen.

Eine teilweise De-Normalisierung einer Datenbank ist in einer medizinischen Umgebung nicht unbedingt völlig unerwartet. Einige Teile medizinischer Datenbanken weisen Merkmale auf, die sie für das Modell EAV (Entität/Attribut/Wert) gut geeignet machen.

29
Robert Harvey

Antwort aus Front-End-Perspektive :

Hören Sie nicht allen zu, die sagen, dass dies nicht möglich ist, da ein experimenteller Webdienst der San Francisco State University, den ich 1996 mitgeschrieben habe, vor ein paar Jahren endlich in den Internet-Himmel kam und in dieser Zeit keine einzige Korrektur der Browserkompatibilität benötigte ;; Das ist fast die Hälfte Ihres 40-Jahres-Ziels. Und dieses JavaScript-basierte Front-End , das ich 1998 für ein Projekt des Stanford Research Institute erstellt habe, wurde einige Jahre später durch etwas Auffälligeres ersetzt, aber es gibt keinen Grund, warum die ursprüngliche Benutzeroberfläche heute noch nicht ausgeführt werden kann kleinere Kompatibilitätskorrekturen.

Der Trick besteht darin, sicherzustellen, dass Ihre App nur weit verbreitete W3C/ECMA-Standards verwendet und ein sauberes Design unter Ihrer Kontrolle hat. Während viele Web-Apps, die mit der trendigen Technologie der 90er Jahre geschrieben wurden, heute nicht oder überhaupt nicht gut funktionieren, funktionieren Web-Apps der 90er Jahre, die nach wichtigen Standards geschrieben wurden, immer noch nicht. Sie mögen passé aussehen, aber sie funktionieren.

Das Ziel hier ist nicht, eine Web-App zu schreiben, die auf ihrem Server hochfährt und dort 40 Jahre lang bleibt, ohne dass jemand sie erneut berührt. Es geht darum, ein Fundament zu schaffen, das noch Jahrzehnte später verwendet werden kann und das erweitert werden kann, um neue Funktionen zu unterstützen, ohne dass es von Grund auf neu erstellt werden muss.

Zunächst müssen Sie nach offiziellen Standards und nur nach offiziellen Standards codieren. Keine JavaScript-Funktionen, die nicht Teil eines ratifizierten ECMAScript-Standards sind. ES5.1 ist die aktuelle Version und wird im Allgemeinen unterstützt, sodass das Ziel sicher ist. Ebenso sind aktuelle Versionen von HTML5, CSS und Unicode gut. Keine experimentellen JavaScript-, CSS3- oder HTML-Funktionen (solche mit Herstellerpräfixen oder ohne 100% ige Übereinstimmung zwischen Browsern). Und keine browserspezifischen Kompatibilitäts-Hacks. Sie können eine neue Funktion verwenden, sobald sie im Standard enthalten ist und jeder sie ohne Präfixe unterstützt.

ES5-Unterstützung würde bedeuten, IE8 oder früher zu löschen, was ich sowieso vorschlage, da es browserspezifische Hacks erfordert, die in ein paar Jahren unbrauchbar sein werden. Ich würde den strengen Modus von ES5 für die beste Langlebigkeit vorschlagen, wodurch die Kompatibilität Ihres Basisbrowsers auf IE10 und neuere Versionen aller anderen gesetzt wird. Diese Browser bieten auch native Unterstützung für viele der HTML5-Funktionen zur Formularvalidierung und zum Platzhalter, die für eine sehr lange Zeit nützlich sein werden.

Neue Editionen von ECMAScript sind weiterhin mit älteren Versionen kompatibel, sodass es viel einfacher ist, kommende Funktionen zu übernehmen, wenn Ihr Code gemäß den aktuellen Standards geschrieben wurde. Beispielsweise können Klassen, die mit der bevorstehenden Syntax class definiert wurden, vollständig mit Klassen ausgetauscht werden, die mit der aktuellen constructor.prototype Syntax. So kann ein Entwickler in fünf Jahren Klassen für Datei in das ES6-Format umschreiben, ohne irgendetwas zu beschädigen - vorausgesetzt natürlich, Sie haben auch gute Komponententests.

Vermeiden Sie zweitens trendige JavaScript-App-Frameworks , insbesondere wenn diese die Art und Weise ändern, wie Sie Ihre App codieren. Backbone war der letzte Schrei, dann waren es SproutCore und Ember), und jetzt ist Angular das Framework, für das jeder gerne wirbt. Sie mögen nützlich sein, aber sie haben auch etwas gemeinsam: Sie brechen oft Apps und erfordern sie Code ändert sich, wenn neue Versionen herauskommen und ihre Langlebigkeit fraglich ist. Ich habe kürzlich eine Angular 1.1-App auf 1.2 aktualisiert und musste einiges umgeschrieben werden. Ebenso erfordert das Wechseln von Backbone 2 zu 3 Viele HTML-Änderungen. Standards bewegen sich aus einem bestimmten Grund nur langsam, aber diese Frameworks bewegen sich schnell und Dinge, die regelmäßig kaputt gehen, sind die Kosten.

Außerdem lassen neue offizielle Standards alte Frameworks oft überholt, und wenn dies geschieht, mutieren diese Frameworks entweder (mit bahnbrechenden Änderungen) oder bleiben zurück. Sie wissen, was mit allen konkurrierenden Versprechen-Bibliotheken der Welt passieren wird, wenn ECMAScript 6 ratifiziert ist und alle Browser die standardisierte Versprechen-Klasse unterstützen? Sie werden veraltet sein und ihre Entwickler werden aufhören, sie zu aktualisieren. Wenn Sie das richtige Framework ausgewählt haben, passt sich Ihr Code möglicherweise gut genug an, und wenn Sie schlecht geraten haben, werden Sie sich mit einem umfassenden Refactoring befassen.

Wenn Sie also überlegen, eine Bibliothek oder ein Framework eines Drittanbieters zu übernehmen, fragen Sie sich, wie schwierig es sein wird, diese in Zukunft zu entfernen. Wenn es sich um ein Framework wie Angular) handelt, das niemals entfernt werden kann, ohne Ihre App von Grund auf neu zu erstellen, ist dies ein gutes Zeichen dafür, dass es in einer 40-jährigen Architektur nicht verwendet werden kann. Wenn es ein drittes ist -Party-Kalender-Widget, das Sie mit einer benutzerdefinierten Middleware abstrahiert haben. Das Ersetzen würde einige Stunden dauern.

Drittens geben Sie ihm eine gute, saubere App-Struktur. Auch wenn Sie kein App-Framework verwenden, können Sie Entwickler-Tools nutzen und Skripte erstellen und ein gutes sauberes Design. Ich persönlich bin ein Fan des Abhängigkeitsmanagements von Closure Toolkit, da es leichtgewichtig ist und der Overhead beim Erstellen Ihrer App vollständig entfällt. LessCSS und SCSS sind auch großartige Tools zum Organisieren Ihrer Stylesheets und zum Erstellen standardbasierter CSS-Stylesheets für die Veröffentlichung.

Sie können Ihren eigenen Code auch in Einwegklassen mit einer MVC-Struktur organisieren. Das wird es viel einfacher machen, einige Jahre in die Zukunft zurückzukehren und zu wissen, was Sie gedacht haben, als Sie etwas geschrieben haben, und nur die Teile zu ersetzen, die es benötigen.

Sie sollten auch den Ratschlägen des W3C folgen und Präsentationsinformationen vollständig aus Ihrem HTML-Code heraushalten. (Dazu gehören Cheats wie das Vergeben von Präsentationsklassennamen für Elemente wie "Big-Green-Text" und "Two-Column-Wide".) Wenn Ihr HTML semantisch und CSS präsentativ ist, ist es viel einfacher, es zu pflegen und anzupassen zu neuen Plattformen in der Zukunft. Es wird auch einfacher sein, Unterstützung für spezielle Browser für Blinde oder Behinderte hinzuzufügen.

Viertens: Automatisieren Sie Ihre Tests und stellen Sie sicher, dass Sie eine nahezu vollständige Abdeckung haben. Schreiben Sie Komponententests für jede Klasse, ob serverseitig oder in JavaScript. Stellen Sie im Frontend sicher, dass jede Klasse in jedem unterstützten Browser gemäß ihrer Spezifikation ausgeführt wird. Automatisieren Sie diese Tests von Ihrem Build-Bot für jedes Commit. Dies ist sowohl für die Langlebigkeit als auch für die Zuverlässigkeit wichtig, da Sie Fehler frühzeitig erkennen können, selbst wenn aktuelle Browser sie verdecken. Sowohl die JSUnit-basierten Testframeworks von Jasmine als auch von Google Closure sind gut.

Sie sollten auch vollständige UI-Funktionstests ausführen, in denen Selenium/WebDriver gut sind. Grundsätzlich schreiben Sie ein Programm, das Ihre Benutzeroberfläche durchläuft und es so verwendet, als würde eine Person es testen. Verdrahten Sie diese auch mit dem Build-Bot.

Schließlich, wie andere bereits erwähnt haben, sind Ihre Daten König. Denken Sie über Ihr Datenspeichermodell nach und stellen Sie sicher, dass es für die Ewigkeit ausgelegt ist. Stellen Sie sicher, dass Ihr Datenschema solide ist, und stellen Sie sicher, dass es auch bei jedem Commit gründlich getestet wird. Stellen Sie sicher, dass Ihre Serverarchitektur skalierbar ist. Dies ist noch wichtiger als alles, was Sie am Frontend tun.

13

Abgesehen von den Problemen der unvernünftigen Erwartungen Ihres Kunden und der Konzentration auf die Designprobleme würde ich nicht bis zu 40 Jahre gehen, aber das Problem, das Sie anscheinend haben, der langfristigen Evolvabilität, ist genau das, was REST wurde für erstellt. Damit meine ich wirklich REST als Architekturstil, nicht die schlagwortgetriebene Entwicklung, die heutzutage so häufig mit dem Begriff assoziiert wird.

Bis zu einem gewissen Grad verstehen sich die Leute REST falsch, weil ich nicht genügend Details zum Medientyp-Design in meine Dissertation aufgenommen habe. Das liegt daran, dass mir die Zeit ausgegangen ist, nicht daran, dass ich dachte, es sei weniger wichtig als die anderen Aspekte von REST. Ebenso vermute ich, dass viele Leute es falsch verstehen, weil sie nur den Wikipedia-Eintrag zu diesem Thema lesen, der nicht auf maßgeblichen Quellen basiert.

Ich denke jedoch, dass die meisten Leute nur den Fehler machen, dass es einfach sein sollte, einfache Dinge zu entwerfen. In der Realität ist der Aufwand für das Entwerfen von Gegenständen umgekehrt proportional zur Einfachheit des Ergebnisses. In Bezug auf Architekturstile ist REST sehr einfach.

REST ist Software-Design im Maßstab von Jahrzehnten : Jedes Detail soll die Langlebigkeit der Software und die unabhängige Entwicklung fördern.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

Sie haben erwähnt, dass Sie eine RESTful-Schnittstelle verwenden möchten. Dieser Kommentar an sich legt nahe, dass Sie ernsthafte Nachforschungen anstellen und versuchen sollten, zu verstehen, worum es bei REST wirklich geht). Sie verbinden ihn wahrscheinlich nur mit der Zuordnung von HTTP-Methoden zu CRUD-Operationen, die am meisten Leute denken REST ist, aber es hat nichts damit zu tun.

Stellen Sie sich REST als eine Formalisierung der Architektur des Web selbst vor. Auf die eine oder andere Weise gibt es viele Teile des Web, die vor einem Jahrzehnt oder länger geschrieben wurden und noch verfügbar sind und sein können verwendet mit einem Kunden, der heute hergestellt wurde, also haben wir in dieser Abteilung etwas richtig gemacht. Es wird eine Menge Arbeit sein, das garantiere ich Ihnen, weil es schwierig ist, REST richtig zu machen, aber die langfristigen Vorteile sind es wert.

10
Pedro Werneck

Nachdem ich die Frage und die anderen (sehr gut durchdachten) Antworten gelesen habe, habe ich gedacht, dass ich auch meine zwei Cent lassen werde. Hinweis: Ich muss überhaupt keine wirklich alte Anwendung/Software warten. Als Referenz verwende ich meine eigene Hobby-Web-App, die einige offene Regierungsdaten erfasst, analysiert und in verschiedenen Formaten anzeigt. Die App begann als ein Projekt, in dem ich nicht alleine war und in dem die Regierung gerade angekündigt hat , dass sie diese Daten irgendwann irgendwie anbieten wird. Es war also klar, dass sich viele Dinge im Laufe der Zeit ändern werden. Und sie taten es. Was ich daraus gelernt habe:

  • Teilen Sie die Dinge in Mini-Anwendungen auf. Jeder kann seine Aufgabe für sich alleine erfüllen. Dies macht das Auswechseln eines einzelnen Stücks sehr schnell, sehr sicher und sehr einfach. Und wenn Sie wieder hineingehen müssen, ist es nicht wirklich schwer zu umgehen, warum Dinge passieren und wie Sie sie passieren. Wenn Sie oder eine andere Person später etwas ändern müssen, ist es einfacher, ein einzelnes Teil zu ersetzen als eine ganze Reihe von Dingen.
  • Holen Sie sich eine solide konstante Middleware/Layer, die für die Kommunikation zwischen den verschiedenen Teilen verwendet wird. In diesem Fall habe ich JSON verwendet, aber auch XML, INI oder ähnliche Standards wären in Ordnung. Es ist leicht zu wiederholen und kann in fast alles verwandelt werden. Alle sind bewährte Standards, die einige Zeit überleben werden. Auch wenn sich das zugrunde liegende Daten- und/oder Speichermodell ändert. Jede der Apps kann ihren eigenen Datenspeicher für ihre spezifische Aufgabe verwenden. Dadurch wird die Menge der gescannten Daten für eine Aufgabe kleiner, daher einfacher zu handhaben und zu warten und leichter auszutauschen.
  • Machen Sie sich keine Sorgen über Programmiersprachenentscheidungen. Diese werden sich im Laufe der Zeit ändern. Stellen Sie einfach sicher, dass Sie die Sprache verwenden, mit der Sie vertraut sind oder die am besten zu einer Aufgabe passt.
  • Stellen Sie sicher, dass Ihr Datenspeicher "horizontal skalierbar" ist und dass es einfach ist, zusätzliche Speichermodule anzuschließen.
  • Holen Sie sich einen gemeinsamen Punkt (in meinem Fall URIs), an dem die Mini-Apps aufgerufen werden und/oder Daten austauschen.

Zusammenfassend: Das, was mich am meisten interessiert, ist die Trennung von Bedenken und die Austauschbarkeit von Teilen, die für Aufgaben zugewiesen sind. Sie wissen einfach, dass sich in 40 Jahren (sogar in 5 oder 10 Jahren) Hardware, Schnittstellen, Speicher usw. stark verändern werden. Und spätere Entwickler müssen auf diese Änderungen reagieren und Teile Ihrer Anwendung austauschen, sei es der Datencontainer oder Teile der Benutzeroberfläche.

9
kaiser

Planen Sie Änderungen ein, um die Dinge so "zukunftssicher" wie möglich zu gestalten. Das heißt, versuchen Sie Ihr Bestes, um nicht für etwas anderes als die Fähigkeit zu optimieren, leicht zu ändern. Also keine Normalisierung, keine strikte Validierung und jede Menge lose Kopplungen.

  • Verwenden Sie wichtige Open-Source-Technologien. Für Daten stellen Closed-Source-Systeme eine große Risikoquelle dar, da nicht geplant werden kann, welche Unternehmen untergehen oder Strategien ändern, und der Zugriff auf die Daten mit sich bringt. Auch kleinere Open-Source-Projekte ohne eine lebendige Community verlieren mit größerer Wahrscheinlichkeit an Unterstützung.

  • Verwenden Sie eine schemalose NoSQL-Datenbank. Die Art der unstrukturierten Daten, die für einen Dokumentenspeicher wie MongoDB verwendet werden, stammt fast direkt aus dem Lehrbuch. Herkömmliche relationale Datenbanken und ihre Normalisierung sind gut, wenn Sie wissen, wie Ihre Daten strukturiert werden, aber das ist wirklich eine Fiktion, besonders hier. Die Kosten für das Ändern des Schemas in einem RDBS werden mit der Erweiterung des Systems immer größer. Wisse, dass sich die Struktur, die jetzt gewählt wird, am Ende ändern wird.

  • Entkoppeln Sie das System stark nach allgemein anerkannten Standards. Die Aufteilung des gesamten Datenzugriffs und der Mutation in Webdienste ist ein Schritt in diese Richtung. Die Kombination mit Nachrichtenwarteschlangen zum Übermitteln von Änderungen und dergleichen hilft einzelnen Teilen des Systems, Sprachen oder Technologien im Laufe der Zeit zu ändern.

7
phlogisticfugu

OK, also werde ich hier einige Dinge sagen, die wahrscheinlich ziemlich unbeliebt sein werden, aber bleib hier bei mir.

Da dies Ihr erstes Projekt ist, bei dem die Daten und/oder die Anwendung mehr als 20 Jahre dauern sollen und Sie das Projekt leiten, müssen Sie einen Schritt zurücktreten und überlegen, wie hoch die Erfolgsaussichten für dieses Projekt sind . Weil sie im Grunde genommen nahe Null sind.

Sie müssen viel Zeit damit verbringen, sich auf das Datenbankdesign zu konzentrieren und es richtig zu machen. Damit dieses Projekt erfolgreich ist, müssen Sie einen Datenarchitekten in das Projekt einbeziehen, und zwar eher früher als später. Ohne jemanden, der Erfahrung im Datenbankdesign hat und sich gut darauf vorbereitet, wie die Daten in Zukunft verwendet werden können, ist die Wahrscheinlichkeit, dass die Daten nach 5 Jahren noch viel weniger als 40 Jahre nützlich sind, gering bis gar nicht.

Die Erwartung, dass zwei Personen (von denen eine den Titel jr. Dev trägt) etwas von Grund auf neu bauen, das voraussichtlich 40 Jahre dauern wird, wird wahrscheinlich keinen Erfolg haben. Es sollte ein Team von Leuten geben, von denen viele Erfahrung in der Arbeit mit großen Projekten wie diesem haben und die am Datendesign, am API-Design und am Anwendungsdesign arbeiten. So etwas ist kein 2-Personen-Projekt.

Der Wunsch, das Projekt an etwas wie Drupal] zu binden, zeigt, warum das Projekt Leute benötigt, die daran gewöhnt sind, an solchen Projekten zu arbeiten. Sie möchten die Anwendung nicht an irgendetwas binden, das möglicherweise ausgeht Wenn Sie dies tun, könnte es sehr schnell sehr schwierig werden, jemanden zu finden, der in 5-10 Jahren am System arbeitet.

Ich würde diesen Rat dem Management geben und ihnen erklären, dass Sie mehr ältere Leute für das Projekt gewinnen müssen. Andernfalls ist das Projekt zum Scheitern verurteilt, und Sie werden wahrscheinlich derjenige sein, der die Schuld dafür trägt.

4
mrdenny

Die Anwendung muss 40 Jahre ohne Weiterentwicklung nicht überleben. Aber weil es von Grund auf neu gebaut werden würde oder sollte, könnte es immer noch "funktionieren".

Am wichtigsten ist die „Datenarchitektur“, die Stabilität und Governance ermöglicht und erweiterbar ist.

Wir haben Datenarchitektur und Taxonomie entwickelt, die das Ende der Menschheit fast überleben könnten, aber dennoch erweiterbar sind. Sie haben eine echte DATA TAXONOMY/DATA ARCHITECTURE-Person gefunden, die dies für Sie erledigt.

3
Alex S

Der Schlüssel hier ist, sich auf die Datenbank zu konzentrieren (wie einige oben gesagt haben). Dies muss kohärent sein und den Betrieb vollständig beschreiben. Es muss mit der Operation wachsen, wenn es sich ändert. Wenn es nicht einfach ist, etwas zu ändern, wird es veraltet sein und das ist der Todeskuss. Der Rest ist relativ weniger wichtig.

Ich bin mit den oben genannten nicht einverstanden, die behaupten, dass Normalisierung nicht wichtig ist, obwohl es immer Fälle gibt, in denen die aktuellen Systeme dem Job nicht gewachsen sind. In diesen Fällen denormalisieren Sie, stellen Sie jedoch sicher, dass die Datenbank die zusätzlichen Schreibvorgänge/Änderungen als Teil einer atomaren Transaktion verarbeitet. Auf diese Weise können Sie das Problem effektiv ignorieren, bis Sie es beheben können.

Das Unternehmen, für das ich vor meiner Pensionierung gearbeitet habe, betreibt ein System, das von Grund auf neu geschrieben wurde und seit 25 Jahren fast kontinuierlich wächst und praktisch alle Aspekte eines mittleren Einzelhändlers abdeckt. Aspekte dieses Systems, die ich für wichtig halte, sind:

  • Integration ist wichtig.
  • Die Datenbank muss sowohl für die IT als auch für andere Mitarbeiter korrekt und verständlich sein, daher ist eine fast paranoide Betonung der Benennung erforderlich. Wir haben Tabellen mit definierten Mnemoniken, die dann zu Tabellen- und Feldnamen zusammengefasst werden, und alle „Codes“ wurden ebenfalls als Konstanten benannt und in einer EAV-Tabellenstruktur gespeichert.
  • Wir haben Geschäftslogik in Datenbank-Trigger eingekapselt. Dies ist zunächst schmerzhaft und erfordert zusätzliche Arbeit, um Fehlermeldungen an Clients zu übertragen und um zu ermöglichen, dass Trigger flexibel geändert werden können, ohne auf einigen Systemen die gesamte Tabelle zu sperren. Dies spart jedoch schnell Zeit und zwingt die Datenbank dazu, viel korrekter zu sein als sonst.
  • Angenommen, Sie behalten mindestens Referenztabellen (im Idealfall alle außer den schnellsten und am wenigsten wichtigen Transaktionen) für die Lebensdauer des Systems bei, auch wenn diese "gelöscht" sind, damit Ihre Referenzen korrekt sind.
  • Stellen Sie aus diesem Grund sicher, dass eindeutige Kennungen und Transaktionsnummern langfristig dimensioniert sind. (Ich schlug ursprünglich scherzhaft vor, dass sie bis zu meiner Pensionierung dauern sollten).
3
Bush Al

Ich würde vorschlagen, Event Sourcing und Befehls- und Abfrageverantwortungstrennung zu verwenden. Dies liegt hauptsächlich daran, dass Sie sich nur auf die Ereignisse verlassen können, die bereits aufgetreten sind. Neue Arten von Ereignissen könnten kommen. Selbst wenn Sie sich Gedanken über ein Modell machen, ist es sicher, dass dies veraltet sein wird. Die Migration aller Daten mit jeder Version ist möglicherweise nicht möglich. Das Beste ist also, ein Modell zu haben, das Ihren aktuellen Anforderungen entspricht und das jedes Mal aus bereits aufgezeichneten Ereignissen berechnet wird, wenn Sie es benötigen, und dann Ereignisse zu verteilen, die aus dem aktuellen Status dieses Modells berechnet werden.

Denken Sie auch an Tests. Wenn die Anwendung in zehn Jahren verwendet wird, müssen Tester sicherstellen, dass sie immer noch das tut, was sie tun soll. Machen Sie das Testen Ihrer Anwendung durch Integrationstests so einfach wie möglich.

2
SpaceTrucker