-
Werkzeuge zur Erhaltung der Softwarearchitektur – JUnit / Selenium / JaCoCo – Teil 8
JUnit / Selenium / JaCoCo Die zweite Werkzeuggruppe zur Erhaltung der Code-Qualität und Architektur sind Tests. Ich nenne hier nur einige Plugins, die wir primär einsetzen. Es gibt aber noch viele, viele andere. Die Verwendung von Tests stellt die Zielerreichung sicher. Es wird mit dem Test ein Sollverhalten definiert und die entsprechende Umsetzung geprüft. Somit […]
-
Werkzeuge zur Erhaltung der Softwarearchitektur – Task Scanner / Open Tasks – Teil 7
Task Scanner / Open Tasks Viele von uns erstellen jeden Tag – häufig automatisiert – technische Schulden und kennzeichnen diese sogar bewusst. Gemeint sind hier die vielen Code-Stellen mit “TODO” oder “FIXME”. Dies sind klassische Punkte, die nicht fertig gestellt wurden und damit in die technischen Schulden fallen. Grundsätzlich sollte sichergestellt werden, dass solche Einträge […]
-
Werkzeuge zur Erhaltung der Softwarearchitektur – Werkzeugintegration und -konfiguration – Teil 6
Werkzeugintegration Die Tools zur Vermeidung technischer Schulden können auf verschiedenen Ebenen in die Entwicklung eingebunden werden. Entwicklungsumgebung In der Entwicklungsumgebung erhalten wir bei der täglichen Arbeit direkt Feedback zu Problemen. Beim Speichern und automatischen Kompilieren der Dateien werden Marker erstellt, die Probleme im Quellcode kennzeichnen. Durch dieses direkte Feedback können wir bei der Entwicklung umgehend […]
-
Werkzeuge zur Erhaltung der Softwarearchitektur – Team / Software / Automatisierungsprobleme – Teil 5
Dies ist der letzte Post, bevor ich zu den eigentlich Werkzeugen für die Vermeidung technischer Schulden komme. Er behandelt verschiedene Rahmenbedingungen für die Vermeidung technischer Schulden. QS im Team Egal ob wir innerhalb eines Scrum-Teams entwickeln oder ein Softwarearchitekt für die Organisation zuständig ist: Qualitätssicherung ist immer eine Aufgabe des gesamten Teams. TEAM bedeutet also […]
-
Werkzeuge zur Erhaltung der Softwarearchitektur – Maßnahmen / QS – Teil 4
Im letzten Post haben wir definiert, welche Messwerte wir bezüglich der technischen Schulden erreichen wollen. Dieser Post beschäftigt sich mit den Maßnahmen für deren Umsetzung. Die grundlegenden Aussagen meiner Posts gelten allgemein für die Softwareentwicklung. Die Beispiele beziehen sich hier auf ein Entwicklung auf Basis von JAVA. Reduzierung der Komplexität Es sollen wenige Zyklen und […]
-
Werkzeuge zur Erhaltung der Softwarearchitektur – Messen und Prozesse / QS – Teil 3
Ziel dieser Serie von Posts, ist es darzustellen, wie technische Schulden erkannt werden können. Nach der Erkennung kann man sich häufig an Mustern orientieren, um die Schulden abzubauen. Einige Werkzeuge geben uns Entwicklern auch direkt Lösungen an die Hand. Aber auch bei der Erkennung von technischen Schulden gilt “You get what you measure” – wie […]
-
Werkzeuge zur Erhaltung der Softwarearchitektur – Verstehen von Quellcode / QS – Teil 2
Im letzten Post ging es um die allgemeinen Ziele bei der Architekturerhaltung. Zentraler Punkt hierbei ist das Verstehen des Quellcodes. Das Verstehen bzw. das Einarbeiten in Quellcode macht einen Großteil unserer Arbeit als Entwickler aus (sicherlich mehr als 50%). Beim Verstehen setzen wir das “Chunking” ein. Hierbei fassen wir bewusst oder unbewusst Teilinformationen zu größeren […]
-
Monolith vs. Microservices …
… oder warum nicht jeder Monolith geschlachtet werden muss. Seit einiger Zeit ist der Hype ungebrochen, jedes monolithische System schnell zu ersetzen und jede Neuentwicklung als Microservice-Architektur zu realisieren (eventuell nicht jedes aber doch eine Vielzahl). Problem Mensch Aus meiner Sicht ist eines der Hauptprobleme in der Softwareentwicklung, dass nicht Vorhandensein von (geeigneten) Architekturregeln und […]
-
Werkzeuge zur Erhaltung der Softwarearchitektur / QS – Teil 1
Nach etwas Pause in diesem Blog werde ich nach und nach einige Posts zum “Thema Werkzeuge zur Architekturerhaltung / QS” veröffentlichen. In diesem Post geht es um die QS im Rahmen von Java Projekten. Viele Punkte – aber nicht alle Werkzeuge – sind aber auch auf andere Sprachen zu übertragen. Das Einhalten einer Softwarearchitektur stellt […]
-
Spooky Exceptions (7) – The tag named inputFile from namespace http://xmlns.jcp.org/jsf/html has a null handler-class defined
Umgebung Situation Es kommt folgende ConfigurationException beim Start des Wildfly: Ursache Es wurde eine JSF Implementierung (jar) mit der Anwendung deployed. Diese stört sich mit der durch WIldfly bereitgestellten. Bei der Verwendung von MyEclipse geschieht dies häufiger, da MyEclipse das JSF jar häufig in den deployment descriptor aufnimmt. Ursache Das Deployment des JSF jar verhindern