Innerhalb des 3ten Semesters haben wir, die Masterklasse Mobile, die Aufgabe ein Gruppenprojekt umzusetzten. Zusammen wurde entschieden, dieses mit Flutter umzusetzen. Eine Flutter Library, welche verschiedene Sensoren auslesen kann und roh oder interpretiert zurückgibt.

https://github.com/hraschan/flutter_sensor_library

Außerdem haben wir uns hier entschieden, dass es eine “Beispiel App” dafür geben soll, die die Anwendung der Library präsentiert.

https://github.com/hraschan/flutter_sensor_library_app

Flutter

Da wir alle zuvor kaum bis gar keine Erfahrung mit Flutter gemacht haben, wurde von Mario und Maximilian ein Workshop vorbereitet, der uns die Grundlagen präsentiert hat und in welchem wir gemeinsam das Setup des Projekts durchführten.

Flutter an sich ist ein Open-Souce-Framework von Google, das zur Erstellung von nativ kompilierten Anwendungen verwendet wird. Bei Flutter gibt es viele Bibliotheken für Standard-UI-Elemente, die bei Android oder iOS benötigt werden. Für Desktop Webanwendungen kann das Framework auch eingesetzt werden.

Das Framework wird also primär für iOS und Android Applikationen verwendet. Für die Entwicklung wird die Programmiersprache “Dart” verwendet, diese wurde ebenfalls von Google entwicklet.

Was kann die Library

Die Library bietet verschiedene Klassen und Methodensammlungen an, um die Sensoren eines Mobilgeräts nutzen zu können. Dabei beruht sie bei den meisten Sensoren auf bereits vorhandenen Librarys, verarbeitet diese und gibt die Daten, wenn gewünscht, gesammelt an eine Flutter App weiter. Zudem bietet die Library auch interpretierte bzw. aus mehreren Sensoren zusammengefasste Daten, wie bspw. die Höhenmeter an, die aus dem aktuellen Luftdruck (Barometer) und dem Luftdruck auf Seehöhe ausgerechnet werden.

Aufgerufen kann die Funktionalität über gewisse Wrapper-Klassen, je nachdem ob Bewegungs-Daten (Movement), Positions-Daten (Position) oder Umgebungs-Daten (Environment) benötigt werden. Außerdem können die nativen Sensoren einzeln aufgerufen werden. Dabei muss immer angegeben werden, in welchem Zeitintervall die jeweilige Klasse Daten zurückliefern soll.

Movement mvmnt = Movement(inMillis: 2000);
mvmnt.getMovementType(true).forEach((element) {print(element.fwd);});

Mit diesem einfachen Code-Beispiel kann alle 2 Sekunden abgefragt werden, ob sich das Gerät in den letzten zwei Sekunden nach vorne bewegt hat. Mit der Übergabe des Boolean (in dem Fall true) kann festgelegt werden, ob die aktuelle Fortbewegung zum Zeitpunkt der Abfrage oder die interpolierten Daten seit der letzten Abfrage wiedergegeben werden sollen.

Die Bespielapplikation

Um die Andwendung der Library zu vereinfachen, wurde ein Beispielapplikation geschaffen, welche die einzelnen Verwendungszwecke zeigen soll. Hier einige Screenshots der Anwendung:

Personal Learnings

Armin

Mein Learning aus dem Gruppenprojekt ist die Einführung in Flutter. Ich habe mit diesem Framework zuvor noch keine Projekte umsetzen können. Ehrlichgesagt finde ich das Framework recht unübersichtlich und ich finde es gibt Frameworks, die um Einiges besser konzipiert sind als Flutter. Dennoch habe ich dieses Learning für die Zukunft mitnehmen können und da Flutter recht bekannt ist, ist auch diese Erfahrung von Wert.

Bettina

Für mich war Flutter vollkommenes Neuland. Bei diesem Projekt konnte ich hier einiges lernen. Von Projektstruktur über Codeaufbau, Widget Aufbau, Verwendung von Libraries sowie die Nutzung verschiedener Simulatoren.

Mario

Die Vertiefung der Kenntnisse in Flutter nach dem gemeinsamen Workshop mit Maximilian ist bestimmt ein großer Lernzugewinn. Die Nutzung der Sprache Dart ist doch etwas ungewohnt, obwohl sie sehr an JavaScript angelehnt ist. Außerdem konnte ich bei der Konzeption einer Library sehr viel dazulernen. Die Erarbeitung einer Library und die Vorstellung anderer Entwicklerinnen als Nutzerinnen des eigenen Programms stellt einen Lerneffekt dar, den man in anderen Projektkontexten so nicht hat.

Maxi

Für mich hat dieses Projekt vor allem einen tieferen Einblick in Flutter ermöglicht. Auch habe ich das aufbauen einer eigenen Library bis jetzt noch nicht in dieser Form kennengelernt. Ich denke jedoch das es noch einiger Zeit bedarf um gute Lösungen mit der Technologie Flutter entwickeln zu können

Thomas

Bis zum Workshop von Mario und Maxi kannte ich weder Flatter noch Dart. Durch den Workshop konnte ich mir ein gutes Grundwissen aneignen und anschließend im Rahmen des Projekts tiefer in die Materie einsteigen. Im Großen und Ganzen habe ich einen guten Überblick über Flutter, Dart und verschiedener Sensoren bekommen.

Sebastian

Die Zusammenarbeit mit Mario und Maxi während der Ausarbeitung des Backends hat mir einige neue Erkenntnisse gebracht. Sowohl mit Flutter als auch mit Dart hatte ich vor diesem Projekt wenig zu tun gehabt. Daher war es für mich sehr erkenntnisreich, ein Projekt umzusetzen, beziehungsweise daran beteiligt zu sein. Auch der Gedanke eine eigene Library zu erstellen war für mich interessant, da ich diesen Aspekt des Programmierens bis dato nur von der anderen Seite gekannt habe. Ich bin gespannt, ob die Library in irgendeiner Form einen späteren Verwendungszweck finden wird.

The post Sensor Library appeared first on Mobile USTP MKL.

Verwendete Technologien

Das Design wurde zunächst in Figma für die benötigten Screens erstellt und mit einigen Kollegen reviewt. Dabei wurden einige Anpassungen vorgenommen. Darauffolgend wurde anhand der Design-Vorlage mit der Erstellung der Applikation begonnen.

Die App basiert auf einem Backend, welches mit Strapi, einem Headless Content Management System, erstellt wurde. Darin können, wie von einem CMS bekannt, in einem designtem UI beispielsweise Texte und Bilder hochgeladen und bearbeitet werden, die dann auf der Webseite angezeigt werden sollen. Anders als bei normalen CM-Systemen, werden die Seiten aber nicht direkt im CMS gebaut, sondern können per API von einem selbst-gebauten Frontend aufgerufen werden. Das Content-Management-System liefert bei Aufruf der richtigen URL wie eine API die Daten im JSON-Format. Das Frontend, die Annahme und Verarbeitung der JSON-Daten und das Design, müssen selbst in die Hand genommen werden. Dies verlangt wesentlich größere Erfahrung im Umgang mit Webentwicklung, bietet allerdings auch wesentlich mehr Freiheit im Design. Außerdem macht es unabhängig von diversen Bezahlmodellen.

Um die Datenverarbeitung im Frontend gering zu halten, wurde ein DataProvider-Service, welches mit einer .NET 5 API in C# umgesetzt wurde, zwischengeschaltet. Dieses übernimmt die Daten von Strapi, verarbeitet sie für das Frontend und bietet diese über eine weitere API an. Durch die Effizienz der Applikation geht somit nicht viel Zeit verloren, es konnte jedoch einiges an Flexibilität und Wartbarkeit gewonnen werden.

