Boehrsi.de - Blog

Es wird mal wieder Zeit für eine I’m a coder News und das heutige Thema werden Reviews sein. Selbige sind extrem wichtig für die Qualität einer Software, welche mitunter maßgeblich durch die eigentliche Codequalität definiert wird. Denn vor allem über längere Zeit ist Software mit guter Codequalität besser wartbar, erweiterbar und erlaubt einen einfacheren Einstieg für neue Entwickler. Reviews sind wichtig, doch auch schwierig und zeitaufwendig. Entsprechend gehen sie manchmal unter, werden nur halbherzig gemacht oder sind zu streng bzw. zu nachsichtig. Hier einen guten Mittelweg zu finden ist schwer, aber extrem wichtig. Nachdem man die eigentlichen Änderungen verstanden und die Funktionalität überprüft hat, folgt der meiner Meinung nach schwerste Teil. Denn nun muss man die Validierung bezüglich der Einhaltung von Coding Guidelines und Naming Vorgaben durchführen.

In der letzten Zeit Wechsel ich oft zwischen Programmiersprachen, Projekten und Frameworks hin und her. Grund dafür ist unter anderem Flutter open_in_new als neues Framework für professionelle und private Projekte, aber auch Kotlin open_in_new als moderner Ersatz für Java. Nun hat man aber auch aktive Projekte (auch wenn ich mein Projekt FileSize gerade beendet habe) und entsprechend puren Java Code oder Android Projekte mit Java Basis. Bedenkt man nun noch Libraries die z.B. Annotation Processing betreiben, also z.B. Lombok open_in_new oder ObjectBox open_in_new, so gibt es einiges zu beachten.
Daraus ergibt sich häufiges umdenken und öfters auch Fehler, denn gerade wenn man in ein laufendes, aber nicht so aktiv gepflegtes Projekt schaut, welches viele spezielle Dinge benutzt, optimiert man gerne mal Code aus Unwissenheit weg. So passierte es bei mir, dass ich Default-Konstruktoren entfernte, da sie nicht genutzt wurden, ObjectBox diese aber für den generierten Code und die Initialisierung der Objekte in selbigem brauch. Entsprechend werde ich für mich versuchen für nicht implizit klare Dinge wieder mehr auf Kommentare zu setzen. Normalerweise schreibe ich quasi keine Kommentare und sorge dafür dass der Code für sich selbst spricht, doch nutzt man mehrere komplexe Libraries die Boilerplate Code entfernen, kann häufig die Klarheit des Codes leiden.
In einem solchen Fall hat man also einen Vorteil durch weniger Code, aber auch einen Nachteil durch weniger klare Codestrukturen. Kommentare können hier hilfreich sein und ohne viele unnötige Zeilen Code diese Wissenslücke füllen. Mich würde interessieren, wie ihr derartige Dinge löst. Verzichtet ihr generell auf Tools, die zu viel Codestruktur abstrahieren bzw. verbergen oder nutzt ihr andere Ansätze, bzw. schreibt ihr lieber mehr Boilerplate Code, solange selbiger dann besser verständlich ist?

Für wiederkehrende Leser dürfte mein Android-Entwickler-Hintergrund mittlerweile bekannt sein, für alle anderen die Information: Ich entwickle unter anderem Android Apps. In diesem Bereich gibt es extrem viele gute Libraries, die einem Aufgaben in allen möglichen Bereichen abnehmen, gut gepflegt sind und extrem viel Zeit sparen.
Die externen Abhängigkeiten sollten dann aber natürlich auch verwaltet, geprüft und aktualisiert werden. Libraries die nicht mehr unterstützt werden, sollten ausgetauscht werden und auch generell sollte man immer ein Auge auf Code haben, welchen man in seine Projekte integriert. Ein gewisser Zeitaufwand ist auf lange Sicht also auch hier zu erwarten.
In diesem Kontext bin ich aber durchaus positiv eingestellt, wenn es um externe Abhängigkeiten geht. Doch mittlerweile wirkt es so, als könnte man vieles zu einfach mit Libraries lösen, denn für teilweise die kleinsten Aufgaben werden komplette Library-Konstrukte integriert und nie wieder mit nur einem Auge betrachtet. Dies gilt für komplexe Dinge, wo Libraries meiner Meinung nach Sinn machen, aber auch für die trivialsten Dinge. Denn eine Abhängigkeit hinzufügen und einfach eine Methode aufzurufen, ist halt immer noch leichter als 5-6 durchdachte Zeilen selbst zu schreiben.
Viele Libraries können hilfreich sein, aber die Selbstverständlichkeit mit welcher, unabhängig von der genutzten Plattform, Programmiersprache oder der Build-Umgebung, Abhängigkeiten überall integriert werden, lässt mich teilweise mit dem Kopf schütteln. Der finale Auslöser dieses Beitrags ist meine Web-Entwicklung mit dem Static-Site-Generator Hugo open_in_new und die damit verbundene Idee warum ich Hugo wählte. Ich arbeite mit Hugo, weil es schnell und einfach funktioniert und dabei eine einzelne ausführbare und aktualisierbare Datei ist. Ohne Abhängigkeiten, ohne 5-Stufigen Build-Prozess, Downloads, Setups, Updates und was man sonst noch alles aufführen könnte.
Ich habe mir ein durchaus komplexes Theme gebaut, kann aber verstehen wenn man bereits fertige nutzen möchte. Was auf meinem Server, für eine andere - nicht von mir entwickelte Website - gerade getan wird. Die Hugo-Webseiten auf dem Server werden mit einem kleinen automatisierten Script, was ich geschrieben habe, gebaut und ich war verwirrt als mir vom Ersteller der Seite mitgeteilt wurde, dass seine Seite nicht erfolgreich erstellt wird.

