Aus der Werkzeugkiste, Teil 6: Rabea Gransberger
Rabea Gransberger arbeitet als Java-Entwicklerin, Projektleiterin und Abteilungsleiterin bei MEKOS in Bremen. Sie hat die Java User Group Bremen gegründet und hält Vorträge auf Java-Konferenzen. Welche Werkzeuge sie tagtäglich nutzt, erzählt sie im sechsten Teil unserer Tool-Interview-Reihe.
- Rabea Gransberger
Wir bitten in der Werkzeugkasten-Serie mehr oder minder bekannte Entwickler, anhand von Kategorien wie Codegenerierung, Editor/IDE, Debugging, Codeanalyse, Unit Testing, Integration Testing, Code Coverage, Building, Deployment und Continuous Integration zu erzählen, welche ihre präferierten Werkzeuge sind.Den Auftakt machten Philip Ackermann, Golo Roden, Oliver Zeigermann, Adam Bien und Sebastian Daschner. Nun lassen wir Rabea Gransberger zu Wort kommen.
Bestes Tools für einen einfachen Programmieralltag
In der Zusammenarbeit mit unseren Kunden ist es mir wichtig die Hintergründe einer Anfrage genau zu verstehen, um eine optimale und qualitativ hochwertige Lösung anbieten zu können. Dazu gehört es auch mal "Nein" zu sagen, um einen anderen Vorschlag zu unterbreiten. Dafür ist es erforderlich ein breites Wissen der Domäne des Kunden aufzubauen. Ich verstehe mich nicht nur als Softwareentwicklerin, sondern auch als Beraterin.
Bei der Programmierung benötige ich die besten Tools, um zumindest diesen Teil der Arbeit so einfach und angenehm wie möglich zu gestalten.
Codegenerierung & Editor/IDE
Neue RCP-Projekte richten wir grundlegend manuell beziehungsweise über die von Eclipse angebotenen Hilfsmittel ein. Für das Erstellen einzelner Entities, DAOs und einiger Oberflächenelemente verwenden wir Eclipse EASE. Hiermit kann ich neue Aktionen für das Eclipse-Kontextmenü in Skriptsprachen wie JavaScript schreiben und in Eclipse integrieren, ohne dass ich extra ein Plug-in entwickeln muss. Die Skripte erstellen mir zum Beispiel eine RCP "View" mit unserem grundlegenden Aufbau und Berechtigungen und tragen diese auch direkt in die plugin.xml ein.
Excel kommt bei mir gerne für die Generierung der Beans zum Erstellen von CSV-Dateien zum Einsatz. Häufig bekommen wir die Spezifikationen für die CSV-Dateien in PDF-Dokumenten, die Tabellen mit Spaltenname, Feldlänge et cetera enthalten. Diese lassen sich gut nach Excel kopieren. Mit der Funktion "Verketten" kann man rund um diese Spalten, in weiteren Spalten, Java dazu "generieren" und das Ergebnis dann in den eigenen Sourcecode kopieren.
Die Generierung von Sourcecode kommt bei uns jedoch nicht für Getter, Setter, Equals, Hashcode und toString zum Einsatz. Lombok ermöglicht die Generierung von Boilerplate-Code, also Code der sowieso immer gleich aussieht, direkt als Bytecode. Statt über Eclipse den benötigten Sourcecode zu generieren, reicht die Annotation @Data an der Klasse. Getter, Setter, Equals, Hashcode und toString sind magisch zur Laufzeit und in der IDE vorhanden, ohne dass der Sourcecode lang und unlesbar wird.
Ich verwende nicht nur aufgrund der RCP-Entwicklung Eclipse bei MEKOS, sondern gerne auch privat. Leider sehe ich häufig, dass die IDE nur als besserer Editor verwendet wird. Ich finde es wichtig, dass man sich einen halben Tag Zeit nimmt, um die "Tipps & Tricks"-Seiten der jeweiligen IDE durchzulesen. Dadurch lernt man die verfügbaren Einstellungen kennen und kann diese entsprechend den Vorgaben des Projekts anpassen. Wenn man Feldnamen wie m_Name und m_Street verwendet, sollte man den Präfix m_ der IDE mitteilen, damit er zum Beispiel bei der Generierung von Gettern und Settern weggelassen wird und man getName erhält.
Mit Eclipse Oomph (auch bekannt als Eclipse Installer) kann man diese Einstellungen auch über die Workspaces oder mit dem ganzen Team teilen. Die Installation einer neuen IDE-Version ist mit allen selbst festgelegten Einstellungen und gegebenenfalls dem Check-out von Sourcecode aus Git in weniger als fünf Minuten fertig.
Debugging & Codeanalyse
Ich verwende den Debugger in Eclipse. Besonders schön finde ich das Feature "Hot Code Replace", das es mir ermöglicht, kleinere Fehler im Code zu beheben, ohne die Anwendung neu starten zu müssen. Für den Debugger verwende ich folgende Einstellungen: In der "Variables"-Ansicht lasse ich mir die Spalten "Value", "Declared Type" und "Actual Type" anzeigen. Die "Value"-Spalte stelle ich so ein, dass immer toString angezeigt wird. Für Objekte, die keine toString-Implementierung besitzen, kann man per Kontextmenü einen "Detail Formatter" hinzufügen, der einem die benötigten Informationen ausgibt. So habe ich immer alle nötigen Informationen zu den Variablen im aktuellen Kontext direkt in der Tabelle dargestellt.
Statt System.out.println für Debugging-Zwecke im Code hinzuzufügen (und dort zu vergessen), kann man das auch über "Conditional Breakpoints" erreichen. Nach dem Setzen eines Breakpoints im Kontext-Menü "Breakpoint Properties" auswählen, auf "Conditional" setzen, das gewünschte "Sysout" eingeben und danach "return false", damit der Debugger nicht anhält.
Gerne verwende ich in der "Debug"-Ansicht auf dem Stack im Kontextmenü die Funktion "Drop to Frame". Diese sorgt dafür, dass der Stack oberhalb des gewählten Elements verworfen und der Code ab der gewählten Methode erneut ausgeführt wird. Das erspart einem das Neustarten der Anwendung, wenn man durch unbedachtes Nutzen von "Stepping"-Shortcuts zu weit in der Ausführung vorangesprungen ist.
Für die Analyse und Qualitätssicherung des Code bei MEKOS verwenden wir SonarQube und das entsprechende Eclipse-Plug-in. Außerdem hat unser Azubi den Einsatz von jQAssistant zum Erstellen architekturbasierter Regeln geprüft. Das Tool liest den Code in eine Neo4j-Graphdatenbank ein. Mittels der Abfragen in der Neo4j-Sprache Cypher lassen sich komplexe Regeln formulieren: Im Hinblick auf Java 9 kann man zum Beispiel prüfen, dass ein Package nicht zweimal in verschiedenen Modulen vorkommen darf.
Bei privaten Projekten verwende ich gerne FindBugs (oder den Fork SpotBugs). Schön finde ich hier die zu einem Bug angezeigten Erklärungen, wie man es besser machen könnte. Das hat mir besonders als Anfängerin geholfen. Zusätzlich zu den statischen Codeanalyse-Tools führen wir Code Reviews durch, um sicherzustellen, dass der Code auch les- und somit gut wartbar ist.
Verwandt mit der Codeanalyse ist für mich auch das "Error Reporting". Kunden melden leider nicht alle Fehler, die in der Anwendung auftreten. Da wir eine Desktop-Anwendung entwickeln, können wir die Logdateien oft nicht an einer zentralen Stelle ablegen und darüber auswerten. Daher haben wir in unserem log4j-basierten Logging den Appender von "Ctrlflow" hinzugefügt. Fehler werden darüber zusätzlich an den Ctrlflow-Server gemeldet, der unter anderem auch eine Stack Trace Deduplication durchführt. Über ein Dashboard und E-Mail-Reports sind wir nun immer über aktuell auftretende Fehler informiert.
