Was ist die Ursache-Wirkungs-Graph-Analyse?

Bei der Ursache-Wirkungs-Graph-Analyse handelt es sich um eine visuelle Darstellungsform, die hilft, komplexe Zusammenhänge zwischen unterschiedlichen Faktoren zu verstehen. Mit Hilfe von Knoten und Verbindungen lassen sich Ursachen und ihre jeweiligen Auswirkungen grafisch abbilden. So kann man nicht nur isolierte Einzelfaktoren betrachten, sondern auch die Wechselwirkungen und Abhängigkeiten zwischen mehreren Faktoren.

Geschichte der Ursache-Wirkungs-Graph-Analyse

Die Idee, komplexe Zusammenhänge grafisch darzustellen, reicht weit zurück. Bereits in der Antike nutzten Philosophen Diagramme, um logische Schlüsse zu ziehen. Doch die moderne Form der Ursache-Wirkungs-Graph-Analyse, insbesondere das Ursache-Wirkungs-Diagramm, erlebte in den 1940er Jahren eine bedeutende Weiterentwicklung durch den japanischen Wissenschaftler Kaoru Ishikawa. Dieses nach ihm benannte Ishikawa-Diagramm diente ursprünglich im Qualitätsmanagement zur Analyse von Qualitätsproblemen und deren Ursachen. Schnell erkannte man jedoch das Potenzial dieses Ansatzes und übertrug ihn auf andere Problemfelder. So fand das Ishikawa-Diagramm weltweite Verbreitung und dient heute in vielfältigen Bereichen als Tool zur Analyse und Problemlösung.

Wie geht man am besten vor?

1. Identifizierung der Hauptursachen: Bevor man einen Graphen erstellt, identifiziert man die Hauptursachen oder Faktoren, die das zu analysierende System beeinflussen.
2. Bestimmung der Wirkungen: Jede Ursache hat eine oder mehrere Wirkungen. Diese muss man identifiziert und im Graphen dargestellt werden.
3. Erstellung des Graphen: Mit Hilfe von speziellen Software-Tools oder auch einfach per Hand zeichnet man die Ursachen und Wirkungen in Form von Knoten und verbindet sie durch Pfeile, die die Beziehungen anzeigen.
4. Analyse des Graphen: Nach der Erstellung des Graphen analysiert man die Wechselwirkungen und Abhängigkeiten, um Schlussfolgerungen zu ziehen oder Lösungsansätze zu entwickeln.

Beispiele für den Einsatz der Ursache-Wirkungs-Graph-Analyse

• Umweltforschung: Bei der Untersuchung von Ökosystemen kann die Analyse helfen, die Auswirkungen menschlicher Eingriffe oder natürlicher Veränderungen zu verstehen.
• Produktentwicklung: In der Industrie lassen sich mit der Analyse mögliche Probleme in der Fertigung oder im Design identifizieren.
• Gesundheitswesen: Ärzte und Forscher nutzen die Methode, um die Wechselwirkungen zwischen verschiedenen Krankheitsursachen und Symptomen besser zu verstehen.
• Wirtschaftsforschung: In der Wirtschaft können Unternehmen die Analyse nutzen, um Marktveränderungen, Kundennachfrage oder Risikofaktoren zu analysieren.

Welche Software eignet sich dafür?

1. Microsoft Visio: Ein weit verbreitetes Tool für Diagramme und Grafiken. Es bietet verschiedene Vorlagen, einschließlich des Ishikawa-Diagramms.
2. Lucidchart: Ein cloudbasiertes Diagramm-Tool, das viele Vorlagen und Integrationen bietet und sich gut für kollaborative Arbeiten eignet.
3. MindManager: Ursprünglich ein Mind-Mapping-Tool, das sich aber auch gut für die Erstellung von Ursache-Wirkungs-Diagrammen eignet.
4. SmartDraw: Ein weiteres Diagramm-Tool mit einer großen Auswahl an Vorlagen.
5. Draw.io (jetzt bekannt als diagrams.net): Ein kostenloses, webbasiertes Tool zur Diagrammerstellung, das auch Vorlagen für Ursache-Wirkungs-Diagramme bereithält.
6. Miro: Ein Online-Whiteboard-Tool, das verschiedene Diagramm-Vorlagen bietet und besonders für Teamarbeit und Brainstorming geeignet ist.

Diese Tools bieten nicht nur Vorlagen für Ursache-Wirkungs-Diagramme, sondern unterstützen auch eine Vielzahl anderer Diagrammtypen und haben oft Kollaborationsfunktionen, sodass Teams in Echtzeit daran arbeiten können.

Fazit

Zusammenfassend bietet die Ursache-Wirkungs-Graph-Analyse ein mächtiges Werkzeug, um komplexe Systeme zu verstehen und fundierte Entscheidungen zu treffen. Mit ihrer Hilfe lassen sich nicht nur Probleme identifizieren, sondern auch Lösungen entwickeln und Potenziale ausschöpfen.

Der Beitrag Ursache-Wirkungs-Graph-Analyse – Verstehen durch Vernetzen erschien zuerst auf CEOsBay.

Was ist Domain Driven Design?