Das Frontend in VueJS der Version 3 enthält somit nicht viel Logik, sondern beschränkt sich hauptsächlich auf die Darstellung der Daten und die Weitergabe der Nutzer-Eingaben ans Backend, die in der ersten Version noch nicht besonders groß ausfallen. Das Styling wurde großteils mithilfe des Styling-Frameworks Tailwind CSS durchgeführt, wodurch nahezu gar keine Zeile CSS notwendig war. Außerdem wurde sich für die Umsetzung mit der Vue 3 Composition API, im Gegensatz zur bisher gebräuchlichen Options API entschieden.

Aufbau

Der Startscreen zeigt das Logo mit dem Titel und Untertitel der App, sowie alle Navigationsmöglichkeiten der App. Man kann sich die Liste an verfügbaren Quizzes anzeigen lassen, sowie seine Challenges zu einer nachhaltigeren Mobilität ansehen. Außerdem befindet sich in der linken oberen Ecke ein Hamburger-Menü, worüber man von jeder Seite aus auf die drei Hauptseiten Home, Quizzes und Challenges wechseln kann.

Auf der Quizzes-Seite sieht man alle verfügbaren Quizzes und kann sie starten, indem man den Namen des jeweiligen Quizzes anklickt. Daraufhin öffnet sich das Quiz und die erste Frage wird gestellt. Es besteht in der ersten Version kein Zeitlimit. Nach Anklicken einer Antwortmöglichkeit wird aufgelöst, ob die Antwort korrekt ist und wenn nicht, welche die korrekte Antwortmöglichkeit ist. Außerdem wird eine nähere Erläuterung zum Thema angeboten. Nach Ablauf von 5 Sekunden wird die nächste Frage angezeigt. Wenn alle Fragen beantwortet wurden, kann über einen Button zur Liste der Quizzes zurückgekehrt werden.

Auf der Challenges-Seite sind alle für den jeweiligen Nutzer / die jeweilige Nutzerin verfügbaren Challenges und deren Status zu sehen. Per Klick auf eine Challenge kann diese abgeschlossen bzw. wieder geöffnet werden.

Learnings

Den größten Lerneffekt hatte wohl die Nutzung von Azure App Services als Veröffentlichungsplattform für das Data-Provider-Service basierend auf .NET. Da ich vor diesem Projekt noch nie eine Applikation persönlich auf Azure gehostet habe, konnte ich durch dieses Projekt nun sehr viel dazulernen. Auch einige Herausforderungen mit CORS und der Middleware haben mich Azure und die Möglichkeiten von .NET näher erkunden lassen.

Ein weiteres selbst gestecktes Ziel war die Verringerung der Komplexität des Frontends. Mit einem headless CMS im Backend müssen oft viele Datenanpassungen im Frontend vorgenommen werden. Diese konnten durch das .NET Service als Businesslayer verringert werden. Mithilfe der erstmaligen Nutzung von Tailwind CSS war außerdem nahezu kein selbstgeschriebenes CSS notwendig. Lediglich die Animationen wurden selbst geschrieben. Durch die sprechenden Klassennamen, die Tailwind in HTML verwendet, bleibt der Code weiterhin gut lesbar. Insgesamt wurden ca. 240 Zeilen Javascript-Code und ohne Animation (denn die hätte man auch in Tailwind bauen können) 19 Zeilen CSS benötigt.

Außerdem habe ich mich bei der Implementierung des Frontends mit Vue 3 Großteils auf die Nutzung der neuen Composition API beschränkt, einer neuen Art, Vue zu implementieren. Diese weist große Unterschiede zur bisherigen Options API auf und hat vor diesem Projekt einige Unsicherheiten mit neuem Vue-Code in mir ausgelöst. Diese konnte ich mit diesem Projekt beseitigen.

The post Face it – Für umweltfreundlichere Mobilität (Projektdoku) appeared first on Mobile USTP MKL.

Allgemeine Neuerungen

64-bit

Visual Studio 2022 läuft nun, anders als seine Vorgänger, die nur 32-bit anboten, ausschließlich mit einer 64-bit-Version. Das soll laut Microsoft vor allem Vorteile für große Solutions, da durch die Verwendung von 64-bit mehr als 4 GB RAM zur Verfügung stehen. Dabei sollen Testungen mit Solutions, die über 16.000 Projekte beinhalten, gemacht worden sein. Gleichzeitig können durch diese Änderung allerdings auch Fehler auftreten. Durch die jahrelange Exklusivität der 32-bit-Version könnten in Projekten z.B. einige Ordnerpfade hardcoded auf 32-bit-Dateien verweisen, die nun nicht mehr gültig sind. Deswegen ist bei dieser Änderung besondere Vorsicht geboten.

Öffnen der Solutions schneller

Zudem werden Solutions beim Öffnen nun um einiges schneller geladen und oft erst später benötigte Features im Laufe der Nutzung nachgeladen. In der alltäglichen Nutzung macht sich dies schnell bemerkbar. Vor allem bei großen Solutions mit fast 30 Projekten musste man mit den Versionen 2019 und davor oft minutenlang warten, um vielleicht nur eine einzige Code-Zeile zu betrachten.

Unterstützte .NET-Versionen

Die unterstützten .NET-Versionen haben sich geändert. Beim Urahnen der .NET-Familie .NET Framework wurde die letzte unterstützte Version auf 4.6.2 angehoben. Außerdem bietet Visual Studio 2022 nun vollen Support für das neue .NET 6. Aber was bedeutet das, wenn die IDE eine Version nicht mehr oder nun vollständig unterstützt? Dazu findet man keine klaren Angaben seitens Microsoft. In der Doku über Framework Targeting lässt sich allerdings herauslesen, dass der Support hauptsächlich für die korrekte Kompilierung der jeweiligen .NET-Version relevant ist. Denn, wenn die IDE die Version unterstützt, wird auch die richtige Compiler-Version mit den richtigen Optionen angewandt. Weiters kann es sein, dass die Optionen im Kontext-Menü, in den Properties, in der Toolbox und anderen Menüs oder die Vorschläge von IntelliSense nicht an die Verfügbarkeit der jeweiligen .NET-Version angepasst sind. Das bedeutet, dass womöglich Vorschläge angeboten werden, die in der jeweiligen Version noch nicht/nicht mehr funktionieren.

Weitere allgemeine Änderungen

Weitere Änderungen sind der Multi-Repo-Support, wonach man nun mehrere Repositories in einer Solution konfigurieren kann. Außerdem verspricht das Visual Studio-Team einen bessere MacOS-Experience, verbesserte GIT-Tools zum Lösen von Konflikten und verbesserten C++-Support.

UI/Desing-Anpassungen

Änderung der Standardschriftart

Die Standardschriftart wurde von consolas auf cascadia code geändert. Die neue Schriftart unterstützt standardmäßig Code-Ligaturen. Dabei werden z.B. die beiden Zeichen ! und = automatisch zu einem Ungleich zusammengefügt. Wem die Schriftartanpassung nicht passt, kann die Schriftarten relativ einfach umstellen. Unter Tools –> Options –> Fonts and Colors lässt sich einiges personalisieren.

Night Light

