Software Architektur

Pregunta	Respuesta
Refactoring - Probleme	- Code wird nach und nach ergänzt - Code wird schwer lesbar und ist nicht mehr wiederverwendbar - Code wird schwer verstehbar - Design verwässert
Refactoring - Vorteile	- Struktur wird wieder angepasst - erhöhte Wiederverwendbarkeit - Code wird verständlicher - leichtere Lesbarkeit
Refactoring - Was sollte beachtet werden?	- Intention des Codes sollte nachvollzogen und beibehalten werden - Verhalten muss beibehalten werden - keine Änderungen an Schnittstellen nach außen - Absicherung durch Tests
Refactoring - Wann durchführen?	- bei Code Reviews - bei Erweiterungen - bei Fehlern - Three Strikes and you refactor!
Duplicate Code	zwei oder mehr Stellen sind sehr ähnlich oder gleich oder haben die gleiche Funktionalität --> Wartungsarbeiten müssen immer an mehreren Stellen gemacht werden Lösung: Extract Method oder Extract Superclass
Long Method	- Methode hat zu viele Lines of Code - Methode erfüllt oftmals viele Funktionen Lösung: Extract Method
Dead Code	- Codebestandteile, die nicht mehr verwendet werden, sollten gelöscht werden - werden i.d.R. von der IDE erkannt - vor dem Löschen sollen Abhängigkeiten und Zusammenhänge geprüft werden
Ruby - Eigenschaften	- interpretiert - objektorientiert - dynamisch typisiert - Skriptsprache - Ducktyping - schlecht skalierbar - macht den Programmierer effizient - viele Bibliotheken und Plug-Ins
Ruby - Einsatzgebiete	- Webentwicklung mit Rails: wenig Konfiguration notwendig, Struktur immer konsistent, Änderung am Model werden direkt in die DB übertragen - Schnelle Produkteinführung: viele Plugins vorhanden
Ruby - Unterschiede zu Java	- keine Kompilierung - keine statische Typprüfung - keine Typumwandlung - Schlüsselwörter statt geschweiften Klammern - nil statt null - self statt this
Ruby - Auswirkungen auf die Architketur	+ Webanwendungen + schnelle Entwicklung - schlechte Laufzeitoptimierung - schlechte Unterstützung bei Nebenläufigkeit - keine Hardwareprogrammierung möglich
Verteilte Anwendungen - Eigenschaften	- mehrere Einzelkomponenten auf unterschiedlichen Rechnern - keine gemeinsame Datenbank - gemeinsames Ziel - Kommunikation mittels Nachrichtenaustausch
SOA	- dominierendes Paradigma für Umsetzung verteilter Systeme - Web Services als Basiskonzept - Anbieten von Funktionen über wohldefinierte Schnittstellen
SOA - statuslose Interaktionen	- Server & Client vergessen nach einer Sitzung wieder alles - bessere Skalierbarkeit - Speicheranforderungen sind geringer - parallele Verarbeitung - dynamische Reorganisation von Services
REST - Vor- und Nachteile	+ schlanke Architektur + baut auf verbreiteten Techniken auf (HTTP) + sehr populär - viel Arbeit verbleibt beim Nutzer - keine explizite Semantik und daher unterschiedliche Anwendungen
Microservices - Allgemein	- viele kleine Dienste statt weniger großer - Kommunikation über Web Protokolle - jeder Microservice hat sein eigenes Paket
Microservices - Pakete	- UI - API - Business Logik - Datenzugriffslogik - Datenbank
Microservices - technische Vorteile	- Komponenten können für sich betrieben, weiterentwickelt oder skaliert werden - hohe Flexibilität - erhöhte Ausfallsicherheit des Gesamtsystems
Microservices - Erfolgsfaktoren für den Entwurf	- Nanoservices vermeiden - Single Responsibility Principle verinnerlichen - Kommunikation zwischen Diensten minimieren - mit Ausfällen rechnen - asynchrone Kommunikation verwenden
Microservices - Erfolgsfaktoren in der Entwicklung	- schnelles Deployment - auf Ausfälle testen
Microservices - Zusammenfassung	- partielles und schnelles Deployment - hohe Verfügbarkeit des Gesamtsystems - eventuelle Inkonsistenzen der jeweiligen DB - nicht verwenden, wenn Datenkonsistenz wichtig, Ausfallsicherheit gegeben sein soll, oder die Software an Kunden verteilt wird

Siguiente

Descripción

Resumen del Recurso

Similar

	Creado por Daniel Eberwein hace alrededor de 8 años