Domain Driven Design ist ein Ansatz zur Softwareentwicklung, der den Fokus auf die Geschäftslogik und -struktur legt, die in der sogenannten „Domäne“ existieren. Es konzentriert sich darauf, ein tieferes Verständnis des Problembereichs und der Geschäftsanforderungen zu erlangen, bevor es auf die technischen Aspekte eingeht. Das primäre Ziel ist, die Komplexität durch die Modellierung einer Software um das Herzstück der realen Weltprobleme zu bewältigen.

Die Entstehung von Domain Driven Design

Domain Driven Design wurde von Eric Evans in seinem Buch „Domain-Driven Design: Tackling Complexity in the Heart of Software“ im Jahr 2003 vorgestellt. Evans hat die Grundlagen und Prinzipien von DDD detailliert beschrieben und dabei den Fokus auf die Zusammenarbeit zwischen technischen Experten und Domänenexperten gelegt.

Wie lässt es sich umsetzen?

Die Implementierung kann in vier Hauptschritten erfolgen:

1. Ubiquitous Language: Dies ist eine gemeinsame Sprache, die von allen Teammitgliedern genutzt wird, um Missverständnisse zwischen den technischen Mitgliedern und den Domänenexperten zu vermeiden. Diese gemeinsame Sprache wird sowohl im Code als auch in den Gesprächen verwendet.
2. Model Driven Design: Hier erstellt man ein Modell oder eine Darstellung der Domäne. Dieses Modell verwendet man, um das System zu entwerfen und zu implementieren. Es hilft, das Verständnis und die Kommunikation zwischen allen Teammitgliedern zu verbessern.
3. Bounded Context: Hierbei handelt es sich um die Grenze oder den Bereich, in dem ein bestimmtes Modell gilt. Durch die Definition von Bounded Contexts kann man die Komplexität des Systems reduzieren und das Verständnis der Domäne verbessern.
4. Context Mapping: Dies ist der Prozess, in dem man die Beziehungen und Interaktionen zwischen verschiedenen Bounded Contexts definiert und ein gewisses Verständnis dafür entwickelt.

Was ist bei der Umsetzung zu beachten?

Es ist wichtig, einige Schlüsselelemente im Auge zu behalten, um eine erfolgreiche Umsetzung von Domain Driven Design zu gewährleisten. Ein gründliches Verständnis der Geschäftsdomäne ist entscheidend. Außerdem ist die Zusammenarbeit zwischen den Domänenexperten und den technischen Experten von großer Bedeutung.

Fazit

Domain Driven Design ist ein wirkungsvolles Werkzeug zur Bewältigung von Komplexität in Softwareprojekten. Es bietet einen strukturierten Ansatz zur Modellierung der Geschäftslogik und zur Entwicklung von robusten, wartbaren Softwarelösungen. Durch eine engagierte Zusammenarbeit und den Aufbau eines gemeinsamen Verständnisses der Domäne kann DDD dazu beitragen, die Herausforderungen in der Softwareentwicklung effektiv zu meistern.

Obwohl Domain Driven Design in komplexen Projekten viele Vorteile bietet, sind damit auch Herausforderungen verbunden. DDD ist ein komplexer Ansatz, der ein tiefgehendes Verständnis der Geschäftsdomäne und technisches Know-how erfordert, was bei neuen Teams zu Schwierigkeiten führen kann. Der Initialaufwand, ein geteiltes Modell der Domäne zu erstellen und effektive Kommunikationskanäle einzurichten, kann zeit- und ressourcenintensiv sein. Es ist am effektivsten in großen, komplexen Projekten, aber für kleinere, weniger komplexe Projekte kann es ineffizient sein. Die Skalierung in großen Organisationen und die Koordination verschiedener Bounded Contexts kann zu Herausforderungen führen. Zudem erfordert es ein hohes Maß an Zusammenarbeit und Verständnis unter allen Teammitgliedern, was in einigen Teams schwer zu erreichen sein könnte. Die Erstellung einer Ubiquitous Language kann aufgrund von Kommunikationsbarrieren in vielfältigen Teams ebenfalls eine Herausforderung darstellen.

Der Beitrag Domain Driven Design (DDD) – Die Kunst der Softwarearchitektur erschien zuerst auf CEOsBay.

Was ist Clean Code?

Clean Code bezieht sich auf den Ansatz, Code so zu schreiben, dass er leicht verständlich, wartbar und erweiterbar ist. Das Konzept wurde von Robert C. Martin, auch bekannt als „Uncle Bob“, in seinem Buch „Clean Code: A Handbook of Agile Software Craftsmanship“ populär gemacht. Im Kern geht es darum, Softwareentwicklung als Handwerk zu betrachten und stets auf hohe Qualität und Präzision in der Codegestaltung zu achten.

Warum ist es wichtig?

Sauberer Code bietet verschiedene Vorteile, sowohl für den Entwickler selbst, für das gesamte Team und meiner Meinung nach auch für die ganze Welt.

• Verständlichkeit: Clean Code ist einfacher zu lesen und zu verstehen. Das hilft Entwicklern, sich schneller mit dem Code vertraut zu machen und Fehler oder Verbesserungsmöglichkeiten schneller zu erkennen.
• Wartbarkeit: Sauberer Code ist leichter zu warten, da er klar strukturiert und weniger anfällig für Fehler oder unerwartete Probleme ist.
• Effizienz: Da Clean Code einfacher zu verstehen ist, kann das Team schneller arbeiten und die Produktivität steigt.
• Zusammenarbeit: Ein sauberer Code erleichtert die Zusammenarbeit im Team, da jeder den Code anderer Entwickler leichter lesen und verstehen kann.

