Nachdem in dem letzten Artikel wichtige Kennzahlen aus der statischen Analyse eines Code Reviews betrachtet wurden, werden nun Aspekte der manuellen Analyse beleuchtet. Wie läuft eine Architektur-Analyse bei einem Code Review ab und welche Erkenntnisse können daraus gezogen werden?
Dieser Post baut auf dem vorangegangenen Teil auf. Solltet ihr diesen noch nicht gelesen haben, empfehlen wir, euch einige Minuten Zeit zu nehmen und dies jetzt zu tun.
Wenn man als Java-Entwickler in die Android-Entwicklung einsteigt, ist zunächst vieles aus Java bekannt. Einige Aspekte sind aber auch anders gelöst. So zum Beispiel das Thema Logging. Hier bringt Android seine eigene API mit, die ohne weitere Konfiguration bequem verwendet werden kann. Bei fortgeschrittenen Herausforderungen zeigt dieser Ansatz jedoch seine Grenzen. Hier kann auf vorhandenes Wissen und Bibliotheken aus der Java-Welt zurückgegriffen werden.
Codequalität und -korrektheit lassen sich unter anderem mit Hilfe von Unit-Tests sicherstellen. Aber nicht jeder Unit-Test ist sinnvoll und häufig schaffen es Bugs von Unit-Tests unerkannt zu bleiben. Wie lässt sich die Testqualität erhöhen, um Programmierfehler zuverlässiger und früher zu erkennen?
Beim automatisierten, integrativen Testen von Software, die mit einem komplexen JPA-Datenmodell arbeitet, steht man unweigerlich früher oder später vor der Frage, wie sich semantisch sinnvolle Testdaten ohne großen Aufwand erzeugen lassen. Dieser Artikel zeigt, wie man mit Groovy eine Domain Specific Language (DSL) definieren kann, die es erlaubt, Testdaten leicht lesbar, modular und getrennt vom eigentlichen Test-Code zu definieren.
Das Pipeline Plugin (früher Workflow Plugin) für Jenkins revolutioniert die Arbeit mit Jenkins, indem es das Erstellen von Build Jobs als Code ermöglicht. Dadurch werden Build Pipelines unter anderem wiederverwendbar, versionierbar, testbar und einfacher lesbar als etwas “Zusammengeklicktes“.
Manchmal fragen sich Entwickler: „Was mache ich hier eigentlich?“ Das hat dann nichts mit einer plötzlichen Sinneskrise oder dem Zusammenbruch der persönlichen Weltanschauung zu tun. Vielmehr wacht der innere Softwarearchitekt auf und verlangt nach einer Darstellung des Großen Ganzen.
Sicherheit in Software-Projekten ist ein schwer zu beherrschendes Thema, wie regelmäßig in den Medien erscheinende Berichte über Datenlecks beweisen. Für Software-Entwickler ist es schwer zu überblicken, welchen Einfluss ihre tägliche Arbeit an nicht unmittelbar sicherheitsrelevanten Themen auf die Sicherheit ihrer Anwendung hat.
Der erste Artikel in dieser Serie – „Versionsnamen mit Maven: Erzeugen des Versionsnamens“ zeigt, wie mit Hilfe von Maven während des Builds eine Versionsnummer, angereichert mit weiteren Informationen in eine Manifest-, Properties- oder HTML-Datei geschrieben wird. Darauf aufbauend beschreibt dieser Artikel, wie diese innerhalb der Anwendung ausgelesen wird. Dies ist in vielen Fällen hilfreich: Man sieht sofort, welche Version auf welcher Stage deployt ist, die Versionsangabe kann Missverständnisse in Fehlerberichten vermeiden, etc.
In vielen Fällen kann es hilfreich sein, einer Anwendung ihre aktuelle Versionsnummer entnehmen zu können: Man sieht sofort, welche Version auf welcher Stage deployt ist, die Versionsangabe kann Missverständnisse in Fehlerberichten vermeiden, etc.
80% der Lebenszykluskosten von Software entfallen auf Wartung. Keine Software wird von nur einem Entwickler betreut. Deswegen ist es entscheidend, dass der Code in einer gut verständlichen und nachvollziehbaren Art und Weise geschrieben ist. Code Conventions helfen, dabei das zu erreichen.
Obwohl Apache Shrio mit seinen WildcardPermissions ein mächtiges und flexibles Werkzeug zur feingranularen Vergabe von Berechtigungen mitliefert, stößt man damit bei komplexen Szenarien an Grenzen. Dieser Artikel zeigt, wie sich beliebige Berechtigungsprüfungen über das Permission-Interface selbst implementieren lassen.