Während ich aktuell mal wieder in der Android-Welt unterwegs bin (leider noch mit Java, aber mein nächstes Projekt wird Kotlin) fällt mir mal wieder auf wie wichtig es ist bei Plattformen, Frameworks und auch Programmiersprachen am Ball zu bleiben. Seit dem letzten Update meines aktuellen Projekts ist einige Zeit vergangen und es gibt einfach unfassbar viel nachzuholen. Auf der einen Seite ist dies schön, denn ich habe nun neue Möglichkeiten, auf der anderen steigt die Menge an Änderungen langsam in unangenehme Bereiche (Stichwort: Regressions).

Das Internet bietet viele Möglichkeiten und vor allem als Softwareentwickler ist es die Basis die eigene Software zu verteilen und eine breitere Masse zu erreichen. Dies ist sehr positiv, aber es gibt auch diverse Schattenseiten in diesem konkreten Bereich, die ich heute einfach mal ansprechen möchte.
Mir geht es vor allem um die Art und Weise wie mit Software und Apps umgegangen wird, wenn mal etwas nicht funktioniert. Dabei sollte man vor allem im Hinterkopf behalten, dass man die meiste Software in diesem Bereich gratis bekommt und genau auf diese möchte ich speziell auch eingehen. Hier bekommen Nutzer also kostenlos Software, die ihnen hilft, sie unterhält oder was auch immer für einen Zweck hat und der jeweilige Nutzer entdeckt ein Problem.

Heute gibt es mal wieder neue Geschichten aus der Welt der Softwareentwicklung. Denn am Wochenende war ich mal wieder fleißig und wollte Googles Bitte nach einem Update meiner Android App FileSize nachkommen. Selbige ist aktuell meine einzige gelistete PlayStore App open_in_new und es wurde mal wieder Zeit die Target-Android-Version anzupassen.
Im Rahmen dieser Aktualisierung dachte ich es wäre eine gute Idee Abhängigkeiten zu aktualisieren, Gradle open_in_new einem Update zu unterziehen und diverse kleinere Aufräumarbeiten durchzuführen. Außerdem wollte ich einen seit langem existierenden Bug beheben und ein neues Feature einbauen. Hier und dort gab es bei diesem Plan natürlich Probleme, doch das eigentliche Problem, welches auch Thema dieses Beitrags ist, ist Vergangenheits-Daniel und im Ernst der nervt mich wirklich.