Prinzipien von Clean Code

Es gibt viele Prinzipien und Praktiken, die beim Schreiben von sauberem Code helfen können. Einige der wichtigsten sind:

• Lesbarkeit: Der Code sollte leicht lesbar und verständlich sein. Das bedeutet, dass man Variablen, Funktionen und Klassen sinnvoll benamt und ihre Funktion leicht erkennbar ist. Kommentare setzt man sparsam ein, um den Code nicht zu überfrachten.

• Einfachheit: Man hält den Code so einfach wie möglich, ohne unnötige Komplexität oder Verwirrung. Das bedeutet, dass man sich auf das Wesentliche konzentrieren und abstrakte Konzepte wie Design Patterns oder Funktionen nur verwendet, wenn sie tatsächlich nützlich sind.

• Modularität: Man teilt den Code in kleine unabhängige Module auf, die jeweils eine bestimmte Funktion erfüllen. Dadurch wird der Code leichter zu verstehen und zu warten.

• Wiederverwendbarkeit: Man schreibt den Code so, dass die Wiederverwendbarkeit gewährleistet ist. Dies bedeutet, dass Funktionen oder Klassen, die eine bestimmte Aufgabe erfüllen, generisch genug sind, um in verschiedenen Situationen Verwendung zu finden.

Clean Code in der Praxis

Hier sind einige konkrete Schritte, die man beim Schreiben von Clean Code in der Praxis beachten sollte:

• Variablen-, Funktions- und Klassennamen: Man wählt sinnvolle, beschreibende Namen, die klar machen, was eine Variable, Funktion oder Klasse macht. Die Vermeidung von Abkürzungen oder unverständliche Namen ist eines der obersten Gebote.

• Single Responsibility Principle (SRP): Jede Funktion oder Klasse sollte nur eine einzige Verantwortung haben. Dies bedeutet, dass sie nur einen Aspekt des Problems lösen sollte, um den Code einfacher und leichter zu warten.

• Funktionen und Methoden: Man hält Funktionen und Methoden kurz und konzentrieren sich darauf, dass sie eine einzige Aufgabe erfüllen. Eine Funktion oder Methode sollte in der Regel nicht länger als 20 Zeilen sein, um ihre Verständlichkeit zu gewährleisten.

• KISS (Keep It Simple, Stupid) Prinzip: Man versucht, den Code so einfach wie möglich zu halten und unnötige Komplexität zu vermeiden. Wenn es eine einfachere Lösung gibt, zieht man diese der komplexeren vor.

• Don’t Repeat Yourself (DRY) Prinzip: Man vermeidet doppelten Code, indem man wiederverwendbare Funktionen oder Klassen erstellt. Das verringert die Wahrscheinlichkeit von Fehlern und macht den Code leichter zu warten.

• Code-Kommentare: Man sollte Kommentare dazu verwenden, den Zweck und die Funktionsweise von Code-Teilen zu erläutern, die nicht sofort offensichtlich sind. Man sollte jedoch nicht zu viele Kommentare schreiben, da dies den Code unübersichtlich machen kann.

• Fehlerbehandlung: Die Implementierung einer angemessenen Fehlerbehandlung sollte unabdingbar sein, um unerwartete Probleme zu erkennen und angemessen darauf zu reagieren. Die Verwendung von Exceptions und try-catch-Blöcken, kann eine gute Lösung darstellen, um Fehler abzufangen und entsprechend darauf zu reagieren.

• Testgetriebene Entwicklung (TDD): Man schreibt zuerst Tests, bevor man den eigentlichen Code entwickelt. Auf diese Weise kann man sicherstellen, dass die Implementierung den gewünschten Anforderungen entspricht und weniger fehleranfällig ist. Siehe hierzu meinen Beitrag über Test Driven Development.

• Kontinuierliche Integration (CI) und Continuous Deployment (CD): Man verwendet CI/CD-Tools, um den Code regelmäßig zu testen und automatisch zu deployen. Dies stellt sicher, dass der Code immer auf dem neuesten Stand ist und das man potenzielle Probleme schnell erkennen kann.

Fazit

Im Grunde genommen ist dies für mich eine relativ neue Angelegenheit, da ich in der Vergangenheit schon recht of den Code einfach reingehackt habe, da ich mich unter Zeitdruck gefühlt habe. Ich ertappe mich hin und wieder immer noch dabei und dies sehr oft, wie ich auf alte Gewohnheiten und Muster zurückgreife. Doch dies sollte sich hoffentlich in den nächsten Monaten und Jahren auf ein Minimum reduzieren lassen. Ich bin davon überzeugt, dass Clean Code ein wesentlicher Bestandteil einer erfolgreichen Softwareentwicklung ist. Indem man sich auf Lesbarkeit, Einfachheit, Modularität und Wiederverwendbarkeit konzentriert, kann man den eigenen Code nicht nur leichter verstehen, sondern auch schneller und effizienter arbeiten. Durch die Anwendung der oben genannten Prinzipien und Praktiken kann man den Code verbessern und letztendlich zu erfolgreichen, wartungsfreundlichen Softwareprodukten beitragen.

Der Beitrag Clean Code – Elegante Lösungen für effiziente und wartungsfreundliche Software erschien zuerst auf CEOsBay.

Definition