Außerdem wurde das sogenannte night light-Feature eingeführt. Somit lässt sich nun das Design von Visual Studio an das derzeit eingestellte Design des Betriebssystems anpassen. Dazu muss in den Einstellungen unter Tools –> Options –> General –> Color Theme die Option “Use System Settings” gewählt werden. Visual Studio verspricht damit auch, dass es sich, wenn so im Betriebssystem konfiguriert, je nach Tageszeit automatisch von Light-Mode in den Dark-Mode umschaltet. Leider konnte ich dieses Feature weder in Windows 10 noch in Windows 11 testen, da ich das Timen zum Umschalten des Farbmodus nicht finden konnte. Von Seiten Visual Studio dürfte es funktionieren: Schaltet man den App-Modus von Windows manuell von Light-Theme auf Dark-Theme, passt sich auch Visual Studio dementsprechend an. Bei MacOS funktioniert dieses Feature laut eigenen Testungen einwandfrei.

Fokus auf Personalisierung

Generell wird bei der Entwicklung von Visual Studio 2022 vermehrt der Fokus auf die Personalisierung des Arbeitsplatzes gelegt. Dies gilt vor allem für die Roadmap von 2022, da viele dieser Ideen noch nicht verfügbar sind. Unter anderem ist die Sortierung der Files nicht nur nach Projekt, sondern nach eigener Ordnung geplant. Zudem, dass Tabs je nach Projekt eingefärbt sind und der aktive Tab fettgedruckt ist, dies soll die Verständlichkeit erleichtern. Außerdem soll man die Breite der Tabs anpassen können.

Code-Unterstützungen

IntelliCode

Ein bahnbrechendes Feature dürfte die Einführung von IntelliCode sein. Der Code-Editor bietet einem beim Beginn einer Code-Zeile KI-basierte Vorschläge an, diese Zeile fertigzustellen. Dabei wurde diese KI nicht nur an von Microsoft zur Verfügung gestelltem Code trainiert. Man kann sie auch an der eigenen Solution trainieren lassen, um die Vorschläge zu verbessern. Im Selbsttest erscheint das Feature als relativ zuverlässig und zeitsparend, jedoch ist es schnell “beleidigt”, wenn man die Ideen nicht annimmt und schlägt für derartige Zeilen dann nichts mehr vor. Gut veranschaulichen lässt es sich bei der Injection eines Services. Wenn man ein Property als Instanz des Services initialisiert und einen Übergabeparameter für dasselbe Service im Constructor angibt, so wird einem im Body des Constructors die Code-Zeile vorgeschlagen, die das Property auf die Referenz des Übergabeparameters setzt. In diesem Video wird das Feature ebenfalls vorgestellt.

Find in Files verbessert

Das Feature Find in Files, welches mit der Tastenkombination Strg + Shift + F aufgerufen werden kann, wurde um das Dreifache beschleunigt. In einer Test-Solution mit 28 Projekten konnte ich sogar eine 4-fache Beschleunigung feststellen. In der folgenden Tabelle wird es mit der neuesten Version von Visual Studio 2019 und den Such-Features der Visual Studio-Erweiterung Resharper verglichen:

Rich Code Navigation

Unter den derzeitigen Preview Features ist ebenfalls eine tolle Neuerung zu finden, die das Entwickeln mit Visual Studio in Zukunft um einiges erleichtern könnte: die Rich Code Navigation lässt es zu, dass über die üblichen Shortcuts (wie z.B. Strg + Klick auf den Typ) durch Code navigiert werden kann, der sich nicht nur wie bisher in den bereits geklonten, sich in der Solution befindlichen Repositorys befindet, sondern aufgerufen werden kann, ohne ein Repository klonen zu müssen. Dieses Feature konnte ich an keinem persönlichen Projekt testen. Es stellt sich somit die Frage, ob die Repositorys dafür öffentlich oder auf einer gewissen Plattform (z.B. Microsofts Github) verfügbar sein müssen bzw. wie dieses Feature im Allgemeinen funktioniert.

Tipp: Preview Features einschalten

Die Preview-Features können unter Tools –> Options –> Environment –> Preview Features einzeln aktiviert und deaktiviert werden.

Dieses Thema soll laut Roadmap in Zukunft auch Verbesserungen beim Debuggen von dekompilierten Files bringen. Außerdem wurden generelle Verbesserungen der Performance des Debuggers angekündigt. Der Fokus der Weiterentwicklung von Visual Studio im Jahr 2022 liegt somit sowohl auf der Personalisierung des UIs wie oben erwähnt, als auch auf der Verbesserung der Diagnostics und des Debuggings.

Weitere Code-Features

Es besteht jetzt die Möglichkeit, dependent Breakpoints zu setzen, sprich Breakpoints, die nur aufgerufen werden, wenn eine gewisse Bedingung im Code eintritt bzw. ein gewisser Breakpoint davor erreicht wurde. Außerdem wurde ein Flame Chart präsentiert, in dem visualisiert werden kann, welcher Code wie oft läuft. Es wurde ein neuer Razor-Editor veröffentlicht, der unter anderem verbessertes Refactoring anbietet (z.B. “Add missing usings” in cshtml-Files).

Ein weiteres Feature ist die Möglichkeit, Hot Reload zu nutzen, wie bereits aus einigen anderen Entwicklungsumgebungen bekannt. Es funktioniert bis Version .NET 5 nur beim Ausführen der App im Debug-Mode (Shortcut F5), ab .NET 6 auch ohne Debugging (Shortcut Strg + F5). Weitere Infos dazu unter: Speed up your .NET and C++ development with Hot Reload in Visual Studio 2022 und Write and debug code by using Hot Reload.

Vielen Dank an Christian Lascsak für die gemeinsame Ausarbeitung und Testung in Projekten: Christian Lascsak auf Github

The post Visual Studio 2022 – Wichtigste Neuerungen und was sie bewirken appeared first on Mobile USTP MKL.

Einzigartiges Design

Zunächst war wichtig, die Besucherin bzw. den Besucher mit einem einzigartigen, abgestimmten Design mit Wiedererkennungswert zu erwarten. Dazu half das vor Jahren von mir entwickelte Logo in Form eines Z, welches ich auch schon auf meiner ehemaligen Portfolio-Webseite verwendet hatte. Mit Unterstützung durch eine erfahrene UX/UI-Designerin entwickelte ich eine stimmige Farbpalette und entschied mich für eine passende Schriftart. Die verwendeten Icons sind teilweise an den bisherigen Lebenslauf angelehnt, da dieser in Zukunft auch wieder an die neue Webseite angepasst werden können soll.

Umsetzung mittels Headless-CMS Strapi und Frontend-JS-Framework Vue

Die Erstellung des Online-Lebenslaufes dient nicht nur dem Zweck der besseren Präsentation im Web meinerseits. Ich wollte mich auch im Umgang mit Headless Content-Management-Systemen und CSS Styling beschäftigen und meine Fähigkeiten in diesen Bereichen vertiefen. Somit wählte ich für die Umsetzung des CMS die Headless Content Management Plattform Strapi. Dieses CMS ist headless, was bedeutet, dass es ohne Designtool (Sitebuilder) ausgestattet ist, wie man es z.B. von WordPress kennt. Das Content-Management-System liefert bei Aufruf der richtigen URL wie eine API die Daten im JSON-Format. Das Frontend, die Annahme und Verarbeitung der JSON-Daten und das Design, müssen selbst in die Hand genommen werden. Dies verlangt wesentlich größere Erfahrung im Umgang mit Webentwicklung, bietet allerdings auch wesentlich mehr Freiheit im Design. Außerdem macht es unabhängig von diversen Bezahlmodellen.

