Beratung zum Entwerfen von Webanwendungen mit einer Lebensdauer von über 40 Jahren

73

Szenario

Derzeit bin ich Teil eines Gesundheitsprojekts, dessen Hauptanforderung es ist, Daten mit unbekannten Attributen mithilfe von benutzerdefinierten 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
  • Berichtsmodul
  • Mobile / Tablet-Unterstützung

Lage

In nur 6 Monaten hat der derzeitige (beauftragte) 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 allmählich verloren, da er einige Beans entworfen hat, um "Löschvorgänge" in der Datenbank durchzuführen. Die Codebasis ist extrem aufgebläht und es gibt Jobs, um nur Daten zu synchronisieren, da die Datenbank nicht normalisiert ist. Sein Ansatz war es, sich auf Sicherungsjobs zu verlassen, um fehlende Daten wiederherzustellen, und er scheint nicht an ein Re-Factoring zu glauben.

Der Architekt, der dem Ministerpräsidenten meine Ergebnisse vorgelegt hat, wird mit Ablauf seines Vertrages entlassen. Mir wurde die Aufgabe übertragen, diese Anwendung neu zu gestalten. Mein Team besteht aus mir und einem Junior-Programmierer. Wir haben keine anderen Ressourcen. Wir haben einen 6-monatigen Anforderungsstopp 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 beim 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 Jahren 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 konstruktiven Überlegungen machen das System "zukunftssicherer"?
  • Welche Fragen sollten dem Kunden / PM gestellt werden, um das System "zukunftssicherer" zu machen?
Pete
quelle
59
Zukunftssicherheit ist eine Sache, aber ich bin der Meinung, dass ein Kunde nach Software fragen muss, deren Lebensdauer voraussichtlich 10x-20x länger ist als die aktuelle Geschichte des Mobile / Tablet-Computing oder 5x-8x länger als die aktuelle Geschichte der Sprache in use ist ... in Bezug auf die Stabilität eines bestimmten Computermodells unangemessen optimistisch.
31
Über 40 Jahre zukunftssicher zu sein, klingt nach einer Übung der Sinnlosigkeit.
Whatsisname
10
Um die Anforderung zu erfüllen, dass eine Datenbank für die nächsten 40 Jahre nützlich ist, würde ich alles auf Papier bringen. Papier hat sich bewährt, wohingegen die digitale Speicherung meistens bewiesen hat, wie viele Daten schnell verloren gehen. (Aber natürlich bewahren Sie alle Daten, die zerstört werden sollten)
Pieter B
34
Sie geben zwei Vertragsentwicklern 6 Monate Zeit, um dieses System aufzubauen? Sammeln Sie jahrelange Altdaten UND rechnen Sie mit neuen Anforderungen in Jahrzehnten? Wenn Sie das Projekt noch nicht verlassen haben, starten Sie es. Dies ist weitaus mehr als zwei Personen in einem Zeitraum, der sich dem Zeitrahmen nähert. Der Kunde hat völlig unangemessene Erwartungen und ist nicht bereit, angemessene Ressourcen für das Projekt bereitzustellen.
Sean McSomething
12
6 Monate für 2 Personen, um eine Anwendung zu entwickeln und zu implementieren, die mehr als 40 Jahre dauern muss? Es spielt keine Rolle, wie gut Sie sind, das klingt nach einem Versagens-Setup. Wenn Sie Ihre Organisation nicht davon überzeugen können, wie unvernünftig das ist, dann würde ich Ihnen empfehlen, sich so schnell wie möglich nach einer anderen Beschäftigung umzusehen.
dsw88

Antworten:

132

Daten sind König

Ich halte es für etwas unvernünftig, zu erwarten, dass eine Webanwendung um 2013 im Jahr 2053 noch funktionsfähig ist. Die Technologien werden sich ändern. Plattformen werden kommen und gehen. Bis dahin könnte HTML eine kuriose Erinnerung sein. Aber Ihre Daten werden immer noch da sein.

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

In Bezug auf die tatsächlichen Anwendungen hat Ihr Unternehmen hier wahrscheinlich Recht, wenn es eine Direktive von Grund auf neu erstellt. Ich verwalte einige Web-Apps, die älter als 10 Jahre sind, und ich bin sehr froh, dass sie nicht an die vorherrschenden CMS-Systeme von 2003 gebunden sind. Sie verwenden einheimische, sehr einfache Frameworks. Ich denke für so etwas sind Sie besser dran mit einem sehr einfachen Framework, das Sie speziell für die Bedürfnisse des Projekts erstellen.

