9 Fragen und Antworten im Vorstellungsgespräch zur Softwarearchitektur

9 Fragen und Antworten im Vorstellungsgespräch zur Softwarearchitektur
Ein Softwarearchitekt ist ein Softwareexperte, der Designentscheidungen auf hohem Niveau trifft und technische Standards vorschreibt, einschließlich Softwarecodierungsstandards, Tools und Plattformen. Softwarearchitektur bezieht sich auf die High-Level-Strukturen eines Softwaresystems, die Disziplin der Erstellung solcher Strukturen und die Dokumentation dieser Strukturen.

F1: Was bedeutet „Programm zu Schnittstellen, nicht zu Implementierungen“?

Thema: Designmuster
Schwierigkeit: ⭐⭐⭐

Codierung gegen Schnittstelle bedeutet, dass der Client-Code immer ein Interface-Objekt enthält, das von a bereitgestellt wird Fabrik.

Jede von der Factory zurückgegebene Instanz wäre vom Typ Interface, das jede Factory-Kandidatenklasse implementiert haben muss. Auf diese Weise kümmert sich das Client-Programm nicht um die Implementierung, und die Schnittstellensignatur bestimmt, welche Operationen ausgeführt werden können.

Dieser Ansatz kann verwendet werden, um das Verhalten eines Programms zur Laufzeit zu ändern. Es hilft Ihnen auch, weitaus bessere Programme aus Wartungssicht zu schreiben.

🔗Quelle: tutorialspoint.com

F2: Was sind die Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment?

Thema: DevOps
Schwierigkeit: ⭐⭐⭐

  • Entwickler üben kontinuierliche Integration Führen Sie ihre Änderungen so oft wie möglich mit dem Hauptzweig zurück. Auf diese Weise vermeiden Sie die Integrationshölle, die normalerweise passiert, wenn Leute auf den Veröffentlichungstag warten, um ihre Änderungen in den Veröffentlichungszweig einzufügen.
  • Kontinuierliche Lieferung ist eine Erweiterung der kontinuierlichen Integration, um sicherzustellen, dass Sie neue Änderungen schnell und nachhaltig für Ihre Kunden freigeben können. Das bedeutet, dass Sie nicht nur Ihre Tests automatisiert haben, sondern auch Ihren Freigabeprozess automatisiert haben und Ihre Anwendung jederzeit per Knopfdruck bereitstellen können.
  • Kontinuierlicher Einsatz geht einen Schritt weiter als Continuous Delivery. Mit dieser Vorgehensweise wird jede Änderung, die alle Phasen Ihrer Produktionspipeline durchläuft, für Ihre Kunden freigegeben. Es gibt keinen menschlichen Eingriff, und nur ein fehlgeschlagener Test verhindert, dass eine neue Änderung in der Produktion bereitgestellt wird.

🔗Quelle: atlassian.com

F3: Wofür steht SOLID? Was sind seine Prinzipien?

Thema: Softwarearchitektur
Schwierigkeit: ⭐⭐⭐

FEST ist ein Akronym für die ersten fünf Prinzipien des objektorientierten Designs (OOD) von Robert C. Martin.

  • SPrinzip der Einzelverantwortung. Eine Klasse sollte einen und nur einen Grund haben, sich zu ändern, was bedeutet, dass eine Klasse nur einen Job haben sollte.
  • ÖAuf-Zu-Prinzip. Objekte oder Entitäten sollten für Erweiterungen offen, aber für Änderungen geschlossen sein.
  • LLiskov-Substitutionsprinzip. Sei q(x) eine Eigenschaft, die über Objekte von x vom Typ T beweisbar ist. Dann sollte q(y) für Objekte y vom Typ S beweisbar sein, wobei S ein Untertyp von T ist.
  • ichPrinzip der Schnittstellentrennung. Ein Client sollte niemals gezwungen werden, eine Schnittstelle zu implementieren, die er nicht verwendet, oder Clients sollten nicht gezwungen werden, sich auf Methoden zu verlassen, die sie nicht verwenden.
  • DAbhängigkeitsinversionsprinzip. Entitäten müssen von Abstraktionen abhängen, nicht von Konkretionen. Es besagt, dass das High-Level-Modul nicht vom Low-Level-Modul abhängen darf, aber sie sollten von Abstraktionen abhängen.

🔗Quelle: schottische.io

F4: Was ist die BASE-Eigenschaft eines Systems?

Thema: Softwarearchitektur
Schwierigkeit: ⭐⭐⭐⭐