Mithilfe des Frontend-JavaScript-Frameworks Vue gestaltete ich eine moderne Webapplikation, die auf ihrem Haupteinstiegspunkt der Nutzerin bzw. dem Nutzer zwei Wahlmöglichkeiten lässt. Den Weg zum Portfolio und Lebenslauf und die Übersicht über alle auf der Webseite befindlichen Artikel (Techblog; siehe Titelbild). Die Techblog-Seite, also die eigentliche Sammlung an allen Artikeln über Learnings und eigene Projekte, folgt im Laufe des nächsten Jahres. Im Rahmen dieses Projektes habe ich mich auf die Gestaltung der Lebenslauf-Seite konzentriert. Man findet die wichtigsten Interessen, meine Hard Skills, Soft Skills, berufliche Erfahrung, Ausbildungsweg, Kontaktmöglichkeiten und ein Impressum auf der Seite. Das responsive Design erstellte ich ohne Zuhilfenahme von irgendwelchen Design-Frameworks wie z.B. PrimeVue, um mich in der Arbeit mit Cascading Style Sheets und responsive Design zu vertiefen.

Features der Seite

Folgende Features sind in der Seite enthalten:

Full Responsive Design

Im Vergleich zu meiner bisherigen Seite, welche nur auf Full-HD Bildschirmen gut nutzbar war, ist diese Seite nun auf alle gängigen Bildschirmgrößen abgestimmt und die Designs für die jeweiligen Größen optimiert. So gibt es vier relevante Breakpoints für das Design. XS für alle Smartphones von iPhone 5 bis Pixel 2XL. SM für Tablets im Hochformat. MD für Tablets im Querformat. LG für alle Geräte mit einer größeren Bildschirmweite als 950 Pixel. Außerdem wurden einige Anpassungen gemacht, um die Seite auch auf 4K-Bildschirmen optimal darzustellen.

Alles wartbar

Alle auf der Seite befindlichen Texte sind im Content-Management-System wartbar und passen sich ausgewählten Profilen an. Außerdem lassen sich auch die Farben der Seite austauschen. In einer zukünftigen Erweiterung könnten auch das Logo und die Icons austauschbar gemacht werden können. So besteht die Möglichkeit, in Zukunft das Code-Snippet als Grundlage für andere Lebenslauf-Seiten verwenden zu können. Die Modifikation des Designs funktioniert dann gänzlich über das CMS.

Sprachen

Die Webseite präsentiert sich in englischer und deutscher Sprache. Die Sprachen lassen sich über einen Button in der Navigation umschalten, die sich auf der mobilen Version im Footer, ab dem MD-Breakpoint, also auf der Desktop-Version im Header befindet.

Dark Mode

Des Entwicklers Freund darf auf einer Seite eines Software Entwicklers natürlich nicht fehlen. Über einen Button im rechten oberen Eck der Seite kann im Desktop-Modus zwischen dem regulären Light-Mode und dem Dark-Mode umgeschaltet werden.

Meine Learnings

Aus der Arbeit an der Webseite konnte ich einiges für meine zukünftige Arbeit als Webentwickler lernen.

Responsive Design mit CSS

Bisher hatte ich oft einen großen Bogen um das Styling mit Cascading Style Sheets gemacht und die Arbeit anderen, erfahreneren Kolleginnen und Kollegen übergeben. Vor allem das responsive Webdesign zur Optimierung der Seiten für alle Bildschirmgrößen bereitete mir bisher große Sorgen. Dies hat sich durch dieses Projekt geändert. Ich fühle mich selbstbewusst im Umgang mit CSS und traue mir nun zu, eine Webseite für alle Bildschirmgrößen zu optimieren.

Erstellung einer vollständig wartbaren Seite mit zwei Sprach-Systemen

Die Verwendung eines Headless-CMS wie Strapi hat mir aufgezeigt, wie modular und anpassbar eine Webseite gestaltet werden kann, obwohl man das Frontend selbst gestaltet. Durch die Modularität der Webseite lassen sich nun auch zukünftige Anpassungen einfach erfüllen, ohne die Webseite neu programmieren zu müssen.

Arbeit mit jsPDF, einer Library zur Erstellung von PDF-Files in JavaScript-Code

Letztendlich ist mir durch das Projekt ein Einstieg in die Library jsPDF gelungen, womit ich versucht habe, den digitalen Lebenslauf per Knopfdruck in ein analog-fähiges Format als PDF umzuwandeln. Die Arbeit mit der Library und ihren eigenen Design-Vorschriften hat ebenfalls einiges abverlangt. Leider konnte ich dieses Feature nicht abschließen, da ich an die Grenzen der Library gestoßen bin. Ich möchte dieses Feature auf der Webseite in Zukunft aber dennoch umsetzen. Ein Ansatz wäre die Auslagerung dieses Features auf ein Backend-Service. Es gibt zahlreiche Libraries für .NET/C#. Das Endergebnis könnte der Kundin bzw. dem Kunden beispielsweise per E-Mail zugesandt werden.

Die Seite ist derzeit unter ihrer Beta-Versions-Adresse https://zerio.netlify.app/#/about erreichbar.

The post Erstellung eines Online-Lebenslaufes – Eine Projektdoku appeared first on Mobile USTP MKL.

So der Begriff WildWeek ist ja nun geklärt. Eine Woche Programmieren. Aber mit der einen Woche ist es nicht getan. Zuerst musste ein Projekt her. Kollektiv entschieden wir, die Masterklasse Mobile, uns für die Umsetzung einer App, dem „Pub Quiz“. Es handelt sich um eine App, mit der man sich ein Gefühl von Gemeinschaft nach Hause holen können, soll. Außerdem soll es möglich sein mit der App direkt in einem Pub an einem solchen Quiz teilnehmen zu können.

Für die Umsetzung wurden die Technologien NodeJs mit ExpressJs für die Entwicklung im Backend, sowie VueJs für die Frontendentwicklung herangezogen. Weiters wurde socket.io für die Verbindung der Spiele herangezogen.

Im Vorfeld war es unsere Aufgabe uns individuell auf die zugeteilten Aufgaben vorzubereiten, Tutorials anzusehen und die einzelnen Anteile vorzubereiten.

Bettina

Meine Aufgaben lagen neben der Backendentwicklung auch in der Organisation und Koordination in der Vorbereitung. Wir mussten einige Vorbereitungen treffen, wie Technologieentscheidungen, Erstellung von Diagrammen und das Design sollte auch im Vorhinein erstellt werden.

Mit dem Start der Woche hatten wir also alle unsere Teile soweit vorbereitet, dass wir mit der Umsetzung starten konnten. Während der Woche war ich Teil des Backendteams für die Organisationsplattform. In diesem Teil der App sollten die Spiele erstellt werden, Freunde eingeladen werden und ein Spiel gestartet werden können. Auch die Statistik sollte ein Teil hiervon sein. Hier hatte ich die Möglichkeit mein Wissen in NodeJs zu vertiefen und auch Kenntnisse im Websocket Bereich zu sammeln.

Mein größter Fortschritt war wohl in Sachen Websockets. Ich war mit dieser Art Kommunikation zwischen Front- und Backend noch nicht in Berührung gekommen und konnte somit ein neues Feld kennen lernen. Für Anwender mag es unbedeutend erscheinen, dass ein Name neben einem andren auftaucht, wenn ein weiterer Spieler teilnimmt, für mich war das wohl der spannendste Fortschritt.

Schwierig war wohl die Kommunikation innerhalb der Gruppe. Da wir alle isoliert zuhause saßen und lediglich online verbunden waren, hatten wir hier einige Anlaufschwierigkeiten. Ich denke aber dennoch lässt sich, das Ergebnis dieser Woche sehen!

