SonarLint unter IntelliJ IDEA

Statische Codeanalyse ist eine feine Sache. Sie weißt auf Fehler und Probleme schon zur Entwicklungszeit hin. Dafür gibt es unter anderem Systeme wie SonarQube. Wem ein solchen System zu groß ist, der kann SonarLint nutzen, welches statische Codeanalyse lokal in der gewünschten IDE liefert.

sonarlint.org/intellij/

sonarlint.org/intellij/

Für IntelliJ IDEA findet man die passende Version dabei unter sonarlint.org/intellij/. Daneben gibt es auch Versionen für Eclipse und Visual Studio. SonarLint wird dabei mit einem vorgefertigtem Regelsatz geliefert und kann nach der Installation gleich genutzt werden. SonarLint ist unter der GPL in Version 3 (bzw. der LGPL) lizenziert und damit freie Software.

Logs unter Windows mittels BareTail anschauen

Wenn man Logs unter Windows anschauen möchte, so kann man diese natürlich in einem Texteditor öffnen. Einfacher wird es mit dem Tool BareTail. Mit der Applikationen können Logs geöffnet werden, welche anschließend angezeigt werden. Dabei wird auf Wunsch immer zum aktuellen Teil des Logs gesprungen. Die einzelnen Logzeilen können dabei nach bestimmten Kritierien eingefärbt werden, so das die Übersicht gewahrt bleibt.

baremetalsoft.com/baretail/

baremetalsoft.com/baretail/

BareTail unterstützt Dateien mit einer Größe von über zwei Gigabyte und kann mit mehreren Dateien gleichzeitig umgehen. Bezogen werden kann BareTail auf der offiziellen Webseite. Neben der Freeware-Version existiert auch eine Pro-Version mit einem erweiterten Funktionsumfang.

Scrum, Storypoints und Schätzungen

Im Scrum werden größere Aufgaben in User Stories zerlegt. Diese User Stories werden anschließend geschätzt. Dabei wird nicht die Zeit geschätzt welche das Team für die Aufgabe benötigt. Stattdessen wird die Komplexität der User Story geschätzt. Story Points sind dabei die abstrakte Einheit um Komplexität bzw. die Größe der Story einschätzen zu können. Nun ist es für Menschen kompliziert akkurat zu schätzen wo der Komplexitätswert einer User Story liegt. Was Menschen besser können ist es eine User Story mit einer anderen User Story zu vergleichen. Man definiert bzw. nutzt bestehende User Stories als Referenz, welche man bereits bearbeitet hat und weißt ihnen einen Referenzwert zu. Als Werte nutzt man dabei eine modifizierte Fibonaci-Reihe nach dem Schema:

1, 2, 3, 5, 8, 13, 20, 40, 100

Mit Hilfe der Referenz-Stories können nun die neuen User Stories bzw. ihre Komplexität geschätzt werden. Bei der Planung schaut man wie viele Story Points man im letzten Sprint erfolgreich bearbeitet hat und nutzt diese Zahl für die neue Planung. Neben den Referenz-Stories, welche zur Einschätzung der Komplexität dienen, wird während der Planung meist auch Planning Poker gespielt. Kern des Prozesses ist dabei das verdeckte Schätzen der Komplexität. Nachdem die Karten aufgedeckt wurde, erklären die beiden Mitspieler mit der niedrigsten und der höchsten Karte ihre Einschätzung. Anschließend wird das ganze wiederholt, bis das Team eine fundierte Einschätzung der Komplexität vorliegen hat.

Karten für das Planning Poker

Karten für das Planning Poker

Für den Product Owner ist es natürlich wichtig zu wissen, wie viel Zeit die eingeschätzten Tickets benötigen. Dazu bedient man sich des Velocity-Faktors. Dieser ergibt sich aus dem was das Team in den letzten Sprints an Story Points abgearbeitet hat. Wenn das Team in acht Stunden z.B. durchschnittlich 4,3 Story Points abarbeitet, kann der Product Owner die benötigte Zeit abschätzen.

Remote-Branch unter Git umbenennen

Um unter Git einen Branch umzubenennen nutzt man den entsprechenden Terminalbefehl:

git branch -m oldBranchname newBranchname

Damit wird der Branch im lokalen Repository umbenannt. Wenn dieser nun mittels git push auf den entfernten Remote übertragen wird, so entsteht dort ein neuer Branch. Um die Umbenennung auch auf dem Remote durchzuführen muss der alte Branch auf dem Remote gelöscht werden:

git push origin :oldBranchname

Damit wird der alte Branch auf dem Remote gelöscht und die Umbenennung ist abgeschlossenen.

Wildcard-Imports unter IntelliJ IDEA deaktivieren

Unter Java ist es mögliche alle Klassen eines Packages als ganzes zu importieren. Im Quelltext sieht das dann so aus:

import com.example.project.engine.*

Viele IDEs wie auch IntelliJ IDEA fügen diese Wildcard-Imports zu einem Projekt, wenn mehr als eine Klasse (abhängig von den Einstellungen) aus dem Namespace genutzt wird. Unter Umständen ist dieses Verhalten allerdings nicht gewünscht. Möchte man das Verhalten unter IntelliJ IDEA deaktivieren, muss dies in den Einstellungen geschehen.

Die entsprechende Seite in den Einstellungen

Die entsprechende Seite in den Einstellungen

Dort gibt es unter Editor -> Code Style -> Java -> Imports die Einstellung ab wie vielen Klassen ein Wildcard-Import genutzt werden soll. Stellt man hier die Zahl entsprechend hoch ein, so werden keine Wildcards-Imports mehr genutzt.