In Wirklichkeit wird das Unternehmen über 40 Jahre lang (hoffentlich) eine ganze Reihe von Front-End- und Back-End-Diensten bereitstellen, um sich an sich entwickelnde Plattformen anzupassen. Daher würde ich eine Lebensdauer von 5 bis 10 Jahren für einzelne benutzerbezogene Anwendungen anstreben.

GroßmeisterB
quelle
13
"Wir werden diesen Code in 40 Jahren möglicherweise nicht mehr verwenden!" Aus diesem Grund gab es am Anfang einen Y2K-Fehler. Es ist nur eine schlechte Praxis, zu erwarten, dass Ihr Code ersetzt wird.
DougM
71
Der Y2K 'Bug' war ein Datenproblem - 2 statt 4 Ziffern wurden gespeichert. Deshalb schlage ich vor, mich auf Daten zu konzentrieren.
GroßmeisterB
24
Guter Punkt. Vor diesen Hintergrund, wenn jemand wirklich ihre Daten erwartet (und möglicherweise Datenbank als auch) im Einsatz seine 40+ Jahre, könnte es am besten sein , um die Datenbank zu entwerfen , mit möglichst wenigen herstellerspezifische Funktionen wie möglich. Wer in 20 Jahren all seinen Code entwirren / umschreiben muss, der auf speziellen Oracle / MS-SQL / jeglicher Funktionalität basiert, wird mit Ihnen nicht zufrieden sein. ;)
FrustratedWithFormsDesigner
4
Dies ist ein solider Rat. Es gibt noch viele Cobol-Programme, die ursprünglich vor 20 bis 30 Jahren geschrieben wurden. Obwohl sich die Technologie weiterentwickelt, bleibt Ihr Code in der einen oder anderen Form in Gebrauch, wenn Ihr Daten- und Objektmodell solide ist und die Daten von Interesse sind.
Bobble
7
Da jemand das Y2K erzogen hat: Achten Sie auf das UNIX Y2K ( en.wikipedia.org/wiki/Year_2038_problem ).
MrFox
40

Wir produzieren Software, die seit über 20 Jahren von zahlenden Kunden genutzt wird. Die Codebasis hat mehrere Generationen von Tools zur Versionskontrolle überlebt. Unsere Software trifft alle Ihre Aufzählungszeichen mit Ausnahme der Tabletsache.

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

Sorgen Sie sich für Ihre Datenbank nicht zu sehr um die Normalisierung. Stattdessen sollten Sie sich darum kümmern, alles zu protokollieren und Prüftabellen zu haben, die Änderungen / Löschungen in Daten verfolgen. Planen Sie beim Aktualisieren von Versionen das parallele Testen neuer Versionen für genügend Zeit ein, um sicherzustellen, dass Ihre Daten migriert werden. 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. Backups testen. Wenn Sie Objekte serialisieren, die in der Datenbank gespeichert werden sollen, verwenden Sie XML anstelle der von Ihrem Entwicklungsframework bereitgestellten Serialisierung.

Für Ihre Besetzung benötigen langfristige Codebasen ein langfristiges Gedächtnis. Im Idealfall möchten Sie Menschen, die schon lange in der Nähe sind. Wenn das institutionell unmöglich ist, müssen Sie alles in so etwas wie einem Wiki dokumentieren. Mein Rat ist ein Wiki, das sich in Ihr Bug-Tracking-System einfügt.

Stellen Sie für Ihre Codebasis sicher, dass Sie Kommentare in Ihrem Code haben. Bei der Migration von einem Versionskontrollsystem auf ein anderes gehen fast immer Ihre Check-in-Kommentare verloren. Ich bin ein Fan von Benennungstests nach Spezifikations- und Fehlernummern. Auf diese Weise Test_Bug_1235 wissen Sie, was und wo Sie herausfinden können, was getestet werden soll, wenn der Komponententest unterbrochen wird. Es ist nicht so "sexy" wie das Benennen Ihrer Tests, Check_File_Save_Networked_Drivesaber diese Art von Test ist anders als bei Spezifikationen, Anforderungen oder Fehlern schwer zurückzuverfolgen Test_requirement_54321_case_2.