Mario

Ich durfte die technische Planung und Leitung des Projektes übernehmen. Zur Vorbereitung dieser intensiven Programmier-Woche kümmerte ich mich um die Zusammenführung einzelner Design- und Architektur-Konzepte. Außerdem bereitete ich die Entwicklungsumgebung für die Arbeit am Projekt vor. Dabei forderte mich am meisten die Einrichtung von Pipelines zur automatischen Testung und Veröffentlichung des Programms auf unserem Server.
Während der Woche investierte ich die meiste Zeit in Meetings zur Abstimmung der einzelnen Entwicklungsstränge und mit dem Überprüfen von geschriebenen Code, sowie dem Instandhalten des Environments.
Ich durfte aber auch an einigen Features, wie der Erstellung eines Quizzes, mitarbeiten.

My Learnings

Arbeit mit Gitlab CI/CD

Ein System mit Frontend und Backend auf einem Produktiv-System mit funktionierender Kommunikation zum Laufen zu bringen, ist nicht die einfachste Aufgabe. Dafür musste ich schon viel Zeit in der Vorbereitung für die Woche, aber auch an den ersten Tagen der Woche investieren. Den Umgang mit Docker konnte ich außerdem noch vertiefen.

Konzeption eines Full Stack Web Projekts

In einem derart großen und komplexen Projekt mit so vielen Teammitgliedern habe ich gelernt, wie wichtig es ist, das Design, die User Experience und die Usability im Vorhinein zu planen und mit der Entwicklung nicht zu früh anzufangen. Sonst besteht die Gefahr, dass zwei verschiedene Entwicklungsstränge aneinander vorbei arbeiten und nicht dieselbe Vision von der Funktionalität vor sich haben.

Zusammenarbeit bei verschiedenen Arbeitsweisen

Je unterschiedlicher die Arbeitsweisen, desto besser muss die Planung sein. In bisherigen FH-Projekte mit einzelnen Kolleginnen und Kollegen gab es da wenige Probleme. Man sucht sich schließlich Projektpartnerinnen und -partner aus, mit denen man gut zusammenarbeiten kann. In diesem Projekt sind einige unterschiedliche Arbeitsweisen aufeinander getroffen und es hätte zu manchen Zeitpunkten bessere Koordination und womöglich konkretere Pläne benötigt, um stets das Ziel im Auge zu behalten.

Discord ist gold wert

Discord ist ein Tool zur Kommunikation, das aus der Videospielszene hervorgegangen ist. Es erlaubt, einerseits über Textkanäle zu chatten, aber auch in verschiedenen Sprachkanälen zu reden bzw. sogar per Video zu telefonieren und den Bildschirm zu teilen. Dabei sieht man dauerhaft, wer gerade mit wem in einem Gespräch ist und wer verfügbar ist. Die digitale Kommunikation funktioniert besser, wenn Nutzer wissen, wer online ist und wen sie gerade nicht stören mit ihrer Frage. Die Nutzung dieses Tools hat uns meiner Meinung nach besonders geholfen.

The post WildWeek: PubQuiz appeared first on Mobile USTP MKL.

Wahrscheinlich würde die flexible Data-Driven Documents Library d3.js alle drei genannten Datenvisualisierungs-Bibliotheken bei weitem schlagen. Jedoch ist der Einstieg in den Umgang mit dieser Bibliothek meiner Meinung nach eine Wissenschaft für sich. Dies hat mich davon abgehalten, in meinem letzten Kundenprojekt d3.js als Lösung für die benötigten Datenvisualisierungen in unserem Projekt vorzuschlagen. Ich war also auf der Suche nach Librarys, die einfacher zu erlernen sind, jedoch eine ähnlich große Flexibilität haben. Später kam auf Wunsch der Kundin bzw. des Kunden noch das Kriterium der Offline-Fähigkeit hinzu, was einiges änderte. In diesem Artikel möchte ich die Erkenntnisse präsentieren, die ich in meinem letzten Kundenprojekt über diese drei Chart-Librarys lernen durfte.

Vorstellung der Librarys

AMCharts – Ein kleines Team aus dem Osten

AMCharts ist eine Library erstellt von einer gleichnamigen siebenköpfigen Teams mit Sitz in Vilnius in Litauen, welche 2004 gegründet wurde. Die Nutzung ist unter allen rechtlichen Umständen kostenlos (soweit ich das der relativ eindeutigen Beschreibung der Seite entnehmen konnte), solange man die Einblendung eines Logos mit Verlinkung zur Seite von AMCharts auf der eigenen Seite erlaubt. Die Pro-Version bietet die Verwendung der Charts ohne Logo, sowie einen über die Dokumentation und das Forum hinausgehenden telefonischen und E-Mail-Support.

Die Seite gibt einen guten Überblick über alle möglichen Varianten an Diagrammen in Form von Beispielen und dem passenden Code. Sie wartet auch mit einem Forum und der Beantwortung von häufigen Problemstellungen auf. Die Graphen selbst zeigen sich in simplem Design. Es besteht die Möglichkeit, die Charts zu animieren. Daten werden über ein Objekt-Array mit bestimmten selbst definierbaren Keywords übergeben. Die Nutzung der Library funktioniert über die Installation von NPM-Packages oder der Einbindung von CDN-Ressourcen.

chart.data = [
    { from: "A", to: "D", value: 10 },
    { from: "B", to: "D", value: 8 },
    { from: "B", to: "E", value: 4 },
    { from: "B", to: "C", value: 2 },
    { from: "C", to: "E", value: 14 },
    { from: "E", to: "D", value: 8 },
    { from: "C", to: "A", value: 4 },
    { from: "G", to: "A", value: 7 },
    { from: "D", to: "B", value: 1 }
];

chart.dataFields.fromName = "from";
chart.dataFields.toName = "to";
chart.dataFields.value = "value";

Google Charts – Googles eigene Charting-Library

Google Charts ist die Charting-Lösung von Google, die sie laut eigenen Angaben auch selbst verwenden. Sie präsentiert sich als völlig kostenlose Bibliothek. Auch sie bietet eine große Auswahl an unterschiedlichen Charts. Das Design ist noch schlichter als bei AMCharts. Es besteht die Möglichkeit, die Graphen in 3D darstellen zu lassen. Einige Diagramme haben Animationen implementiert, wenn man über das Diagramm hovert. Wer an die Arbeit mit der Google Maps Library gewöhnt ist, wird sich auch schnell mit dem Aufbau der Charts Library anfreunden. Google Chart bietet nur die Möglichkeit einer Einbindung über CDN-Ressourcen.

Primefaces – ein vollständiges UI-Framework mit Charts

Primefaces ist der Überbegriff für eine Vielzahl an UI-Frameworks für die Nutzung in Java, Angular, React oder Vue. Es bietet einerseits eine große Anzahl an bereits designten UI-Elementen, wie Buttons, Listen, Formulare und eben auch Charts an. Andererseits werden auf der Seite auch sogenannte Layouts angeboten, die diese UI-Elemente nicht in der Standard-Ausstattung, sondern in extra abgestimmten Farben erstrahlen lassen. Das Design ist auf Business-Web-Auftritte abgestimmt und wirkt minimalistisch elegant. Die Charts decken klassische Business-Fälle. So gibt es z.B. ein Organigramm. Kompliziertere Datenvisualisierungen sucht man allerdings vergebens. Die Charts sind sehr interaktiv gestaltet. Oft kann man Regionen z.B. ein- und ausblendbar gestalten.

Flexibilität als entscheidendes Kriterium