Der Begriff wurde zum ersten Mal in einer Arbeit von Ralph Johnson und William Opdyke 1990 gebraucht (Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In: Proceedings of Symposion on Object-Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990). Opdyke promovierte 1992 zu dem Thema. Sie entwickelten die Idee einer Software-Refactory, die das Umgestalten (eben das Refactoring) von Computerprogrammen erleichtern sollte. Die unzutreffende Übersetzung Refaktorisierung stammt aus einer Verwechslung mit einer häufig zitierten Analogie, die ursprünglich nicht Begriffsinhalt war: Refactoring ist eine Art, ein Programm so zu modifizieren, dass man verborgene Strukturen offenlegt, ohne die Funktionalität zu ändern. Dies, so der (fälschliche) Analogieschluss, entspreche dem Vorgehen der Faktorisierung von Polynomen in der Mathematik. Bin aber kein Mathematiker 😉

Warum ist Refactoring wichtig?

• Verbesserung der Code-Lesbarkeit: Lesbarkeit ist entscheidend, um den Code effizient zu warten und zu erweitern. Durch das Refactoring können Entwickler den Code vereinfachen, Duplikate entfernen und konsistente Benennungen und Formatierungen verwenden, um die Lesbarkeit zu verbessern.
• Reduzierung der technischen Schulden: Technische Schulden entstehen, wenn man die Software in Eile entwickelt, ohne auf Qualitätsstandards zu achten. Sie führen oft zu schwer zu wartendem und unzuverlässigem Code. Es hilft, technische Schulden zu reduzieren und verhindert, dass sie sich im Laufe der Zeit anhäufen.
• Optimierung der Code-Wartbarkeit: Refactoring hilft dabei, den Code modular und gut strukturiert zu halten, was die Wartung und Fehlerbehebung erleichtern kann.
• Verbesserung der Code-Performance: Durch das Entfernen von unnötigem Code und die Optimierung von Algorithmen kann Refactoring dazu beitragen, die Performance der Software zu steigern.
• Erleichterung der Teamarbeit: Ein sauberer und gut strukturierter Code ist leichter zu verstehen und ermöglicht eine effektivere Zusammenarbeit zwischen Entwicklern.

Strategien für effektives Refactoring

• Code Smells identifizieren: „Code Smells“ sind Anzeichen dafür, dass man den Code möglicherweise verbessern muss. Beispiele sind lange Methoden, große Klassen, doppelter Code und unklare Benennungen. Entwickler sollten diese Anzeichen erkennen und entsprechende Maßnahmen ergreifen, um den Code zu verbessern.
• Schrittweise Verbesserungen vornehmen: Refactoring sollte schrittweise erfolgen, um den Code schrittweise zu verbessern und gleichzeitig die Funktionalität intakt zu halten.
• Automatisierte Tests verwenden: Um sicherzustellen, dass die Funktionalität nach dem Refactoring unverändert bleibt, ist es entscheidend, automatisierte Tests zu verwenden. Dies stellt sicher, dass Änderungen am Code keine unerwünschten Nebenwirkungen verursachen.
• Konsistente Coding-Standards einhalten: Ein konsistenter Codierungsstil erleichtert das Lesen und Verstehen des Codes. Es ist wichtig, dass das gesamte Team die gleichen Standards einhält, um Inkonsistenzen zu vermeiden.
• Regelmäßiges Refactoring betreiben: Man Refactoring als fortlaufenden Prozess betrachten, der in die tägliche Arbeit eines Entwicklers integriert ist. Regelmäßiges Refactoring hilft dabei, den Code kontinuierlich sauber und auf dem neuesten Stand zu halten, wodurch man die langfristige Wartbarkeit der Software verbessern kann. Außerdem hilft es dabei, den Code zu besser verstehen und tiefere Erkenntnisse über das Programmieren selbst zu erhalten.

Beliebte Refactoring-Techniken

1. Extract Method: Wenn eine Methode zu lang oder zu komplex ist, kann sie in kleinere, gut definierte Methoden aufgeteilt werden, um die Lesbarkeit und Wartbarkeit des Codes zu verbessern.
2. Rename Variable/Method/Class: Durch das Umbenennen von Variablen, Methoden und Klassen in klarere und aussagekräftigere Namen kann man den Code verständlicher und leichter pflegbar machen.
3. Remove Duplication: Duplikate im Code können Wartungsprobleme verursachen und man sollte sie entfernen. Bei der Erkennung von Duplikaten können Entwickler allgemeine Funktionen extrahieren und wiederverwenden, um den Code zu straffen.
4. Replace Conditional with Polymorphism: Anstatt mehrere bedingte Anweisungen zu verwenden, kann man Polymorphismus eingesetzen, um den Code besser zu strukturieren und die Lesbarkeit zu erhöhen.
5. Encapsulate Field: Durch das Kapseln von Feldern in Klassen und die Bereitstellung von Zugriffs- und Mutationsmethoden kann man den Code modularer und besser wartbar machen.

Tools und Programme

Es gibt eine Vielzahl von Tools und Programmen, die Entwicklern beim Refactoring helfen. Nachfolgend sind einige der gängigsten Tools für verschiedene Programmiersprachen (Einige davon habe ich bereits in diversen Beiträgen thematisiert. Hierzu einfach auf die jeweiligen Verlinkungen klicken oder die Suchfunktion verwenden 😉 ):