Tangurena
quelle
Vielen Dank für den Austausch Ihrer Erfahrungen. Ich muss definitiv einige davon erledigen, da der aktuelle Architekt keinen seiner Codes kommentiert oder uns Unterlagen zur Verfügung gestellt hat. Es war ein logistischer Albtraum, aber ich hoffe, das zu ändern. Das PDF / A-Format werde ich auf jeden Fall untersuchen, da es von unserem Kunden benötigt wird - insbesondere für Audits. Nochmals vielen Dank für Ihren Rat!
Pete
4
Dies ist eine umfassende und durchdachte Antwort. Sie weisen auf die Bedeutung der Überwachung hin, sowohl für Änderungen der Daten als auch für die Datenqualität, aber auch aus rechtlichen Gründen für die Verfolgung, wer welche Daten anzeigt . Siehe HIPAA . Wenn Ihre Software in den USA verwendet werden soll, gelten für Sie bestimmte Sicherheitsbeschränkungen und -anforderungen, die nach diesem Gesetz erforderlich sind.
maple_shaft
3
… Zumindest SVN to Git ist mit vollem Commit-Verlauf möglich.
Feeela
Nicht nur SVN zu Git, sondern auch die meisten nicht aus der Steinzeit stammenden Systeme, auch wenn ältere Systeme wie CVS häufig manuell mit dem Reposurgeon angepasst werden müssen. Die meisten Exporteure geben auch einen Git-Fast-Export-Stream aus, der so einfach ist, dass er auch von Nicht-Git-VCSs importiert werden kann.
Grawity
2
Ich schlage vor, Sie benennen Tests nicht erst nach den Nummern für Bug-Tracking und -Spezifikation, da: a) die Fehlernummern in der Regel bei 0 beginnen (da niemand 5-stellige Nummern zu mögen scheint) und die Software für Bug-Tracking ausgetauscht wird; b) die Spezifikationen in der Regel verloren gehen (hässlich, aber es passiert oft genug); c) Sexy Namen machen es oft deutlich genug. Ein Verweis auf spec / bug id ist jedoch immer eine gute Idee.
Bernstein
29

Anstatt herauszufinden, wie diese Anwendung in 20 Jahren noch funktioniert, sollten Sie sich ein halbes Jahr Zeit nehmen, um die vom ursprünglichen Architekten verursachten Probleme zu beheben und eine vernünftige, robuste Architektur einzurichten gehe von dort aus vorwärts

Eine teilweise De-Normalisierung einer Datenbank ist in einem medizinischen Umfeld nicht unbedingt völlig unerwartet. Einige Teile der medizinischen Datenbanken weisen Merkmale auf, die sie für das EAV- Modell (Entity / Attribute / Value) geeignet machen .

Robert Harvey
quelle
2
@ user2708395 Seien Sie vorsichtig mit dem EAV-Design, da es möglicherweise nicht die leistungsstärkste und leicht abzufragende ist. Es ist möglicherweise auch keine gute Wahl für die Berichterstellung.
maple_shaft
@maple_shaft Das habe ich auch gelesen. Ich werde sehr vorsichtig damit sein, da ich einige Horrorgeschichten gehört habe, in denen die Leute es übertreiben. Sie möchten eine Berichtsdatenbank verwenden, um die Abfrage zu vereinfachen, da der Client nur einmal im Monat Berichte generiert.
Pete
4
@maple_shaft: Normalerweise werden Daten aus dem EAV-Schema / der Datenbank in ein separates Berichtsschema / eine separate Berichtsdatenbank extrahiert.
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner Das ist ein ausgezeichneter Punkt. Die Flexibilität Ihres Schemas, die EAV bietet, ist unübertroffen, aber es ist sicherlich kein Wundermittel für alle Persistenz.
maple_shaft
Ich gebe zwar zu, dass EAVs verwendet werden können, Sie wären jedoch überrascht, welche Beziehungen Sie finden können. Das heißt, die zusätzlichen Attribute, die häufig für diese Art von Branchen (Gesundheitswesen, Kundenbeziehungen usw.) angezeigt werden, müssen irgendwohin gehen ... Stellen Sie einfach sicher, dass Sie eine Attributschlüssel-Tabelle verwenden, um eine kanonische Liste von zu erhalten Attribute.
Clockwork-Muse
13

Antwort aus Front-End-Perspektive:

Hören Sie nicht zu, wie alle sagen, dass dies nicht möglich ist, da ein experimenteller Webdienst der San Francisco State University, den ich 1996 mitschrieb, vor ein paar Jahren endlich in den Internet-Himmel kam und in dieser Zeit keine einzige Browser-Kompatibilitätskorrektur 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 ein paar Jahre später durch etwas auffälligeres ersetzt, aber es gibt keinen Grund, warum die ursprüngliche Benutzeroberfläche mit geringfügigen Kompatibilitätskorrekturen heute noch nicht ausgeführt werden konnte.

Der Trick besteht darin, sicherzustellen, dass Ihre App nur allgemein unterstützte W3C / ECMA-Standards verwendet und ein klares Design unter Ihrer Kontrolle hat. Während viele Web-Apps, die auf die trendige Technologie der 90er Jahre zugeschnitten sind, heute nicht mehr oder überhaupt nicht mehr funktionieren, sind es Web-Apps der 90er Jahre, die nach den wichtigsten Standards geschrieben wurden, immer noch. Sie mögen passé aussehen, aber sie funktionieren.

Hier geht es nicht darum, eine Web-App zu schreiben, die auf ihrem Server hochfährt und dort 40 Jahre bleibt, ohne dass jemand sie erneut berührt. Es geht darum, ein Fundament zu schaffen, das noch Jahrzehnte in Gebrauch sein kann und das wachsen kann, um neue Funktionen zu unterstützen, ohne dass es von Grund auf neu erstellt werden muss.

Zuallererst 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 (die mit Herstellerpräfixen oder ohne 100% ige Übereinstimmung zwischen den Browsern). Und keine browserspezifischen Kompatibilitätshacks. Sie können eine neue Funktion verwenden, sobald sie im Standard enthalten ist. Alle Benutzer unterstützen sie ohne Präfixe.

ES5-Unterstützung würde bedeuten, IE8 oder früher fallen zu lassen, was ich sowieso vorschlage, da es browserspezifische Hacks erfordert, die in ein paar Jahren unbrauchbar werden. Ich würde den Strikten Modus von ES5 vorschlagen, um die beste Langlebigkeitschance zu erzielen. Dadurch wird die Basiskompatibilität Ihres Browsers mit IE10 und den neuesten Versionen aller anderen festgelegt . Diese Browser bieten auch native Unterstützung für viele der HTML5-Funktionen zur Formularüberprüfung und Platzhalter, die sehr lange nützlich sein werden.

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

Zweitens sollten Sie trendige JavaScript-App-Frameworks vermeiden, insbesondere wenn sie die Art und Weise ändern, in der 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, haben aber auch eines gemeinsam: Sie brechen häufig Apps und erfordern Codeänderungen, 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 umschreiben. Ebenso sind für den Wechsel von Backbone 2 zu 3 viele HTML-Änderungen erforderlich. 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 machen neue offizielle Standards alte Frameworks häufig überholt. In diesem Fall mutieren diese Frameworks entweder (mit aktuellen Änderungen) oder bleiben zurück. Wissen Sie, was mit allen konkurrierenden Versprechenbibliotheken der Welt passieren wird, wenn ECMAScript 6 ratifiziert ist und alle Browser die standardisierte Versprechen-Klasse unterstützen? Sie sind veraltet und werden von ihren Entwicklern nicht mehr aktualisiert. Wenn Sie sich für das richtige Framework entschieden haben, passt sich Ihr Code möglicherweise gut an, und wenn Sie nicht sicher sind, ob es sich um eine größere Umgestaltung handelt.

Wenn Sie also daran denken, eine Bibliothek oder ein Framework von Drittanbietern zu übernehmen, fragen Sie sich, wie schwer es sein wird, diese in Zukunft zu entfernen. Wenn es sich um ein Framework wie Angular handelt, das niemals entfernt werden kann, ohne die 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 sich um ein Kalender-Widget eines Drittanbieters handelt, das Sie mit einer benutzerdefinierten Middleware abstrahiert haben, dauert das Ersetzen einige Stunden.

Drittens geben Sie ihm eine gute, saubere App-Struktur. Auch wenn Sie kein App-Framework verwenden, können Sie Entwickler-Tools, Skripts und ein gutes, übersichtliches Design nutzen. 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 entfernt wird. LessCSS und SCSS eignen sich auch hervorragend 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, mehrere 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 brauchen.