Man kann die Dokumentationen der zahlreichen Charting-Libraries lange nach ähnlichen Problemen, die dem im eigenen Projekt gleichen, durchsuchen. Womöglich findet man sogar genau das passende Diagramm, welches man mithilfe der Dokumentation schnell und einfach umsetzen kann. Jedoch braucht es lediglich einen einzigen Kundenwunsch, der eine Änderung mit sich bringt, die in der Library nicht umsetzbar ist. Außerdem wird man – außer bei ausschließlich ganz klassischen Diagrammtypen – selten eine Bibliothek finden, die alle Kundenwünsche bzw. Designvorgaben abdeckt. Daher ist es relativ wichtig auf die Flexibilität der einzelnen Librarys zu achten. Je mehr man im Code selbst verändern kann, desto eher werden sich Kundenwünsche und Designvorgaben umsetzen lassen.

Flexibilität und Einsteigerfreundlichkeit – AMCharts bietet beste Schnittmenge

In Sachen Flexibilität kann definitiv AMCharts mit den meisten Möglichkeiten aufwarten. Auf den ersten Seiten der Dokumentation wirkt die Personalisierung noch sehr umständlich. Wenn man jedoch im Umgang mit den enthaltenen Funktionen warm wird, merkt man, welches Potenzial diese Bibliothek hat. Von der Farbe, Größe und Lage der einzelnen Datensätze, über die Platzierung und das Styling von verschiedensten Beschriftungen und Symbolen, lässt sich vieles personalisieren.

Google Charts stellt sich von Anfang an recht flexibel dar. Es bietet allerdings in der Tiefe betrachtet bei weitem nicht so viele Personalisierungsmöglichkeiten wie AMCharts. Gerade die Möglichkeit, nicht nur Unicode-Zeichen, sondern auch diverse Icons in die Beschriftung von Charts einzubringen, hat mir bei Google Charts sehr gefehlt.

Einziger Pluspunkt auf Seiten von Primefaces Charts: Die Charts und Teile der Charts bekommen CSS-Klassen zugeordnet, wodurch in CSS zusätzliches Design vorgenommen werden kann und man sich einige Zeilen in JavaScript erspart. Die Auswahl an möglichen Charts ist aber um Weiten geringer als bei Google Charts oder AMCharts.

Offline-Fähigkeit und andere Nachteile der Gratis-Nutzung

Auf Empfehlung eines Kollegen startete das Projektteam in meinem Projekt mit der Nutzung von Google Charts. Wir setzten bereits nahezu alle Diagramme mit der Library um. Wenngleich wir auch einige Einbußen gegenüber dem Design machen mussten (z.B. keine Möglichkeit der Nutzung von Icons in der Beschriftung der Charts), dachten wir nicht über einen Wechsel nach, da diese Einbußen für die Kundin bzw. den Kunden akzeptabel waren. Erst in einer späteren Projektphase stießen wir auf ein Problem, welches uns zu einem Wechsel der Bibliothek zwang.

Google Charts ohne Offline-Fähigkeit

Google Charts bietet keine Möglichkeit, die Charts offline zu nutzen, sondern verlangt andauernden Zugriff auf auf Google Servern befindlichen minimierte JavaScript-Files, wo sich die Logik der Library befindet. Weder kann man die Files herunterladen und in das Projekt einbinden, noch lässt sich ein einfacher Workaround dazu finden. Man kann diese Files zwar im Browser anzeigen lassen, während der Generierung eines einzelnen Diagramms werden aber zig verschiedene dieser Files vom Google Server aufgerufen und es lässt sich nicht nachverfolgen, welche Files man kopieren und einbinden müsste. Die kostenlose Library hat ihren Preis: Google möchte über diese Verbindung womöglich Daten sammeln.

AMCharts mit Logo-Link zur Website

Auch bei AMCharts gibt es einen Nachteil, solange man die Bibliothek gratis verwenden möchte. Im linken unteren Bereich des Charts wird das Logo von AMCharts angezeigt, welches außerdem ein Link zur Webseite der Bibliothek ist. Dieser Nachteil ist allerdings meiner Ansicht nach wesentlich angenehmer zu ertragen als ein Verlust der Offline-Fähigkeit wie bei Google Charts. Zudem kann er mittels Kauf der Nutzungsrechte umgangen werden. Auch die Kundin bzw. der Kunde in meinem Projekt haben sich für diese Lösung entschieden. Die Applikation soll nicht im Kundinnen- und Kundenbetrieb, sondern lediglich von Mitarbeiterinnen und Mitarbeitern genutzt werden. In diesem Fall sei das Logo nicht störend.

Primefaces ohne Einschränkungen unter Auflagen nutzbar

Die Komponenten von Primefaces im Allgemeinen (also auch die Diagramme) sind für die nicht kommerzielle Nutzung ohne Auflagen gratis nutzbar. Lediglich für die kommerzielle Nutzung bzw. für die Verwendung von bereits vorab designten Layouts müssen Zahlungen an die Ersteller geleistet werden.

Fazit

Mit der Kenntnis von nur drei Diagramm-Bibliotheken für JavaScript kann ich nicht für alle Anwendungsfälle und alle Librarys sprechen. Solange ich mit diesen Tools nicht an meine Grenzen stoße, habe ich aus dem Projekt Folgendes gelernt und werde die Bibliotheken wie folgt in zukünftigen Projekten nutzen.

Bildet das Design sehr simple Diagramme ab, die sich mit der Palette an Möglichkeiten von Primefaces umsetzen lässt, und ist das Projekt nicht für die kommerzielle Nutzung geplant, so wähle ich Primefaces Charts. Die Flexibilität von Primefaces reicht womöglich ohnehin aus. Außerdem wird einem ein tolles Gesamtpaket an weiteren Designelementen geboten, die mit dem Design der Diagramme übereinstimmen und ebenso genutzt werden können. Die Dokumentation ist übersichtlich und die Elemente sind einfach zu nutzen.

Verlangt das Projekt kompliziertere Diagramme bzw. besondere Änderungen von geläufigen Graphen, so greife ich zu AMCharts, welches eine gute Dokumentation zur Manipulation der Elemente bietet. Der Einstieg verlangt ein wenig Übung. Danach hat man allerdings ein mächtiges Werkzeug zur Umsetzung von Datenvisualisierungen in der Hand.

Mit Google Charts könnte doppelte Arbeit auf einen zukommen!

Von der Nutzung von Google Charts würde ich abraten. Der Einstieg ist zwar einfacher als bei AMCharts, jedoch bietet es nicht so viel Flexibilität. Die Tatsache, dass die Library nicht offline verwendbar ist, bereitet wohl in einigen Anwendungsfällen große Umstände. Man stelle sich ein Szenario vor, wo die Kundin bzw. der Kunde erst im Laufe des Projektes angibt, dass die Applikation offline verfügbar sein muss. Spätestens dann muss bei Google Charts die Chart-Library gewechselt und die Visualisierungen ein weiteres Mal mit einer anderen Bibliothek umgesetzt werden.

The post Google Charts vs. AMCharts vs. Primefaces – Mein Data Viz-Library Einsteigerduell appeared first on Mobile USTP MKL.

Agiles Arbeiten ebnet den Weg für testgetriebene Entwicklung

Im Agilen Manifest, welches im Jahre 2001 von den Begründern der agilen Software Entwicklung formuliert wurde (Beck et al., 2001), nannte man testgetriebene Entwicklung neben  Kundenakzeptanztests als eine der beiden wichtigsten Testpraktiken. Auch beim Extreme Programming ist testgetriebene Entwicklung eine zentrale Instanz (Khanam & Ahsan, 2017). Somit rückten die Vertreter agiler Methoden in den letzten Jahrzehnten auch das Test Driven Development (TDD) ins Rampenlicht.