BASE Eigenschaften sind die gemeinsamen Eigenschaften kürzlich entwickelter NoSQL-Datenbanken. Gemäß dem CAP-Theorem garantiert ein BASE-System keine Konsistenz. Dies ist ein erfundenes Akronym, das auf die folgende Eigenschaft eines Systems im Sinne des CAP-Theorems abgebildet wird:

  • Grundsätzlich vorhanden zeigt an, dass das System garantiert verfügbar ist
  • Weicher Zustandzeigt an, dass sich der Zustand des Systems im Laufe der Zeit auch ohne Eingabe ändern kann. Dies liegt vor allem am schlussendlich konsistenten Modell.
  • Endgültige Konsistenz gibt an, dass das System im Laufe der Zeit konsistent wird, da das System während dieser Zeit keine Eingaben erhält.

🔗Quelle: vondev.com

F5: Was ist das CAP-Theorem?

Thema: Softwarearchitektur
Schwierigkeit: ⭐⭐⭐⭐⭐

Das CAP-Theorem für verteiltes Rechnen wurde von Eric Brewer veröffentlicht. Darin heißt es, dass es für ein verteiltes Computersystem nicht möglich ist, gleichzeitig alle drei der folgenden Garantien zu bieten:

  1. Konsistenz (alle Knoten sehen die gleichen Daten auch gleichzeitig mit gleichzeitigen Updates)
  2. Verfügbarkeit (eine Garantie, dass jede Anfrage eine Antwort darüber erhält, ob sie erfolgreich war oder fehlgeschlagen ist)
  3. Partitionstoleranz (das System läuft trotz willkürlichem Nachrichtenverlust oder Ausfall eines Teils des Systems weiter)

Das Akronym CAP entspricht diesen 3 Garantien. Dieses Theorem hat die Grundlage für moderne verteilte Computeransätze geschaffen. Die meisten High-Volume-Traffic-Unternehmen der Welt (z. B. Amazon, Google, Facebook) verwenden dies als Entscheidungsgrundlage für ihre Anwendungsarchitektur. Es ist wichtig zu verstehen, dass nur zwei dieser drei Bedingungen garantiert von einem System erfüllt werden können.

🔗Quelle: vondev.com

F6: Sind Sie mit den Prinzipien der Zwölf-Faktoren-App vertraut?

Thema: Softwarearchitektur
Schwierigkeit: ⭐⭐⭐⭐⭐

Das Zwölf-Faktoren-App Methodik ist eine Methodik zum Erstellen von Software-as-a-Service-Anwendungen. Diese Best Practices sollen es ermöglichen, Anwendungen mit Portabilität und Ausfallsicherheit zu erstellen, wenn sie im Web bereitgestellt werden.

  • Codebasis – Es sollte genau eine Codebasis für einen bereitgestellten Dienst geben, wobei die Codebasis für viele Bereitstellungen verwendet wird.
  • Abhängigkeiten – Alle Abhängigkeiten sollten ohne implizite Abhängigkeit von Systemtools oder Bibliotheken deklariert werden.
  • Konfig – Konfigurationen, die zwischen Bereitstellungen variieren, sollten in der Umgebung gespeichert werden.
  • Backing-Services Alle unterstützenden Dienste werden als angehängte Ressourcen behandelt und von der Ausführungsumgebung angehängt und getrennt.
  • Erstellen, veröffentlichen, ausführen – Die Delivery-Pipeline sollte strikt aus Build, Release, Run bestehen.
  • Prozesse – Anwendungen sollten als ein oder mehrere zustandslose Prozesse bereitgestellt werden, wobei persistente Daten auf einem Sicherungsdienst gespeichert werden.
  • Port-Bindung – In sich geschlossene Dienste sollten sich über bestimmte Ports anderen Diensten zur Verfügung stellen.
  • Parallelität – Nebenläufigkeit wird durch die Skalierung einzelner Prozesse befürwortet.
  • Verfügbarkeit – Schnelles Hoch- und Herunterfahren wird für ein robusteres und widerstandsfähigeres System empfohlen.
  • Dev/Prod-Parität – Alle Umgebungen sollten möglichst ähnlich sein.
  • Protokolle – Anwendungen sollten Protokolle als Ereignisströme erzeugen und die Ausführungsumgebung zur Aggregation überlassen.
  • Verwaltungsprozesse – Alle erforderlichen Verwaltungsaufgaben sollten in der Quellcodeverwaltung aufbewahrt und mit der Anwendung gepackt werden.

🔗Quelle: 12factor.net

F7: Was sind heuristische Ausnahmen?

Thema: Softwarearchitektur
Schwierigkeit: ⭐⭐⭐⭐⭐

Eine heuristische Ausnahme bezieht sich auf die Entscheidung eines Transaktionsteilnehmers, einseitig Maßnahmen ohne Zustimmung des Transaktionsmanagers zu ergreifen, normalerweise als Ergebnis eines katastrophalen Ausfalls zwischen dem Teilnehmer und dem Transaktionsmanager.