Sie sollten auch den Ratschlägen des W3C folgen und Präsentationsinformationen vollständig aus Ihrem HTML-Code entfernen. (Dazu gehören Cheats wie das Vergeben von Namen für Präsentationsklassen für Elemente wie "großer grüner Text" und "zwei Spalten breit".) Wenn Ihr HTML semantisch und CSS präsentativ ist, ist es viel einfacher, es zu pflegen und anzupassen auf neue Plattformen in der Zukunft. Es wird auch einfacher, Unterstützung für spezialisierte Browser für blinde oder behinderte Menschen 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, egal ob serverseitig oder in JavaScript. Stellen Sie im Front-End 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 sie von aktuellen Browsern verdeckt werden. Sowohl die JSUnit-basierten Test-Frameworks von Jasmine als auch von Google Closure sind gut.

Sie sollten auch vollständige UI-Funktionstests durchführen, in denen Selenium / WebDriver gut ist. 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 ebenfalls mit dem Build-Bot.

Wie andere bereits erwähnt haben, sind Ihre Daten König. Denken Sie über Ihr Datenspeichermodell nach und stellen Sie sicher, dass es auf Langlebigkeit ausgelegt ist. Stellen Sie sicher, dass Ihr Datenschema solide ist, und stellen Sie sicher, dass es bei jedem Commit gründlich getestet wird. Und stellen Sie sicher, dass Ihre Serverarchitektur skalierbar ist. Dies ist noch wichtiger als alles, was Sie am Frontend tun.

Richard Connamacher
quelle
1
Der gute Rat zu 'JS-Frameworks' gilt auch für Backend-Frameworks. Siehe den Rat von Onkel Bob Martin .
Brian Low
Ehrlich gesagt, wäre ich vorsichtig mit JS, wenn man den Kontext bedenkt. Ich kann mir vorstellen, dass HTML in 40 Jahren existiert. Ich würde mich nicht darauf verlassen, welcher Konverter verwendet wird, um JS notwendigerweise so zu unterstützen, wie Sie es möchten (und denke, dass Ihr JS möglicherweise das Falsche tut, da das bevorzugte Ausgabegerät möglicherweise unvorstellbar anders ist).
Eamon Nerbonne
10

Abgesehen von den unangemessenen Erwartungen Ihres Kunden und der Fokussierung auf Designprobleme würde ich 40 Jahre nicht überschreiten, aber das Problem, das Sie anscheinend haben, ist genau das, wofür REST geschaffen wurde . Damit meine ich wirklich REST als einen Architekturstil, nicht das Schlagwort, das heutzutage so häufig mit dem Begriff assoziiert wird.

In gewissem Maße verstehen die Leute REST falsch, weil ich in meiner Dissertation nicht genügend Details zum Design von Medientypen angegeben habe. Das liegt daran, dass mir die Zeit ausgeht, und nicht daran, dass ich dachte, es sei weniger wichtig als die anderen Aspekte von REST. Ebenso vermute ich, dass viele Leute etwas falsch machen, weil sie nur den Wikipedia-Eintrag zu diesem Thema lesen, der nicht auf maßgeblichen Quellen basiert.

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

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

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

Sie haben erwähnt, dass Sie beabsichtigen, eine RESTful-Schnittstelle zu verwenden. Dieser Kommentar an sich legt nahe, dass Sie ernsthafte Nachforschungen anstellen und versuchen sollten, zu verstehen, worum es bei REST wirklich geht. Sie verbinden es wahrscheinlich nur mit der Zuordnung von HTTP-Methoden zu CRUD-Operationen, die die meisten Leute für REST halten, aber das hat nichts damit zu tun.

Stellen Sie sich REST als eine Formalisierung der Architektur des Webs selbst vor. Auf die eine oder andere Weise gibt es viele Teile des Internets, die vor einem Jahrzehnt oder später geschrieben wurden und noch verfügbar sind und mit einem Kunden verwendet werden können, der heute erstellt wurde. Ich garantiere Ihnen, es wird eine Menge Arbeit sein, denn es ist schwierig, REST richtig zu machen, aber die langfristigen Vorteile sind es wert.

