Hallo Freunde. Im Vorgriff auf den Start des Kurses , teilen Ihnen traditionell die Übersetzung nützlichen Materials mit.
Software löst immer mehr alltägliche Aufgaben und wird dabei immer komplexer. Wie Marc Andressen einmal sagte: Es verschlingt die Welt.
Infolgedessen hat sich die Art und Weise, wie Anwendungen entwickelt und bereitgestellt werden, in den letzten Jahren dramatisch verändert. Dabei handelte es sich um tektonische Verschiebungen, die zu einer Reihe von Prinzipien führten. Diese Prinzipien haben sich beim Teamaufbau, beim Entwerfen, Entwickeln und Bereitstellen Ihrer Anwendung für Endbenutzer als hilfreich erwiesen.
Die Grundsätze lassen sich wie folgt zusammenfassen: Die Anwendung sollte klein und webbasiert sein und über eine entwicklerorientierte Architektur verfügen. Unter Berücksichtigung dieser drei Prinzipien können Sie eine robuste End-to-End-Anwendung erstellen, die dem Endbenutzer schnell und sicher bereitgestellt werden kann und leicht skalierbar und erweiterbar ist.
Jedes der vorgeschlagenen Prinzipien weist eine Reihe von Aspekten auf, die wir diskutieren werden, um zu zeigen, wie jedes Prinzip zum Endziel beiträgt, nämlich der schnellen Bereitstellung zuverlässiger Anwendungen, die einfach zu warten und zu verwenden sind. Wir werden die Prinzipien in Bezug auf ihre Gegensätze betrachten, um zu klären, was sie bedeuten, sagen wir: „Achten Sie darauf, dass Sie Folgendes verwenden.“ Kleinheitsprinzip".
Wir hoffen, dass dieser Artikel Sie dazu ermutigt, die vorgeschlagenen Prinzipien zum Erstellen moderner Anwendungen zu verwenden, die einen einheitlichen Entwurfsansatz im Kontext eines ständig wachsenden Technologie-Stacks bieten.
Durch die Anwendung dieser Prinzipien werden Sie feststellen, dass Sie von den neuesten Trends in der Softwareentwicklung profitieren, einschließlich der für die Entwicklung und Bereitstellung von Anwendungen, die Verwendung von Containern (z. B. ) und Container-Orchestrierungs-Frameworks (z. B. ), die Nutzung von Microservices (einschließlich der Microservice-Architektur). и für Microservice-Anwendungen.
Was ist eine moderne Anwendung?
Moderne Anwendungen? Moderner Stack? Was genau bedeutet „modern“?
Die meisten Entwickler haben nur eine allgemeine Vorstellung davon, woraus eine moderne Anwendung besteht, daher ist es notwendig, dieses Konzept klar zu definieren.
Eine moderne App unterstützt mehrere Clients, unabhängig davon, ob es sich um eine Benutzeroberfläche der React-JavaScript-Bibliothek, eine mobile Android- oder iOS-App oder eine App handelt, die eine Verbindung zu einer anderen API herstellt. Eine moderne Anwendung impliziert eine unbegrenzte Anzahl von Clients, für die sie Daten oder Dienste bereitstellt.
Eine moderne Anwendung stellt eine API für den Zugriff auf die angeforderten Daten und Dienste bereit. Die API sollte unveränderlich und konstant sein und nicht speziell für eine bestimmte Anfrage eines bestimmten Clients geschrieben werden. Die API ist über HTTP(S) verfügbar und bietet Zugriff auf alle in der GUI oder CLI verfügbaren Funktionen.
Die Daten müssen in einem allgemein akzeptierten, interoperablen Format wie JSON verfügbar sein. Eine API stellt Objekte und Dienste auf saubere und organisierte Weise bereit, so wie RESTful API oder GraphQL eine anständige Schnittstelle bieten.
Moderne Anwendungen basieren auf dem modernen Stack, und der moderne Stack ist der Stack, der solche Anwendungen unterstützt. Mit diesem Stack kann ein Entwickler problemlos eine Anwendung mit einer HTTP-Schnittstelle und klaren API-Endpunkten erstellen. Der gewählte Ansatz ermöglicht es Ihrer Anwendung, problemlos Daten im JSON-Format zu empfangen und zu senden. Mit anderen Worten, der moderne Stapel entspricht den Elementen der Zwölf-Faktor-Anwendung für .
Beliebte Versionen dieses Stapeltyps basieren auf , , , , и . Microservice-Architektur stellt ein Beispiel für einen modernen Stack dar, der in jeder der genannten Sprachen implementiert ist.
Bitte beachten Sie, dass wir keinen ausschließlich Microservice-Ansatz befürworten. Viele von Ihnen arbeiten mit Monolithen, die weiterentwickelt werden müssen, während andere mit SOA-Anwendungen zu tun haben, die erweitert und zu Microservice-Anwendungen werden. Wieder andere setzen auf serverlose Anwendungen und einige implementieren Kombinationen der oben genannten. Die im Artikel dargelegten Grundsätze gelten mit nur wenigen geringfügigen Änderungen für jedes dieser Systeme.
Principles
Nachdem wir nun ein gemeinsames Verständnis davon haben, was eine moderne Anwendung und ein moderner Stack sind, ist es an der Zeit, sich mit den Architektur- und Entwicklungsprinzipien zu befassen, die Ihnen bei der Entwicklung, Implementierung und Wartung einer modernen Anwendung gute Dienste leisten werden.
Eines der Prinzipien klingt wie „kleine Anwendungen machen“, nennen wir es einfach Kleinheitsprinzip. Es gibt unglaublich komplexe Anwendungen, die aus vielen beweglichen Teilen bestehen. Wenn Sie eine Anwendung aus kleinen, diskreten Komponenten erstellen, ist es wiederum einfacher, sie als Ganzes zu entwerfen, zu warten und damit zu arbeiten. (Beachten Sie, dass wir von „vereinfacht“ und nicht von „vereinfacht“ gesprochen haben.
Das zweite Prinzip besteht darin, dass wir die Produktivität der Entwickler steigern können, indem wir ihnen helfen, sich auf die von ihnen entwickelten Funktionen zu konzentrieren, und sie gleichzeitig von Infrastruktur- und CI/CD-Bedenken während der Implementierung befreien. Kurz gesagt, unser Ansatz konzentriert sich auf Entwickler.
Schließlich muss alles rund um Ihre Anwendung mit dem Netzwerk verbunden sein. In den letzten 20 Jahren haben wir große Fortschritte in Richtung einer vernetzten Zukunft gemacht, da Netzwerke immer schneller und Anwendungen komplexer werden. Wie wir gesehen haben, muss eine moderne Anwendung über ein Netzwerk von vielen verschiedenen Clients genutzt werden. Die Anwendung des Netzwerkdenkens auf die Architektur hat erhebliche Vorteile, die gut damit einhergehen Kleinheitsprinzip und das Konzept des Ansatzes, entwicklerorientiert.
Wenn Sie diese Grundsätze beim Entwerfen und Implementieren einer Anwendung berücksichtigen, werden Sie einen unbestreitbaren Vorteil bei der Entwicklung und Bereitstellung Ihres Produkts haben.
Schauen wir uns diese drei Prinzipien genauer an.
Kleinheitsprinzip
Für das menschliche Gehirn ist es schwierig, eine große Menge an Informationen gleichzeitig wahrzunehmen. In der Psychologie bezieht sich der Begriff „kognitive Belastung“ auf die Gesamtmenge an geistiger Anstrengung, die erforderlich ist, um Informationen im Gedächtnis zu behalten. Die Reduzierung der kognitiven Belastung der Entwickler hat Priorität, da sie sich so auf die Lösung des Problems konzentrieren können, anstatt das aktuelle komplexe Modell der gesamten Anwendung und der zu entwickelnden Funktionen im Kopf zu behalten.
Anwendungen zerfallen aus folgenden Gründen:
- Reduzierte kognitive Belastung der Entwickler;
- Beschleunigung und Vereinfachung des Testens;
- Schnelle Lieferung von Änderungen in der Anwendung.
Es gibt mehrere Möglichkeiten, die kognitive Belastung von Entwicklern zu reduzieren, und hier kommt das Prinzip der Kleinheit ins Spiel.
Hier sind also drei Möglichkeiten, die kognitive Belastung zu reduzieren:
- Reduzieren Sie den Zeitrahmen, den sie bei der Entwicklung einer neuen Funktion berücksichtigen müssen – je kürzer der Zeitrahmen, desto geringer ist die kognitive Belastung.
- Reduzieren Sie die Menge an Code, an der einmalige Arbeiten ausgeführt werden – weniger Code – weniger Last.
- Vereinfachen Sie den Prozess der Durchführung inkrementeller Änderungen an einer Anwendung.
Verkürzung des Entwicklungszeitrahmens
Kehren wir zu den Tagen zurück, als die Methodik waterfall war der Standard für den Entwicklungsprozess und Zeitrahmen von sechs Monaten bis zwei Jahren für die Entwicklung oder Aktualisierung einer Anwendung waren gängige Praxis. Typischerweise lesen Ingenieure zunächst relevante Dokumente wie die Produktanforderungen (PRD), das Systemreferenzdokument (SRD) und den Architekturentwurf und beginnen, all diese Dinge in einem kognitiven Modell zusammenzufassen, nach dem sie programmieren. Da sich die Anforderungen und damit auch die Architektur änderten, mussten große Anstrengungen unternommen werden, um das gesamte Team über Aktualisierungen des kognitiven Modells zu informieren. Im schlimmsten Fall könnte ein solcher Ansatz die Arbeit einfach lahmlegen.
Die größte Veränderung im Anwendungsentwicklungsprozess war die Einführung der agilen Methodik. Eines der Hauptmerkmale der Methodik agile ist eine iterative Entwicklung. Dies wiederum führt zu einer Verringerung der kognitiven Belastung der Ingenieure. Anstatt vom Entwicklungsteam zu verlangen, die Anwendung in einem langen Zyklus zu implementieren, agile Mit diesem Ansatz können Sie sich auf kleine Codemengen konzentrieren, die schnell getestet und bereitgestellt werden können, und gleichzeitig Feedback erhalten. Die kognitive Belastung der App hat sich von einem sechsmonatigen auf einen zweijährigen Zeitrahmen verschoben, wobei eine große Menge an Spezifikationen für eine zweiwöchige Ergänzung oder Funktionsänderung auf ein unklareres Verständnis einer großen App abzielt.
Die Verlagerung des Fokus von einer umfangreichen Anwendung auf bestimmte kleine Funktionen, die in einem zweiwöchigen Sprint abgeschlossen werden können, wobei nicht mehr als eine Funktion vor dem nächsten Sprint im Auge behalten wird, ist eine bedeutende Änderung. Dadurch konnten wir die Entwicklungsproduktivität steigern und gleichzeitig die kognitive Belastung reduzieren, die ständig schwankte.
In der Methodik agile Die endgültige Anwendung wird voraussichtlich eine leicht modifizierte Version des ursprünglichen Konzepts sein, sodass der Endpunkt der Entwicklung zwangsläufig unklar ist. Nur die Ergebnisse jedes einzelnen Sprints können klar und präzise sein.
Kleine Codebasen
Der nächste Schritt zur Reduzierung der kognitiven Belastung besteht darin, die Codebasis zu reduzieren. Moderne Anwendungen sind in der Regel riesig – eine robuste Unternehmensanwendung kann aus Tausenden von Dateien und Hunderttausenden Codezeilen bestehen. Abhängig davon, wie die Dateien organisiert sind, können Verknüpfungen und Abhängigkeiten zwischen Code und Dateien offensichtlich sein oder umgekehrt. Sogar das Debuggen der Codeausführung selbst kann problematisch sein, abhängig von den verwendeten Bibliotheken und davon, wie gut die Debugging-Tools zwischen Bibliotheken/Paketen/Modulen und benutzerdefiniertem Code unterscheiden.
Die Erstellung eines funktionierenden mentalen Modells des Codes einer Anwendung kann beeindruckend viel Zeit in Anspruch nehmen und wiederum eine große kognitive Belastung für den Entwickler darstellen. Dies gilt insbesondere für monolithische Codebasen, bei denen es eine große Menge an Code gibt, deren Interaktion zwischen den funktionalen Komponenten nicht klar definiert ist und die Trennung der Aufmerksamkeitsobjekte oft verschwimmt, weil funktionale Grenzen nicht respektiert werden.
Eine der effektivsten Möglichkeiten, die kognitive Belastung von Ingenieuren zu reduzieren, ist der Umstieg auf eine Microservice-Architektur. Bei einem Microservice-Ansatz konzentriert sich jeder Service auf einen Satz von Funktionen. während die Bedeutung des Dienstes normalerweise definiert und verständlich ist. Auch die Grenzen eines Dienstes sind klar – denken Sie daran, dass die Kommunikation mit einem Dienst über eine API erfolgt, sodass von einem Dienst generierte Daten problemlos an einen anderen weitergegeben werden können.
Die Interaktion mit anderen Diensten ist normalerweise auf einige wenige Benutzerdienste und einige Anbieterdienste beschränkt, die einfache und saubere API-Aufrufe verwenden, beispielsweise die Verwendung von REST. Dies bedeutet, dass die kognitive Belastung des Ingenieurs erheblich reduziert wird. Die größte Herausforderung bleibt das Verständnis des Service-Interaktionsmodells und der Art und Weise, wie beispielsweise Transaktionen über mehrere Services hinweg ablaufen. Infolgedessen reduziert der Einsatz von Microservices die kognitive Belastung, indem die Codemenge reduziert, klare Servicegrenzen definiert und ein Verständnis für die Beziehung zwischen Benutzern und Anbietern bereitgestellt wird.
Kleine inkrementelle Änderungen
Das letzte Element des Prinzips Kleinheit ist Change Management. Für Entwickler ist es besonders verlockend, sich die Codebasis anzusehen (vielleicht sogar ihren eigenen, älteren Code) und zu sagen: „Das ist Mist, wir müssen alles neu schreiben.“ Manchmal ist das die richtige Entscheidung, manchmal nicht. Dadurch wird dem Entwicklungsteam die Last des globalen Modellwechsels aufgebürdet, was wiederum zu einer enormen kognitiven Belastung führt. Für Ingenieure ist es besser, sich auf die Änderungen zu konzentrieren, die sie während des Sprints vornehmen können, damit sie die erforderlichen Funktionen zeitnah, wenn auch schrittweise, einführen können. Das Endprodukt sollte dem vorab geplanten Produkt ähneln, jedoch mit einigen Modifikationen und Tests, um den Bedürfnissen des Kunden gerecht zu werden.
Beim Umschreiben großer Codeteile ist es manchmal nicht möglich, die Änderung schnell bereitzustellen, da andere Systemabhängigkeiten ins Spiel kommen. Um den Änderungsfluss zu steuern, können Sie das Ausblenden von Features nutzen. Im Prinzip bedeutet dies, dass sich die Funktionalität in der Produktion befindet, aber nicht über die Umgebungsvariableneinstellungen (env-var) oder einen anderen Konfigurationsmechanismus verfügbar ist. Wenn der Code alle Qualitätskontrollprozesse bestanden hat, landet er möglicherweise in einem latenten Zustand in der Produktion. Diese Strategie funktioniert jedoch nur, wenn die Funktion schließlich aktiviert wird. Andernfalls wird der Code nur unübersichtlich und es kommt zu einer kognitiven Belastung, mit der sich der Entwickler auseinandersetzen muss, um produktiv zu sein. Das Änderungsmanagement und die inkrementellen Änderungen selbst tragen dazu bei, die kognitive Belastung der Entwickler auf einem erschwinglichen Niveau zu halten.
Selbst bei der einfachen Einführung zusätzlicher Funktionalität müssen Ingenieure viele Schwierigkeiten überwinden. Seitens des Managements wäre es ratsam, die unnötige Belastung des Teams zu reduzieren, damit es sich auf wichtige Funktionselemente konzentrieren kann. Es gibt drei Dinge, die Sie tun können, um Ihrem Entwicklungsteam zu helfen:
- Verwenden Sie Methodik
agileum den Zeitrahmen zu begrenzen, in dem sich das Team auf Schlüsselfunktionen konzentrieren muss. - Implementieren Sie Ihre Anwendung als mehrere Microservices. Dadurch wird die Anzahl der Funktionen begrenzt, die implementiert werden können, und die Grenzen verstärkt, die die kognitive Belastung am Laufen halten.
- Bevorzugen Sie inkrementelle Änderungen gegenüber großen und unhandlichen Änderungen und ändern Sie kleine Codeteile. Verwenden Sie das Ausblenden von Funktionen, um Änderungen umzusetzen, auch wenn diese nicht sofort nach dem Hinzufügen sichtbar sind.
Wenn Sie das Prinzip der Kleinheit bei Ihrer Arbeit anwenden, wird Ihr Team viel zufriedener sein, sich besser auf die Implementierung der notwendigen Funktionen konzentrieren und qualitative Änderungen schneller umsetzen. Dies bedeutet jedoch nicht, dass die Arbeit nicht komplizierter werden kann. Im Gegenteil, die Einführung neuer Funktionen erfordert manchmal die Änderung mehrerer Dienste, und dieser Prozess kann in einer monolithischen Architektur schwieriger sein als vergleichbar. In jedem Fall lohnen sich die Vorteile des Smallness-Ansatzes.
Das Ende des ersten Teils.
Bald werden wir den zweiten Teil der Übersetzung veröffentlichen, und jetzt warten wir auf Ihre Kommentare und laden Sie dazu ein , die heute um 20.00 Uhr stattfinden wird.
Source: habr.com