Mein Blog ist jetzt nicht wirklich relevant. Aber den Bots ist das natürlich egal. Damals bin ich dann irgendwie auf ein Plugin gestoßen, das als “Virenscanner” für WordPress beworben wurde. Dummerweise kommt jetzt jeden Tag ein Email-Report, wie viele “Angriffe” dieses Plugin wieder “abgewehrt” hat. Für mich bedeutet das, dass ich immer ein latentes Gefühl von “Unsicherheit” habe. Wordpress ist die eine Software, die sich ja automatisch aktualisiert und daher einen eher geringeren Angriffsvektor bietet, allerdings gibt es dann doch das ein oder andere Plugin, was ich nutze und sicher halten muss, … ...

Diese Woche war ich in einem zweitägigen Führungskräfte-Training, das sich mit effektiver Kommunikation nach oben beschäftigt hat. Ein Thema hat mich dabei besonders zum Nachdenken gebracht: strukturierte Berichterstattung. Nicht, weil ich bisher keine Berichte geschrieben hätte - ganz im Gegenteil. Aber die Art, wie ich es gemacht habe, war vermutlich nicht optimal. Die Situation Seit einiger Zeit führe ich mit meinen Product Ownern regelmäßige monatliche Berichtsmeetings durch. Das Format war bisher ziemlich informell: Ein mündlicher Rundumschlag über die wichtigsten Themen der letzten Wochen, die aktuellen Herausforderungen und was in den nächsten Wochen ansteht. Anschließend habe ich das Ganze in einem Protokoll in Aufzählungsform festgehalten - mehr schlecht als recht strukturiert, wenn ich ehrlich bin. ...

Heute möchte ich über eine Methode sprechen, die ich “Random Refactoring” nenne, und darüber, wie wir als Führungskräfte die richtigen Rahmenbedingungen dafür schaffen können. Die Methode Der Ansatz ist denkbar einfach: Öffne eine zufällige Datei im Projekt. Analysiere kritisch, was sich verbessern lässt. Führe ein klassisches Refactoring dieser Stelle durch (ggf. Tests schreiben, verbessern, …). Was auf den ersten Blick nach Chaos klingt, hat sich für mich als effektiver Weg erwiesen, die Code-Qualität kontinuierlich zu verbessern. Nebenbei bemerkt kann man sich auch beim zufälligen Auswählen helfen lassen, z. B. mit der “Inspect Code”-Funktion im IntelliJ-Menü “Code”. ...

Als Entwicklungsleiter stelle ich mir häufig die Frage: Wie gut testen wir eigentlich wirklich? Eine hohe Code-Coverage ist zwar schön, sagt aber wenig darüber aus, ob unsere Tests tatsächlich alle wichtigen Testfälle abdecken. Hier kommt Mutation Testing ins Spiel. Die Idee dahinter ist einfach aber genial: Der Code wird automatisch an verschiedenen Stellen “mutiert” (verändert) und dann werden die Tests ausgeführt. Wenn die Tests diese Änderungen nicht erkennen, haben wir eine Lücke in unserer Testabdeckung gefunden. ...