Pedro Werneck
quelle
Das ist sehr hilfreich! Danke. Ich habe mich eingehender mit REST befasst und sehe, dass es enorme Vorteile hat und wie es über die HTTP-Methoden hinaus erweitert werden kann. Es ist ziemlich mächtig und ich bin ziemlich aufgeregt, damit zu arbeiten. Danke auch für den Link! Ich wünschte nur, ich hätte mehr Zeit!
Pete
9

Nachdem ich die Frage und die anderen (sehr gut durchdachten) Antworten gelesen habe, habe ich gedacht, dass ich meine zwei Cent auch lassen werde. Hinweis: Ich muss überhaupt keine wirklich alte Anwendung / Software warten. Als Referenz verwende ich meine eigene Work-in-Progress-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 irgendwie anbieten wird. Es war also klar, dass sich mit der Zeit viele Dinge ändern werden. Und sie taten es. Was ich daraus gelernt habe:

  • Teilen Sie die Dinge in Mini-Anwendungen auf. Jeder ist in der Lage, seine Aufgabe für sich zu erfüllen. Dies macht das Auswechseln eines einzelnen Teils sehr schnell, sehr sicher und sehr einfach. Und wenn Sie zurückkehren müssen, ist es nicht wirklich schwierig, herauszufinden, warum Dinge passieren und wie Sie passieren. Wenn Sie oder jemand anderes später etwas ändern muss, ist es einfacher, ein einzelnes Teil als eine ganze Reihe von Dingen zu ersetzen.
  • 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 die zugrunde liegenden Daten und / oder das Speichermodell ändern. Jede der Apps kann für ihre spezifische Aufgabe einen eigenen Datenspeicher verwenden. Dadurch wird die Menge gescannter Daten für eine Aufgabe kleiner, die Handhabung und Wartung wird vereinfacht und der Austausch wird erleichtert.
  • Mach dir 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 zusätzliche Speichermodule problemlos angeschlossen werden können.
  • Holen Sie sich einen gemeinsamen Punkt (in meinem Fall sind es URIs), an dem die Mini-Apps aufgerufen werden und / oder Daten austauschen.

Fazit: Am wichtigsten ist mir die Trennung der Belange und die Austauschbarkeit der für Aufgaben zugewiesenen Teile. 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.

Kaiser
quelle
1
Sehr guter Rat! Vielen Dank. Ich bin definitiv mit der Aufgabentrennung und der Erstellung der Mini-Apps einverstanden. Mit dem aktuellen Build ist alles gekoppelt, was es schwierig macht, neue Funktionen und Anforderungen zu integrieren. Ich hoffe, mit einer RESTful-Schnittstelle zu gehen und JSON zu verwenden. Nicht zu bemängeln, aber als ich zum ersten Mal bei JSON anfing, ließ mich der Offshore-Architekt nicht JSON verwenden. Also habe ich ihm nur gesagt, dass ich "Strings" übergeben habe und den Teil weggelassen, dass diese Strings im JSON-Format sind. :)
Pete
7

Planen Sie Veränderungen ein, um die Dinge so "zukunftssicher" wie möglich zu machen. Das heißt, versuchen Sie Ihr Bestes, um nicht für etwas anderes als die Fähigkeit zu optimieren, sich leicht zu ändern. Also keine Normalisierung, keine strenge Validierung und lose Kopplung in Hülle und Fülle.

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

  • Verwenden Sie eine NoSQL-Datenbank ohne Schema. Die Art der unstrukturierten Daten, die verwendet werden, ist für einen Dokumentenspeicher wie MongoDB fast aus dem Lehrbuch entfernt. Traditionelle 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 die Änderung des Schemas in einem RDBS werden mit zunehmender Systemerweiterung immer höher. Wisse, dass sich die Struktur, die jetzt gewählt wird, ändern wird.

  • Entkoppeln Sie das System stark mit allgemein anerkannten Standards. Die Aufteilung aller Datenzugriffe und Mutationen in Webdienste ist ein Schritt in diese Richtung. Wenn Sie dies mit Nachrichtenwarteschlangen zum Senden von Änderungen kombinieren, können einzelne Teile des Systems im Laufe der Zeit Sprachen oder Technologien ändern.

phlogisticfugu
quelle
Leider bedeutet die Verwendung einer schemenlosen Datenbank nicht, dass die Umstrukturierung und Reorganisation von Daten keine Kosten verursacht.
Alex D
4

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, in dem die Daten und / oder die Anwendung mehr als 20 Jahre dauern sollen, und Sie derjenige sind, der das Projekt leitet, müssen Sie einen Schritt zurücktreten und darüber nachdenken, wie die Erfolgsaussichten dieses Projekts stehen . Weil sie im Grunde gegen Null sind.

