|
|
Criado por Daniel Eberwein
mais de 10 anos atrás
|
|
| Questão | Responda |
| 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 |
Quer criar seus próprios Flashcards gratuitos com GoConqr? Saiba mais.