![]() |
Created by Daniel Eberwein
over 8 years ago
|
|
Question | Answer |
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 |
Want to create your own Flashcards for free with GoConqr? Learn more.