Während der Software Entwicklung lernt man viel, teils in Bezug auf neue Programmiersprachen und ähnliches und teils allgemeine Dinge. Zu letzteren zähle ich so etwas wie: “Keine IDE Updates kurz vor einem Release”, nicht “einfach so Libraries aktualisieren” und “das sollte einfach so funktionieren” ist meistens nicht wahr. Die Liste geht noch weiter, quasi unendlich lang, doch worum es mir geht ist diese Lesson Learned auch anzuwenden.
Wir wissen diese Dinge, doch wir vergessen, wir sind im Stress und missachten eigentlich klare Abläufe und dadurch machen wir Fehler. Ich selber habe erst vor kurzem auf meinem privaten System ein Update von IntelliJ Idea 18.1 auf 19.2 gemacht, ohne auch nur eine Sekunde über aktuelle Projekte nachzudenken. Dies wurde natürlich prompt damit quittiert, dass das Projekt nicht mehr baute und ich erstmal das Projekt und die IDE debuggen musste, statt ein neues Feature zu entwickeln.
Um Lessons Learned anwenden zu können muss man sich erst einmal an sie erinnern, somit hilft es im ersten Schritt sie aufzuschreiben. Egal ob in einem Wiki oder auf einem Post-It am Monitor, man sollte den für sich persönlich richtigen Platz finden. Denn hier geht es vor allem um Sichtbarkeit im Alltag. Im nächsten Schritt versuche ich aktuell meine Aufzeichnungen zu bestimmten Kontexten von Zeit zu Zeit erneut zu betrachten, denn was hilft die beste Dokumentation, wenn man sie nicht liest. Um die entsprechenden Dinge dann final anwenden zu können bleibt eigentlich nur der gesunde Menschenverstand. Nicht überstürzt handeln, Backups erstellen, erst prüfen ob z.B. mit Updates Probleme bekannt sind und ähnliches kann helfen Probleme zu vermeiden. Auch Automatisierung in Form von Skripten oder ähnlichem kann hier und da vor Fehlern schützen. Generell fasse ich für mich die Abläufe in Document (z.B. Wiki), Repeat (regelmäßig erneut lesen), Apply (denken und anschließend handeln) und Protect (Skripte, Berechtigungen restriktiv setzen) zusammen.
Mich würden eure Lesson Learned im Bereich der IT interessieren und ich würde mich freuen einige in den Kommentaren finden zu können, denn wir alle lernen nicht aus.

Niemand weiß alles und deswegen ist es in der Softwareentwicklung meiner Meinung nach sehr wichtig eine aktive Community zu haben. In einer solchen kann man sich bezüglich der genutzten Sprache, Frameworks und ähnlichen Dingen austauschen. Denn auch wenn es Dokumentationen gibt, die erklären wie man performant eine Sprache nutzt oder wie man in einem Framework konkrete Use-Cases umsetzen kann, so gibt es zu viele unterschiedliche Aufgaben, als das alles dokumentiert sein könnte.
Community-Portale wie Stack Overflow open_in_new, Gitter open_in_new oder auch öffentliche Slack oder RocketChat Channels bieten hier eine Möglichkeit sich asynchron oder synchron auszutauschen und sich gegenseitig zu helfen. Vor allem Stack Overflow dürfte fast jedem Entwickler ein Begriff sein, denn z.B. im Android Bereich findet man quasi alles was man braucht dort.

Obwohl ich aktuell eigentlich viel im Coding Bereich zu sagen hätte, komme ich zurzeit leider nicht wirklich dazu umfangreiche I’m a coder Beiträge zu erstellen. Doch heute nehme ich mir, bei entspannten 32°, einfach mal wieder etwas Zeit.
Thema ist heute die Erstellung von Grafiken und Diagrammen zur Erklärung von Konzepten oder Abläufen innerhalb von Software. Denn wer kenn es nicht, man hat Software entwickelt, verschiedene Konzepte und Ansätze angewendet und dann vergehen einige Monate und vieles gerät in Vergessenheit oder aber ein neues Teammitglied möchte eingearbeitet werden. Bei mir trifft aktuell beides zu, denn bei meinen privaten Projekten vergesse ich durch häufige Kontextwechsel gerne Dinge und auf der Arbeit versuche ich gerade neue Kollegen in mein aktuelles Projekt einzubinden.

Es wird mal wieder Zeit für eine I’m a Coder News und heute ist das Thema die Architektur einer Software. Einer der Themenbereich in denen ich in den letzten Jahren wohl am meisten gelernt habe, allem voran auf der Arbeit, aber auch im privaten von eigenen Projekten. Der Aufbau der Architektur mag nach Arbeitsaufwand aussehen, aber selbiger lohnt sich meiner Meinung nach immer.
Selbst bei kleinen App gibt es immer mal wieder Momente in denen man Dinge erweitern oder ändern will und hat man eine stabile Basis geschaffen, also eine gute Grundarchitektur erstellt, geht dies um ein vielfaches leichter als bei einem großen Klumpen Software. Ebenfalls praktisch ist eine gute Architektur im Bereich Dokumentation, denn gerade bei privaten Projekten bleibt die Doku oft auf der Strecke und nach ein paar Monaten versteht man den eigenen Code nicht mehr. Hat man hier aber mit einem verständlichen Entwicklungskonzept gearbeitet, findet man viel schneller wieder in existierenden Code hinein.