Integrated Development Environments (IDEs): Viele moderne IDEs bieten integrierte Refactoring-Unterstützung für verschiedene Programmiersprachen an. Einige der bekanntesten sind:

a. JetBrains IntelliJ IDEA (Java, Kotlin, Scala, u.a.)

b. JetBrains PhpStorm (PHP)

c. JetBrains PyCharm (Python)

d. JetBrains ReSharper (C# in Visual Studio)

e. Microsoft Visual Studio (C#, C++, VB.NET)

f. Eclipse (Java)

g. Xcode (Swift, Objective-C)

Standalone-Tools: Es gibt auch eigenständige Refactoring-Tools, die man unabhängig von der IDE verwenden kann. Einige Beispiele sind:

a. JDeodorant (Java)

b. SonarLint und SonarQube (Java, JavaScript, TypeScript, u.a.)

c. JSLint und ESLint (JavaScript)

d. RuboCop (Ruby)

e. Clang-Tidy (C++, Objective-C)

Code-Editor-Erweiterungen: Viele Code-Editoren, wie Visual Studio Code und Sublime Text, verfügen über Erweiterungen, die Refactoring-Unterstützung für verschiedene Programmiersprachen bieten. Einige dieser Erweiterungen sind:

a. Visual Studio Code Refactoring Extensions (z.B. Python, JavaScript, TypeScript, PHP, Ruby, C#)

b. Sublime Text Refactoring Plugins (z.B. Anaconda für Python, JsPrettier für JavaScript)

Es ist wichtig zu beachten, dass jedes Tool seine eigenen Stärken und Schwächen hat. Ein Entwickler sollte die verfügbaren Optionen für seine Programmiersprache und seinen Arbeitsablauf sorgfältig prüfen, um das am besten geeignete Refactoring-Tool zu finden.

Fazit

Refactoring ist ein wesentlicher Bestandteil des Softwareentwicklungsprozesses, der es ermöglicht, den Code sauber, lesbar und wartbar zu halten. Durch das Identifizieren von „Code Smells“, die Anwendung bewährter Techniken und das kontinuierliche Integrieren von Refactoring in den Arbeitsablauf können Entwickler qualitativ hochwertigen Code schreiben, der leicht zu verstehen und zu erweitern ist.

Die Investition in regelmäßiges Refactoring zahlt sich langfristig aus, indem sie dazu beiträgt, die technischen Schulden zu reduzieren und die Zusammenarbeit im Team zu verbessern. Der Schlüssel zum erfolgreichen Refactoring liegt in der Kombination aus automatisierten Tests, konsistenten Codierungsstandards und einem proaktiven Ansatz zur Code-Optimierung. Durch die Priorisierung von Refactoring in der Softwareentwicklung können Entwickler sicherstellen, dass ihre Projekte skalierbar und zukunftssicher sind.

Der Beitrag Refactoring – Optimierung und Evolution für nachhaltigen Code erschien zuerst auf CEOsBay.

Seit 2009 ist es ein Open-Source-Projekt, dass auf gute Testbarkeit ausgelegt ist (An dieser Stelle möchte ich auf den Test Driven Development Beitrag verweisen 😉 ). Dies bietet ein MVC/MVVM-Framework, welches bidirektionales Databinding unterstützt.

MVC/MVVM?

MVVM teilt die verschiedenen Komponenten des Entwicklungsprozesses in drei Kategorien auf. Model, View und ViewModel. In der Regel handelt es sich dabei um Code-Markup oder grafische Benutzeroberflächen (GUI). MVC (Model-View-Control) ist eine Methode, mit der Entwickler Programme in diese drei Komponenten aufteilen. Auf diese Weise lassen sich geschäftliche Anforderungen und Regeln von der Art und Weise unterscheiden, wie Benutzer mit der Anwendung arbeiten. Gerne gehe ich in einem zukünftigen Beitrag näher darauf ein.

Unterschiede zwischen Angular und AngularJS

Angular ist wie bereits erwähnt der Nachfolger von AngularJS. Von Grund auf neu geschrieben, unterscheiden die beiden sich grundsätzlich und in vielerlei Hinsicht.

• Angular kennt keine „scopes“ oder Controller, sondern verwendet eine Hierarchie von Komponenten als zentrales Architekturkonzept.
• Angular hat eine einfachere Syntax für Ausdrücke: Mit „[ ]“ werden Bindings für Eigenschaften und mit „( )“ werden Bindings für Events erzeugt.
• Mobile-First-Ansatz: Die Anforderungen von mobilen Plattformen haben besondere Priorität.
• Modularität: Module können Funktionalitäten auslagern, sodass Code leichtgewichtiger und schneller sein kann.
• Es liegt lediglich die Unterstützung moderner Browser vor, wodurch man weniger Workarounds wegen Browser-Kompatibilitätsproblemen benötigt.
• Angular empfiehlt die Verwendung von TypeScript. Es bietet Klassenbasierte objektorientierte Programmierung, Statische Typisierung und Generics.
• TypeScript ist eine Obermenge von ECMAScript 6 (ES6) und ist rückwärts kompatibel mit ECMAScript 5, damit JavaScript. Angular bietet somit auch die Vorzüge von ES6: (Lambdas, Iteratoren, for…of-Schleifen, Generatoren im Stil von Python, Reflexion)
• Verbesserte Dependency Injection: Bindings ermöglichen die Benennung von Abhängigkeiten.
• Directives dienen dem Zweck, dass Aussehen und Verhalten eines Tags dynamisch zu verändern.
• Dynamisches Laden ist möglich
• Asynchrone Kompilierung von Templates
• Einfacheres Routing
• Kontroller und $scope sind durch Komponenten und Directives ersetzt. Eine Komponente ist eine Directive mit einem Template.
• Reaktive Programmierung mit RxJS

Angular für konventionelle Websites?

Angular ist ideal für Websites mit dynamischem Inhalt, jedoch nicht für kleine Seiten mit statischem Inhalt geeignet. Die Implementierung von Angular erhöht in diesem Fall lediglich die Gesamtgröße des Projekts und folglich auch die Ladezeiten. Dies ist eines der Hauptgründe, warum man Angular nicht für Landing Pages und Websites mit statischem Inhalt verwenden sollte. Davon abgesehen ist Angular weit davon entfernt, SEO-freundlich zu sein. Und im Zeitalter von Search-Engine-Optimization gibt es weitaus bessere Alternativen, um dieses Ziel zu erreichen. Auch ist Angular keine gute Lösung für kurzfristige Projekte oder Start-ups mit begrenzten Ressourcen. Die Komplexität des Front-Ends kann in relativ kurzer Zeit immense Ausmaße annehmen und später schwer zu bändigen sein.

Das Hauptanwendungsgebiet von Angular bestand darin, Einzelseiten-Webanwendungen zu erstellen. Aus diesem Grund verfügt es über eine breite Palette von Werkzeugen für die SPA-Entwicklung. Darüber hinaus ist es eine ideale Technologie für Websites, bei denen sich der Inhalt auf der Grundlage des Nutzerverhaltens und der Präferenzen der Benutzer dynamisch anpasst. Dependency Injections stellen sicher, dass im Falle der Änderung einer Komponente andere Komponenten, die mit ihr in Zusammenhang stehen, automatisch mitgeändert werden.

Die 3 verschiedenen Ladetechniken

Bei der Arbeit mit Angular bieten sich 3 verschiedene Ladetechniken an. Diese sind das Eager Loading, Lazy Loading und Preloading, auf die ich nachfolgend eingehe.

Eager Loading (Eifriges Laden)

Der Abruf aller benötigten Daten möglichst wirksam und umgehend bzw. sofort. Hierzu gibt es im Grunde genommen nicht viel anzumerken. Die Technik ist zwar effizient, doch die Tatsache, dass man eventuell nur einen bestimmten Teil der Daten benötigt aber dennoch alle Daten lädt, kann sich schnell zu einem Nachteil entwickeln, wenn es sich um große Datenmengen handelt.

Lazy Loading (Langsames Laden)

Die am wenigsten eifrige bzw. nicht eifrige Ladetechnik. Wenn man faul ist, tut man so lange nichts, bis man es wirklich muss oder dazu gezwungen wird. Man stelle sich vor, dass die Anwendung drei Bereiche hat. Home, Admin und das Dashboard. Auf den Home-Bereich wird ständig zugegriffen, auf den Dashboard-Bereich die meiste Zeit. Der Admin-Bereich wird jedoch nur von einigen wenigen Nutzern verwendet. Folglich kann man die Admin-Route nach und nach laden. So lange niemand auf die Idee kommt, auf den Verwaltungsbereich der Anwendung zu klicken, wird der damit verbundene Code auch nicht ausgeführt bzw. nicht geladen.

Die Mehrheit der Nutzer lädt den Code für den Verwaltungsbereich schlichtweg nie. Wenn man also Lazy Loading verwendet, kann man grundsätzlich schneller auf die Anwendung zugreifen, da man nicht so viel Code vom Server laden muss. Dies hängt damit zusammen, dass das ORM-Werkzeug (Objekt-Relationales Mapping-Werkzeug) jeglichen Zugriff auf alle Objektreferenzen »abfangen« muss, um hier bei Bedarf die verbundenen Objekte nachladen zu können. Dieses Abfangen erfolgt durch die Verwendung bestimmter Klassen für Einzelreferenzen und Mengenklassen. Der Unterschied zwischen den ORM-Werkzeugen liegt darin, ob der Entwickler diese Klassen explizit im Code verwenden muss oder ob das ORM-Werkzeug diese beim Kompilieren oder zur Laufzeit austauscht.

Preloading (Vorladen)

Die „somewhere-in-between“ (Irgendwie Zwischendrin) Ladetechnik. Beim Preloading macht man im Grunde genommen dasselbe wie beim Lazy Loading, nur ein bisschen anders.

Anhand des Home, Dashboard und Admin Beispiels lässt sich dies folgendermaßen darstellen. Die Startseite braucht man immer. Also lädt man diese schnell bzw. eifrig. Der Admin-Bereich wird nur selten und nur von wenigen Benutzern benötigt, also kann man diesen erst einmal etwas vernachlässigen bzw. „lazy“ laden. Aber das Dashboard ist nicht das Erste, was ein Benutzer sieht, also kann es grundsätzlich erst einmal warten. Doch das Dashboard ist gleichzeitig etwas, dass die meisten der Benutzer irgendwann sehen möchten. Also sollte es zumindest dann zur Verfügung stehen, wenn das Laden des Home-Bereichs fertiggestellt ist. Nach jeder erfolgreichen Navigation sucht der Router in seiner Konfiguration nach einem nicht geladenen Modul, das er vorladen kann.

Der Home-Bereich wird erfolgreich geladen und unmittelbar danach wird der Dashboard-Bereich im Hintergrund geladen.

Welche Ladetechnik kann/soll ich nun verwenden?

Wie bei vielen Angelegenheiten in der IT kommt es hier auf den spezifischen Anwendungsfall und den zur Verfügung stehenden Ressourcen an. Wenn man nicht genau weiß, ob man die zusätzlichen Daten benötigt oder nicht, dann kann es ungünstig sein, sie direkt zu laden. Es kann aber auch ungünstig sein, sie später nachladen zu müssen. Entscheidend bei der Entscheidung ist die Wahrscheinlichkeit, ob und wann man die jeweiligen Daten für wen benötigt, um welche Datenmenge es sich handelt und ob man die Daten später einfach nachladen kann. Zu beachten ist, dass man ein automatisches Nachladen, nach einer Serialisierung, in der Regel nicht mehr initiieren kann.

Release-Frequenz

Angular Releases folgen dem Konzept des Semantic Versionings. Man unterscheidet zwischen Major-, Minor- und Bugfix-Releases. Alle 6 Monate gibt es eine neue Major Release. Major Releases enthalten signifikante neue Features, sind aber nicht abwärtskompatibel. Der Umstieg auf eine neuere Major Release benötigt daher oft Update-Scripts, Refactorings des bestehenden Codes, weitere Tests und das Erlernen neuer APIs. Zu jeder Major Release gibt es ein bis drei Minor Releases. Patch Releases und Pre-Releases gibt es fast jede Woche.

Support

Der Support von Major Releases beträgt typischerweise 18 Monate lang nach Release. Davon 6 Monate aktiv. Aus diesem Grund gibt es in regelmäßigen Abständen Minor Releases und Patch Releases. Es folgt ein 12-monatiger Long Term Support (LTS) in Form von Patch-Releases, ausschließlich zur Behebung kritischer und sicherheitsrelevanter Fehler.

Fazit

Bei der Verwendung von Angular sollte von vornherein klar sein, dass die Realisierung eines Projekts mit der Abnahme vieler Entscheidungen über Architektur und des Renderings verbunden ist. Dies hat den Vorteil, dass sich das Projektteam zu 100% auf die Umsetzung von Features konzentrieren kann und nicht die grundlegende Architektur eigenständig aufbauen muss.

Durch die sehr einheitliche Struktur von Angular Anwendungen lassen sich gute Entwickler sehr schnell in das Projekt integrieren, da Angular Anwendungen stets einer gewissen Struktur folgen. Dies vereinfacht die Skalierbarkeit des Teams als auch des Projektes selbst als vergleichsweise bei Individuallösungen der Architektur in anderen Frameworks.

Generell ist es für Enterprise Projekte sicherlich eine gute Wahl. Dennoch sollte man andere Frameworks wie React und VueJS nicht außer Acht lassen, über die ich in den kommenden Tagen schreibe.

Der Beitrag Angular – Entfaltung des vollen Potenzials von Webanwendungen erschien zuerst auf CEOsBay.

Wie funktioniert SonarQube?

SonarQube besteht aus drei Komponenten

1. Einem Modul für Build-Management-Tools wie Apache Maven oder Apache Ant. (Hauptsächlich für die Analyse des Quelltextes hinsichtlich verschiedener Qualitätsmerkmale.)
2. Einer Datenbank, für Speicherung der Ergebnisse der Qualitätsanalyse.
3. Einer Website für die visuelle Darstellung, Auswertung und das Management der Qualitätsanalyse-Ergebnisse.

Durch diese Architektur kann man sowohl eine Prüfung des Quelltextes auf dem Entwicklungsrechner ermöglichen als auch eine Einbindung von SonarQube in den Entwicklungsprozess gewährleisten. Dies unterstützt die Ermittlung der Qualitätsmetriken auf einem Build-Server für die kontinuierliche Integration.

SonarQube analysiert den Quelltext hinsichtlich der Abdeckung durch Modultests, checkt den Quellcode nach doppeltem Code und in Bezug auf die Komplexität. Auch werden unter anderem potenzielle Fehler im Code, Kodier-Richtlinien als auch Kommentare überprüft.

Modularer Aufbau und Erweiterungen

SonarQube ist modular aufgebaut und integriert selbst einige bekannte Entwicklungswerkzeuge zur Analyse der Codequalität, darunter PMD und Checkstyle für die Erkennung von doppeltem Code für die Prüfung von Kodier-Richtlinien. Damit wird unter anderem auch nach ineffizientem Code gesuche. FindBugs dient beispielsweise zum Aufdecken potenzieller Fehler sowie Surefire und Cobertura zur Messung der Qualität der Modultests.

Diese Werkzeuge nutzen entsprechend ihrer Natur und Einsatzgebiete Metriken, um die jeweiligen Auswertungen bzw. Statistiken zu erzeugen. Der Name „Metrik“ trägt jedoch wenig Bedeutung von dem in sich, was eine Metrik ausmacht. Schlägt man nämlich nach woher der Name kommt, landet man im Lateinischen: „ars metrica„, die Lehre von den Maßen. Fragt man jedoch das Institute of Electrical and Electronics Engineers, was eine Softwaremetrik ist, erhält man folgende Antwort:

„software quality metric: A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality.“ „Eine Softwarequalitätsmetrik ist eine Funktion, die eine Software-Einheit in einen Zahlenwert abbildet, der als Erfüllungsgrad einer Qualitätseigenschaft der Software-Einheit interpretierbar ist.“ – IEEE Standard 1061, 1998

Folglich bedeutet dies, dass es sich bei einer Metrik am Ende des Tages um eine Funktion handelt, die für beliebige Eingaben Zahlen erzeugt. Die Beschaffenheit ist so, dass sie, nur so 

lange sie von derselben Funktion erzeugt wurden, vergleichbar sind. Dadurch kann man Rückschlüsse auf die Eingabe mit Hinblick auf die Funktion erzielen.

Ein Beispiel dafür ist die McCabe-Metrik, auch zyklomatische Komplexität genannt. Diese sehr grundlegende Metrik berechnet die Anzahl der unterschiedlichen Pfade durch ein Stück Code. Die Formel ist relativ einfach: Es wird die Anzahl an Kontrollstrukturen wie if, while, case und boolescher Operatoren wie && und || summiert und nochmals mit 1 addiert. Möchte man diese Information nochmals anhand eines Beispiels betrachten, sieht es folgendermaßen aus:

String nameDesWochenTags(int nr) {
  switch(nr) {
    case 1: return "Montag";
    case 2: return "Dienstag";
    case 3: return "Mittwoch";
    case 4: return "Donnerstag";
    case 5: return "Freitag";
    case 6: return "Samstag";
    case 7: return "Sonntag";
  }
  return "";
}

Diese relativ einfache Methode gibt den Namen eines Wochentages entsprechend seiner 1-indizierten Position innerhalb der Woche zurück. Ihre zyklomatische Komplexität beträgt 8. Zumal 1 + 7 x case. Dies ist ein verhältnismäßig hoher Wert. Ein Maximalwert von 10 gilt als allgemein akzeptiert und ausreichend erprobt. Um also die Komplexität dieser Methode zu verringern, findet eine Refaktorisierung statt, die folgendermaßen aussehen kann:

String nameDesWochenTags(int nr) {
  String[] names = new String[] {
    "Montag", "Dienstag", "Mittwoch",
    "Donnerstag", "Freitag", "Samstag",
    "Sonntag"
  };
  if(nr) > 0 && <= names.length) {
    return names[nr - 1];
  }
  return "";
}

Die zyklomatische Komplexität dieser Methode beträgt 3. Zumal 1 + 1 x if + 1 x &&. Durch den unterschiedlichen Ansatz kann man die Komplexität verringern. Dennoch ist es relativ unstrittig, dass die erste Version leichter zu verstehen ist.

Will man nun also alle Tools gemeinsam benutzen, muss man alle konfigurieren und ihre Ergebnisse zusammenführen, damit sich ein Gesamtbild darstellen lässt. Außerdem kommt es dabei zwangsweise zu Dopplungen in ausgewerteten Metriken oder anderen Kennzahlen. PMD beispielsweise besitzt durch seinen relativ vagen Aufgabenbereich Überschneidungen im Hinblick auf Codestil mit checkstyle, während es aber auch genauso wie FindBugs auf toten Code achtet. An solchen und weiteren Stellen kann SonarQube Verbesserungen herbeiführen.

Neben der visuellen Anzeige der Ergebnisse der einzelnen Bereiche, ermöglicht SonarQube das Drill-Down der Ergebnisse bis auf die einzelne Metrik und Codezeile sowie die Verknüpfung der einzelnen Metriken sowie die Darstellung ihrer historischen Entwicklung in einer recht übersichtlichen grafischen Oberfläche.

Über einen ausgeklügelten Plugin-Mechanismus ist eine relativ einfache Integration von Erweiterungen möglich. Neben den Erweiterungen für die Analyse zusätzlicher Programmiersprachen gibt es Plugins für ergänzende Metriken, Governance, Schnittstellen zu Entwicklungsumgebungen, Visualisierungen, Integration sowie zur Berechnung der technischen Schuld(en).

Fazit

Ich arbeite noch nicht so lange mit SonarQube. Um genau zu sein, habe ich es mir erst heute das erste Mal angeschaut. Zusammenfassend kann ich folgendes sagen:

Statistiken sind zwar interessant und es kann Spaß machen, sich diese anzuschauen, doch ist eine statische Codeanalyse erst dann wirklich vollständig, wenn ein Mindestmaß an Interpretation hineingeflossen ist.

Die Codeanalyse liefert ein gutes Gefühl für die Codebasis. Erst so kann man fundierte Aussagen darüber treffen, welche Bereiche des Projekts besonders gefährdet, instabil oder verbesserungsfähig sind.

Regelmäßige Analysen können die Teammotivation erhöhen. Eine positive Issuebilanz am Ende eines Sprints und aufwärtszeigende Historiengraphen sollten gute Treiber für eine Gruppe Entwickler und ein Beweis für die eigene Leistung sein.

Alles in allem sind Analyseergebnisse immer gut als Argumentationsgrundlage. Mit Hilfe der Projekthistorie, die eine Auswahl gut darstellbarer Kennzahlen beinhaltet, kann man vor Kunden oder Entscheidern besser über ein eventuell nötiges technisches Release diskutieren.

Der Beitrag SonarQube – Das Code-Qualitätsmanagement-Tool erschien zuerst auf CEOsBay.