Testgetriebene Entwicklung sieht den bisher sehr verbreiteten Code then test-Ansatz als veraltet an, bei dem das Programm zunächst entwickelt wird und im Nachhinein die Tests dazu erstellt werden. Viel effektiver sei es, die Testfälle jeweils für einen kleinen Teil des Programms im Vorhinein zu entwickeln. Der darauffolgend geschriebene Programmcode wird so lange bearbeitet, bis die Tests erfolgreich abschließen. Nach jeder kleinen Erweiterung des Programms (Increment) wird der Code refactored, um die Tests nicht nur mit einem grünen Häkchen zu versehen, sondern auch gute Code-Qualität zu erreichen (Shull et al., 2010).

Khanam und Ahsan (2017) merken an, dass es wichtig sei, zwischen Unit Testing und der Gesamtheit des Test Driven Developments zu unterscheiden. Unit Testing garantiert das Verhalten von Code, während TDD darüber hinaus maßgeblich die Entwicklung der Software beeinflusst.

Dieser Test-First-Ansatz sei laut Erdogmus et. al (2005) das zentrale Element von testgetriebener Entwicklung. Außerdem sei wichtig, dass die Tests von derselben Person bzw. von demselben Team entwickelt würden, die auch den Code zur Lösung des Tests schreiben. Damit setzt es sich klar von der Cleanroom-Technik ab, wo zwar auch Tests vor der Entwicklung der Software erstellt werden, die Tests jedoch von einem eigenen Team mithilfe von zukünftigen Nutzerinnen und Nutzern durchgeführt werden und statistischer Natur sind. Meist sind die Tests bei Test Driven Development eher mit geringem Aufwand erstellt und decken lediglich die Funktionalität der zu erfüllenden User Stories ab.

Dieser Artikel fasst die Ergebnisse einiger wissenschaftlicher Arbeiten zum Thema testgetriebene Software-Entwicklung zusammen und präsentiert die Stärken und Schwächen. Den Abschluss bildet ein Fazit und eine Bewertung der Effektivität von Test Driven Development.

Auswirkungen auf die Qualität des Produkts

Forrest Shull und seine Kolleginnen und Kollegen haben in ihrem Artikel, erschienen in der IEEE Software (2010), bereits zahlreiche Studien zur testgetriebenen Entwicklung erfasst und deren Ergebnisse ausgewertet.  In Anbetracht von acht Pilotstudien, sechs überwachten Experimenten und sieben Branchenstudien kommen sie zu dem Schluss, dass die Ergebnisse von über 60 % der Studien (13 Werke) auf eine Verbesserung durch Test Driven Development (TDD) hindeuten. Sechs Arbeiten stellen keinen Unterschied zwischen den bisherigen Programmierpraktiken und TDD fest. Nur zwei Arbeiten behaupten, eine Verschlechterung zu erkennen.

Aber was macht testgetriebene Entwicklung so erfolgreich? Zunächst liefert es direktes Feedback. Tests, die vor der Entwicklung eines Features geschrieben wurden, bieten der Programmiererin / dem Programmierer sofortige Rückmeldung, ob die Funktionalität des Features erreicht wurde und ob sich die neue Funktionalität auf bisherige negativ auswirkt, sprich ob bereits implementierte Funktionalität bei der Implementierung der neuen Funktionalität beschädigt wurde (Erdogmus et al., 2005; Khanam & Ahsan, 2017).

Durch Test Driven Development wird das Schreiben von Tests ein zentraler Teil der Entwicklung. Es wird nicht erst im Nachhinein eingeplant oder gar darauf verzichtet. Es treten weniger Fehler auf und das Projekt wird somit effizienter (Maximilien & Williams, 2003).

TDD lässt das Entwicklerteam den Code in lösbare, ausführlich formulierte Aufgaben herunterbrechen, was den Fokus auf die Funktionalität erhält und den Fortschritt besser messbar macht (Erdogmus et al., 2005; Khanam & Ahsan, 2017). Außerdem bringt es die Entwicklerinnen und Entwickler dazu, von Beginn an von einer Endnutzer-Perspektive aus zu denken (Khanam & Ahsan, 2017).

Testgetriebene Entwicklung trägt zur Qualitätssicherung bei. Wenn man zahlreiche Tests auf dem neuesten Stand parat hat und diese regelmäßig ausführt, garantiert dies ein gewisses Grundlevel an Qualität des geschriebenen Programmcodes (Erdogmus et al., 2005). Die Tests können als Dokumentation dienen (Khanam & Ahsan, 2017). Durch die regelmäßige Testung des Increments werden Spätfolgen bei einer Zusammenführung der Features am Schluss vermieden (Maximilien & Williams, 2003).

Es unterstützt außerdem das architekturelle Design der Software, indem anhand der Funktion, die getestet werden soll, Entscheidungen über den Aufbau der Klassen und Methoden, deren Nomenklatur und deren Schnittstellen mit Fokus auf die Funktionalität getroffen werden können (Erdogmus et al., 2005; Khanam & Ahsan, 2017; Maximilien & Williams, 2003).

Refactoring ist ein wichtiger Aspekt, der durch testgetriebene Entwicklung erleichtert wird. Es beschreibt das Verändern von bereits existierendem, funktionierendem Code, ohne die Funktionalität zu verändern. Das Ziel ist es, die interne Struktur des Codes zu verbessern. Dieser Refactoring-Prozess dient dazu, nach der Erfüllung der Akzeptanzkriterien, sprich der Erfüllung der Tests, die Qualität des Codes zu erhöhen. Mithilfe von Test Driven Development kann das Refactoring ohne Angst vor Verlust des Funktionsumfangs durchgeführt werden, da die Tests die Funktionalität des Codes absichern (Astels, 2003; Khanam & Ahsan, 2017).

Kent Beck schreibt in seinem Werk Test Driven Development By Example (2003), dass dieser Effekt des Testens und des Refactorings sogar so wichtig sei, dass es sich lohne, dafür Aufwand zu betreiben. Für bessere Testmöglichkeiten zahle es sich aus, die Code Struktur zu verändern und somit testbar zu halten, wenn das mit der bisherigen Struktur nicht gewährleistet wäre (z.B. zu große Test-Fälle).

Für David Astels (2003) sei es vor allem wichtig, dass TDD, gemeinsam mit dem Einsatz agiler Methoden einen denken-bevor-man-handelt-Ansatz forciert. Außerdem führe der Gedanke, wie man gewisse Anforderungen testen kann, zu mehr Testfällen, die das Programm ausfallssicherer machen.

Auswirkungen auf die Produktivität

Es ist anhand dieser zahlreichen Vorteile einfach sich vorzustellen, dass testgetriebene Entwicklung die Produktqualität verbessert. Dass es jedoch auch die Produktivität des Entwicklungsteams erhöht, widerspricht den Stimmen vieler erfahrener Software Experten alter Schule. Entgegen deren Annahme, dass Tests einen Overhead die Zeit und das Budget betreffend erzeugen und deswegen von einem eigenen Qualitätssicherungsteam durchgeführt werden sollen, biete TDD laut Erdogmus et al. (2005) auch klare Vorteile für die Produktivität des Teams, wenn es direkt von den Entwicklerinnen und Entwicklern durchgeführt wird.