In einer verteilten Umgebung können Kommunikationsfehler auftreten. Wenn die Kommunikation zwischen dem Transaktionsmanager und einer wiederherstellbaren Ressource für einen längeren Zeitraum nicht möglich ist, kann die wiederherstellbare Ressource entscheiden, Änderungen, die im Zusammenhang mit einer Transaktion vorgenommen wurden, einseitig festzuschreiben oder rückgängig zu machen. Eine solche Entscheidung wird als heuristische Entscheidung bezeichnet. Dies ist einer der schlimmsten Fehler, die in einem Transaktionssystem auftreten können, da er dazu führen kann, dass Teile der Transaktion festgeschrieben werden, während andere Teile zurückgesetzt werden, wodurch die Atomizitätseigenschaft der Transaktion verletzt wird und möglicherweise zu einer Beschädigung der Datenintegrität führt.

Wegen der Gefahren von heuristische Ausnahmen, muss eine wiederherstellbare Ressource, die eine heuristische Entscheidung trifft, alle Informationen über die Entscheidung im stabilen Speicher halten, bis der Transaktionsmanager ihr sagt, dass sie die heuristische Entscheidung vergessen soll. Die tatsächlichen Daten über die heuristische Entscheidung, die im stabilen Speicher gespeichert werden, hängen von der Art der wiederherstellbaren Ressource ab und sind nicht standardisiert. Die Idee ist, dass ein Systemmanager sich die Daten ansehen und möglicherweise die Ressource bearbeiten kann, um Datenintegritätsprobleme zu beheben.

🔗Quelle: jboss.org

F8: Was ist eine Shared-Nothing-Architektur? Wie skaliert es?

Thema: Softwarearchitektur
Schwierigkeit: ⭐⭐⭐⭐⭐

Eine Shared-Nothing-Architektur (SN) ist ein verteilter Computing-Ansatz, bei dem jeder Knoten unabhängig und autark ist und kein einzelner Konfliktpunkt im gesamten System erforderlich ist.

  • Das bedeutet, dass keine Ressourcen zwischen Knoten geteilt werden (kein gemeinsamer Speicher, kein gemeinsamer Dateispeicher)
  • Die Knoten können unabhängig voneinander arbeiten, ohne bei der Arbeit voneinander abhängig zu sein.
  • Der Ausfall eines Knotens wirkt sich nur auf die Benutzer dieses Knotens aus, andere Knoten arbeiten jedoch ohne Unterbrechung weiter.

Dieser Ansatz ist hochgradig skalierbar, da er das Vorhandensein eines einzelnen Engpasses im System vermeidet. Shared Nothing ist in letzter Zeit aufgrund seiner linearen Skalierbarkeit für die Webentwicklung populär geworden. Google verwendet es seit langem.

Theoretisch kann ein Shared-Nothing-System fast unendlich skalieren, indem einfach Knoten in Form von kostengünstigen Maschinen hinzugefügt werden.

🔗Quelle: vondev.com

F9: Was bedeutet „Endgültig konsistent“?

Thema: Softwarearchitektur
Schwierigkeit: ⭐⭐⭐⭐⭐

Im Gegensatz zur relationalen Datenbankeigenschaft Strikte Konsistenz eventuelle Konsistenz Die Eigenschaft eines Systems stellt sicher, dass jede Transaktion die Datenbank schließlich (nicht sofort) von einem gültigen Zustand in einen anderen bringt. Dies bedeutet, dass es Zwischenzustände geben kann, die zwischen mehreren Knoten nicht konsistent sind.

Eventuell konsistente Systeme sind in Szenarien nützlich, in denen absolute Konsistenz nicht kritisch ist. Wenn beispielsweise im Falle einer Twitter-Statusaktualisierung einige Benutzer des Systems nicht den neuesten Status eines bestimmten Benutzers sehen, ist dies möglicherweise nicht sehr verheerend für das System.

Endgültig konsistente Systeme können nicht für Anwendungsfälle verwendet werden, in denen absolute/strikte Konsistenz erforderlich ist. Beispielsweise kann ein Banktransaktionssystem keine Eventual Consistency verwenden, da es zu jedem Zeitpunkt konsistent über den Status einer Transaktion verfügen muss. Ihr Kontostand sollte keine unterschiedlichen Beträge anzeigen, wenn Sie von verschiedenen Geldautomaten darauf zugreifen.

🔗Quelle: vondev.com

Danke 🙌 fürs Lesen und viel Glück bei deinem Vorstellungsgespräch!
Weitere Fragen und Antworten zu FullStack-Interviews finden Sie unter 👉 www.fullstack.cafe

Similar Posts

Leave a Reply

Your email address will not be published.