Sie müssen viel Zeit darauf verwenden, 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 darauf freut, wie die Daten in Zukunft verwendet werden können, ist die Wahrscheinlichkeit gering, dass die Daten nach 5 Jahren und noch viel weniger als 40 Jahren noch nützlich sind.

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

Der Wunsch, das Projekt an etwas wie Drupal zu binden, zeigt, warum das Projekt Menschen benötigt, die es gewohnt sind, an solchen Projekten zu arbeiten. Sie möchten die Anwendung nicht an irgendetwas binden, das innerhalb weniger Jahre aus der Mode kommen könnte. In diesem Fall könnte es sehr schnell schwierig werden, jemanden zu finden, der in 5-10 Jahren an dem System arbeitet.

Ich würde diesen Rat an die Geschäftsleitung weitergeben und ihnen erklären, dass Sie mehr Senioren 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.

mrdenny
quelle
3

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

Was am wichtigsten ist, ist die „Datenarchitektur“, die Stabilität und Governance bietet und erweiterbar ist.

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

Alex S
quelle
Ich denke, das war der Misserfolg dieses Projekts von Anfang an, dass es ohne einen richtigen Datenarchitekten gestartet wurde. Dies ist definitiv ein sehr guter Rat.
Pete
Zeit, mich anzurufen und einzustellen :) Ich mache gerade eine Data Governance & Taxonomy-Sache für einige Unternehmen :)
Alex S
3

Der Schlüssel hier ist, sich auf die Datenbank zu konzentrieren (wie bereits erwähnt). Dies muss kohärent sein und die Funktionsweise vollständig beschreiben. Es muss mit der Operation mitwachsen, wenn es sich ändert. Wenn es nicht einfach ist, sich zu ändern, wird es veraltet sein und das ist der Kuss des Todes. Der Rest ist relativ unwichtig.

Ich stimme den oben genannten Personen nicht zu, die meinen, Normalisierung sei nicht wichtig, obwohl es immer Fälle gibt, in denen die aktuellen Systeme den Anforderungen nicht gerecht werden. In diesen Fällen denormalisieren Sie, stellen Sie jedoch sicher, dass die Datenbank die zusätzlichen Schreib- / Änderungsvorgänge 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 entwickelt wurde und seit 25 Jahren nahezu kontinuierlich wächst und nahezu alle Aspekte eines mittleren Einzelhändlers abdeckt. Aspekte dieses Systems, die ich für wichtig halte, sind:

  • Integration ist lebenswichtig.
  • 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 Mnemonics, die dann zu Tabellen- und Feldnamen zusammengefasst werden. 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ätzlichen Aufwand, um Fehlermeldungen an Clients zu senden und Trigger flexibel ändern zu können, ohne die gesamte Tabelle auf einigen Systemen zu sperren. Dies spart jedoch schnell viel Zeit und zwingt die Datenbank dazu, viel korrekter zu sein als sonst.
  • Angenommen, Sie behalten mindestens Referenztabellen (im Idealfall alle bis auf die schnellsten und am wenigsten wichtigen Transaktionen) für die Lebensdauer des Systems, auch wenn diese "gelöscht" wurden, damit Ihre Referenzen korrekt sind.
  • Stellen Sie deshalb sicher, dass alle eindeutigen Bezeichner und Transaktionsnummern langfristig dimensioniert sind. (Ich habe ursprünglich im Scherz vorgeschlagen, dass sie bis zu meiner Pensionierung Bestand haben sollten).
Bush Al
quelle
2

Ich würde vorschlagen, Event-Sourcing und die Trennung von Befehls- und Abfrageverantwortung zu verwenden . Dies liegt hauptsächlich daran, dass Sie sich nur bei den Ereignissen sicher sein 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. Das Migrieren aller Daten mit jeder Version ist möglicherweise nicht möglich. Am besten ist es also, ein Modell zu haben, das Ihren aktuellen Anforderungen entspricht und das jedes Mal, wenn Sie es benötigen, aus bereits aufgezeichneten Ereignissen berechnet wird, 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 Integration so einfach wie möglich.

SpaceTrucker
quelle