So ergibt die Auswertung des Experiments in der Arbeit von Erdogmus et. al (2005) einen linearen Zusammenhang zwischen der Anzahl der Tests und der Produktivität des Teams. Dies sei auf ein besseres Verständnis der Aufgabenstellung, einen besseren Fokus auf die Funktionalität, schnelleres Lernen aus und Ersetzen von falsch gewählten durch effektivere Strategien und weniger Aufwand beim Ausbessern von Fehlern zurückzuführen. Diesen geringeren Aufwand belegt auch das Experiment von Maximilien and Williams (2003), bei dem durch Anwendung von TDD 50% weniger Fehler im Programm aufgetreten sind. Der Einsatz von TDD mag den Entstehungsprozess zunächst verlangsamen, unterstützt das Team aber und treibt die Produktivität auf lange Sicht gesehen an (Khanam & Ahsan, 2017).

In der Arbeit von Erdogmus et al. (2005) kommen die drei Autoren sogar zu dem Schluss, dass die Auswirkung von Test Driven Development (im Vergleich zu normalem Software Testing nicht im Vergleich zur Entwicklung ohne Testung!) auf die Qualität schwieriger nachgewiesen werden kann und bestätigen nur die Auswirkung auf die Produktivität des Teams. Warum die Andeutung auf eine Verbesserung der Qualität des Produkts so undeutlich ausgefallen ist, erklären die Autorinnen und Autoren unter anderem dadurch, dass der Umfang des beobachteten Programmes zu klein gewesen sei und in dieser Größenordnung auch die Erfahrung und Design-Fähigkeit des Entwicklungsteams eine große Rolle spielen könnten. So können die Entwicklerinnen und Entwickler bei kleinen Applikationen etwa mit Leichtigkeit selbst den Funktionsumfang eines Features überblicken und durch Ausprobieren manuell testen, bevor die Tests nach der Entwicklung ergänzt werden.

Aber auch bei der Produktivität käme es auf das Team und dessen Erfahrung an, wie sehr sich jene steigern lässt. Da testgetriebene Entwicklung ein gewisses Grundverständnis benötigt und einer komplexen Implementierung bedarf, gelangen unerfahrene Entwicklerinnen und Entwickler zu einem geringeren Anstieg der Produktivität (Erdogmus et al., 2005). Die oben genannte anfängliche Verlangsamung könnte bei unerfahrenen Teams größer ausfallen.

Für testgetriebene Entwicklung ungeeignete Systeme

Aus den oben genannten Punkten lässt sich schließen, dass Test Driven Development nicht für jedes Projekt geeignet ist. Khanam und Ahsan (2017) erwähnen einige Beispiele:

Wenn das System Design zu Beginn der Entwicklung noch nicht klar ist.  Die Änderung des Designs während der Entwicklung würde eine ständige Überarbeitung und Anpassung der Tests an die neue Funktionalität bedürfen und damit in einem großen Zeitverlust resultieren (siehe auch: Dogša & Batič, 2011).

Nicht alle Systeme lassen sich an eine Testumgebung mit Unit Tests anpassen und es könnte mehr Zeit kosten, die Tests und das System aneinander anzupassen, als der Vorteil der Tests an Zeit und Qualität wieder einbringt. In solchen Sonderfällen ist also auch Vorsicht geboten. Jedoch sei laut Beck (2003) ein größerer Aufwand in der Implementierung der Testumgebung durch den Vorteil, den diese Testungen bringen, durchaus gerechtfertigt.

Wenn die gewählten Programmiersprachen und Frameworks keine sinnvollen Unit-Testing-Frameworks unterstützen, wird sich die Implementierung von TDD womöglich als schwierig herausstellen. Genauso ist die Testung von grafischen Userinterfaces deutlich schwieriger und zeitaufwändiger als die Testung von Libraries und APIs.

Wie bereits im Kapitel Produktivität genannt, kommt es auch auf die Erfahrung der Entwicklerinnen und Entwickler an. Nicht jede Entwicklerin bzw. jeder Entwickler ist ein erfahrener Test- und Refactoring-Experte. Dabei kann TDD die Produktion verlangsamen.

Khanam und Ahsan (2017) schlagen aufgrund dieser genannten Fälle vor, Test Driven Development beim Einbau an das System anzupassen und nicht das System so zu verändern, dass sich TDD anwenden lässt.

Fazit

Testgetriebene Entwicklung stellt, mit zahlreichen Belegen (Erdogmus et al., 2005; Khanam & Ahsan, 2017; Maximilien & Williams, 2003; Shull et al., 2010), eine Verbesserung für den Entstehungsprozess in Anbetracht von Software Qualität und Team-Produktivität dar. Es bedeutet im Entwicklungsprozess des Systems einen wiederverwendbaren und erweiterbaren Bestand an Tests zu generieren, der die Qualität des Software Systems über dessen Lebenszeit stätig verbessern wird (Maximilien & Williams, 2003). Der Anstieg der Software Qualität gegenüber der traditionellen Software Testung kann in wenigen der in dieser Arbeit beschriebenen Studien wie in der Pilotstudie von Erdogmus et al. (2005) nicht belegt werden, jedoch könnte dies laut Erstellerinnen und Erstellern und auch laut Khanam und Ahsan (2017) am Versuchsaufbau derartiger Pilotstudien zu diesem Thema liegen.

Im Einzelfall bedarf es womöglich einer Abwägung, ob Test Driven Development für die jeweilige Umgebung geeignet ist. Khanam und Ahsan (2017) nennen da einige Beispiele (siehe Kapitel 4 Ungeeignete Systeme). Für manche Projekte könnten andere ähnliche Methoden wie Behaviour Driven Development (BDD) oder Acceptance TDD (ATDD) passender sein.

Gerade der als größter Nachteil zu erwartende Zeitaufwand stellt sich zumindest bei erfahrenen Teams als Vorteil heraus, steigert die testgetriebene Entwicklung doch letztendlich die Produktivität des Teams (Erdogmus et al., 2005).

Testen trägt zur Qualität der Software und das Framework Test Driven Development zur Produktivität des Teams bei. Bei der Entscheidung über den Test-Last- oder den Test-First-Ansatz (wie in TDD) sind die jeweiligen Gegebenheiten des Projekts zu bedenken und sich für ein passendes Framework zu entscheiden. Jedoch ist eine ordentliche Integration von Testungen in den Entwicklungsalltag eines Produkts durch die zahlreichen oben genannten Vorteile in jedem Fall empfehlenswert.

Quellen

Astels, D. (2003). Test-driven development: A practical guide (3. print). Prentice Hall PTR.

Beck, K. (2003). Test-driven development: By example. Addison-Wesley.

Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for Agile Software Development. Manifesto for Agile Software Development. https://agilemanifesto.org/

Erdogmus, H., Morisio, M., & Torchiano, M. (2005). On the Effectiveness of the Test-First Approach to Programming. IEEE Transactions on Software Engineering, 1(31), 14.

Khanam, Z., & Ahsan, M. N. (2017). Evaluating the Effectiveness of Test Driven Development: Advantages and Pitfalls. 12(18), 12.

Maximilien, E. M., & Williams, L. (2003). Assessing test-driven development at IBM. 25th International Conference on Software Engineering, 2003. Proceedings., 564–569. https://doi.org/10.1109/ICSE.2003.1201238

Shull, F., Melnik, G., Turhan, B., Layman, L., Diep, M., & Erdogmus, H. (2010). What Do We Know about Test-Driven Development? IEEE Software, 27(6), 16–19. https://doi.org/10.1109/MS.2010.152

The post Die Effektivität von Test Driven Development appeared first on Mobile USTP MKL.