Boehrsi.de - Blog

Über die letzten eineinhalb Jahre habe ich mein erstes professionelles Projekt geleitet und heute möchte ein kleines Fazit ziehen. Vielleicht ist für den einen oder anderen ein hilfreicher Tipp dabei oder vielleicht habt ihr Tipps, wie man in diesem Bereich noch besser werden kann. Über Kommentare freue ich mich wie gewohnt sehr.
Ich bin gerne ein Entwickler, soll heißen ich schreibe wirklich gerne Code, doch auf der anderen Seite koordiniere und plane ich tatsächlich auch recht gerne. Letztes ist glaub ich extrem wichtig wenn es darum geht ein Team und ein Projekt zu leiten. Denn sofern man keine Ambitionen in diesen Bereichen hat, sollte man lieber bei der reinen Entwicklung bleiben. Grund dafür ist die massive Verschiebung der Aufgaben und die entsprechend veränderte Zeitverteilung. Sofern einem dann der Verwaltungsteil gar nicht gefällt, wird man vermutlich schnell unzufrieden sein.
Wie erwähnt finde ich aber durchaus Gefallen daran und war froh mit dem genannten Team arbeiten zu dürfen. In Retrospektive denke ich damit steht und fällt generell alles, also ob das Team allgemein und menschlich funktioniert. Erst darauf kann man dann auf professioneller Ebene etwas aufbauen. Wir hatten das Glück das es passte und mit einer recht guten Wissensverteilung (2x Android, 2x iOS, 1x Testing) konnten wir eine Flutter App entwickeln, welche mit genügend Platform-Background versorgt wurde.

Ich schreibe seit ca. 15 Jahren Software und seit 5 Jahren ist es mein täglicher Vollzeitjob Programme zu entwickeln. In dieser Zeit fallen einem verschiedene Dinge auf und man lernt extrem viel. Vor kurzem wurde ich von einem Kollegen, der gerade den Sprung von der Uni ins Berufsleben vorbereitet, gefragt wie ich Projekte angehe und Entscheidungen in der Starphase treffe. Während ich meine Ansichten und Ideen mit ihm teilte dachte ich mir, dies könnte auch ein gutes Thema für den Blog sein und hier sind wir nun.
Meiner Meinung nach ist der Anfang eines Projekts, noch bevor man überhaupt über die Architektur nachdenkt, einer der wichtigsten Momente. Denn ich denke man sollte ein Projekt initial mit der richtigen Plattform, Technik und Sprache aufziehen. Hier gibt es natürlich Limitierungen bezüglich dem eigenen Wissen oder dem Wissen des Teams, aber man muss z.B. nicht einen Blog, einen Shop, einen Hausbootverleih und eine Dinosaurierzucht mit Wordpress bauen. Natürlich bietet es um drei Ecken die Möglichkeiten, aber ihr nehmt ja wahrscheinlich auch keine Rohrzange, um damit Nägel in die Wände zu kloppen.
Soll heißen, nur weil man etwas tun kann, heißt dies nicht dass es gut oder gar der beste Weg ist. Hier gilt auch über den Tellerrand zu schauen und vielleicht die Chance zu nutzen und etwas Neues lernen. Dabei ist es mir sehr wohl bewusst, dass dies gerade im professionellen Umfeld durchaus kompliziert und nicht immer machbar ist. Doch einige Minuten des Nachdenkens zu investieren und vielleicht Vorschläge für neue und passende Ansätze zu unterbreiten dürfte selten falsch sein.

Im Rahmen der Software-Entwicklung nutzt man oft Libraries, Tooling und andere Dinge die man selbst nicht komplett durchdringt. Dies ist zu bestimmten Teilen auch in Ordnung und an der Tagesordnung, doch manchmal ist eine Software-Blackbox ein extremes Problem.
Doch definieren wir erst einmal Blackbox. Für mich ist eine Blackbox im Software-Bereich eine Komponente, die man selbst nicht durchdringt und die nicht mit akzeptablem Zeitaufwand, aus welchen Gründen auch immer, verstanden werden kann. Gründe sind hier, auch wenn es sich um Open Source Software handelt, andere Programmiersprachen, zu komplexe Konzepte, fehlende Dokumentation oder ähnliches. Closed Source Software ist natürlich per-se eine Blackbox.

Wann ist eine Blackbox aber nun ein Problem? Meiner Meinung nach wenn sie grundlegende Konzept abstrahiert oder zu essentielle Abläufe übernimmt und dem Entwickler dabei nicht klar ist was wann passiert und warum. Nimmt man z.B. das Build-Tool Gradle open_in_new, so hätte man vielleicht eine Blackbox vor Augen. Diese funktioniert allerdings sehr gut, es gibt eine sehr umfangreiche Dokumentation und auch weitere Ressourcen sind vorhanden. Hier muss man also Vorsicht walten lassen bei Updates und ähnlichem, falls man nicht durchdringt was dies bedeuten könnte. Doch durch vorhandene Dokumentation kann man sich entsprechend und mit akzeptablem Zeitaufwand schlau machen. Insofern würde ich persönlich nicht von einer Blackbox reden, wenn es um Gradle geht.
Hat man nun aber ein derartig wichtiges Tool (z.B. für die Build-Toolchain) oder eine Library die grundlegende Funktionen der eigenen Software übernimmt (z.B. Netzwerk-Interaktionen oder die Implementierung von Protokollen) und eine derartige Informationsquelle ist nicht gegeben, kann man sich in große Probleme manövrieren.

Es ist wieder soweit, nachdem es einige Monate keine Top 10 Liste gab, ist sie nun wieder am Start. Zuletzt gab es diverse Serverprobleme und zusätzlich bin ich leider auch noch vergesslich, sodass diese News häufig ausfiel. Doch sowohl der Server, wie auch mein Gehirn, laufen aktuell rund und entsprechend findet ihr im unteren Teil der News die am meisten gelesenen Beiträge des Monats Mai, absteigend sortiert.

Auch wenn die Umstände dieses Jahr etwas unschön sind und wir alle eher zuhause als unterwegs sein sollten, wünsche ich trotzdem allen Besuchern frohe Ostern. Genießt die hoffentlich ruhige Zeit, telefoniert mit Freunden und Familie und passt auf euch auf.
Etwas Ruhe hier und da kann dem einen oder anderen sicherlich auch mal ganz gut tun, in dieser durchaus schnelllebigen und speziellen Zeit.

Lasst uns doch kurz noch das Framework / die Library aktualisieren. Ein Satz den sicherlich der eine oder andere Softwareentwickler schon häufiger von sich gegeben hat. Vermutlich auch kurz vor einem Release, selbst wenn man eigentlich weiß, dass das vielleicht riskant ist. Aber man testet ja, überprüft nochmal die bekannten Flows und eigentlich sieht ja alles ganz gut aus oder?
Nein, einfach nur nein. Auch wenn es vielleicht von Zeit zu Zeit funktioniert, vor einem Release machen wir sowas einfach nicht. Egal ob es ein Update auf die nächste IDE Version ist, eine aktualisierte Library oder gar eine frische Framework Version, am Ende gibt es immer etwas was man nicht überprüft hat.
Erst heute habe ich diese Lehre wieder gezogen. Denn ich arbeite seit langem mit der aktuellen Beta Version des Flutter Frameworks, um einige Funktionen bereits testen zu können. Nun ergab sich das für ein Projekt, welches eigentlich auf dem Flutter Stable-Branch lebt, eben dieser Beta-Branch ein Problem löst. Da ich schon lange auf selbigem unterwegs bin, entschied ich - wenn auch mit einem mulmigen Gefühl - wir versuchen es mit dem Beta-Branch. Alles in allem habe ich ja schon viel getestet und was soll schon passieren?

Es ist schon wieder etwas her das ich eine News in diesem Bereich geschrieben habe, doch nun wird’s mal wieder Zeit. Denn aktuell grübele ich bezüglich einem Thema, bei welchem ich nicht zu einem optimalen Entschluss komme. Es geht um die Menge der zu verwendenden Guards bzw. Sicherheitsmechanismen, um eine fehlerfreie User Experience zu gewährleisten.
Generell sind wir Softwarenentwickler uns bestimmt einig, dass das User Interface und alles was der Nutzer darin zu sehen bekommt, eher robust sein sollte und entsprechend Fehler gut abfangen muss. Doch wie weit soll man gehen, wenn es darum geht die UI und Logik gegen fehlerhafte APIs zu schützen, die man selber mehr oder weniger unter Kontrolle hat. Ich rede hier von Schnittstellen die auf dem Gerät in Form von Bibliotheken vorhanden sind, nicht von externen APIs, die z.B. auf entfernten Servern liegen (letztere sollten definitiv umfangreich und effektiv abgesichert werdern). Denn auch selbstverwaltete Bibliotheken, welche vielleicht von einem Kollegen der aktuell keine Zeit hat gepflegt werden, können hin und wieder Fehler beinhalten.
Ich bin ein Fan von Fail Fast & Fail Often, denn meiner Meinung nach gehen ansonsten zu viele Fehler unter. Doch wie geht man mit mehr oder weniger bekannten Issues um, welche in darunterliegenden Ebenen vorhanden sind, die teilweise zum eigenen Code gehören.
Baut man Guards ein - vielleicht auch nur temporär - können selbige in Vergessenheit geraten und später das Debugging massiv erschweren. Lässt man die Fehler zu, kann es zu sichtbaren UI Fehlern kommen, was natürlich zu vermeiden ist. Ich persönlich sehe hier eine Zwickmühle, welche ich zwar nicht perfekt, aber für mich für den Moment passend lösen konnte.

Auch wenn es im Kontext Corona wesentlich relevantere Informationen gibt, Boehrsi.de ist und bleibt ein Technik Blog und entsprechend versuche ich in diesem Bereich aktiv zu sein und überlasse die gesundheitsbezogenen Inhalte den Profis.
Doch nun zum eigentlichen Thema dieses Beitrags, der Verschiebung der DroidCon Berlin 2020. Wenig überraschen wird das Event nicht wie geplant im Sommer (01. bis 03. Juli) stattfinden. Stattdessen plant man aktuell die Konferenz im Herbst nachzuholen.
Der konkrete Plan sieht den 07. bis 09. Oktober vor, allerdings ist dieses Datum natürlich nur unter Vorbehalt gesetzt. Aktuell dürften die wenigsten konkret abschätzen können in welche Richtung die aktuelle Situation größere Events verschiebt und wann bzw. ob sie wirklich zeitnah nachgeholt werden können. Solltet ihr aber so wie ich gerne zum Event wollen, haltet euch Anfang Oktober ein paar Tage frei, mit etwas Glück sieht man sich in Berlin.

• Droidcon Website open_in_new

Es ist zwar schon Mitte März, aber vielleicht interessiert es ja den einen oder anderen was im Februar besonders beliebt war hier im Blog. Die Top 10 Liste der am meisten angeschauten Beiträge findet ihr wie immer im unteren Teil der News. Sortiert wird absteigend nach Anzahl der Aufrufe.
Dieses Mal gibt es wieder eine bunte Mischung aus Gaming- und Coding-Themen, was mich sehr freut, denn beide Themenbereiche liegen mir sehr am Herzen. Falls ihr wünsche zu Themen, Schwerpunkten oder anderen Dingen hier im Blog habt, meldet euch gerne direkt unter dieser News in den Kommentaren.

Corona ist als Thema aktuell in aller Munde und ich hätte nicht gedacht, dass es selbst hier in meinem IT und Gaming Blog zum jetzigen Zeitpunkt relevant wird. Vorweg, keine Sorge, ich bezweifle das ich Corona habe, aber auch mich betrifft die aktuelle Epidemie. Denn eigentlich wäre ich jetzt gerade in den Niederlanden und würde die Appdevcon genießen.
Doch durch die aktuelle Situation wurde das Event auf den September verschoben open_in_new. Meiner Meinung nach die richtige Entscheidung, denn Reisen und Events mit vielen Menschen auf engem Raum, welche mitunter auch aus Risikogebieten kommen, ist eben keine gute Idee.
Das Ganze macht einen definitiv nachdenklich. Denn während man versucht weder zu den ignoranten, noch zu den hysterischen Teilen der Bevölkerung zu gehören, so hat man ja trotzdem eine gewisse Distanz. Spürt man nun die Auswirkungen, wenn auch nur durch abgesagt Events am eigenen Leib, macht es die Situation doch etwas wirklicher und gleichzeitig surrealer.
Ich hoffe das Ganze legt sich eher früher als später wieder und ich hoffe vor allem auf eine gewisse Portion gesunden Menschenverstand. Denn am Ende könnte durch panisches und unüberlegtes Handeln durch den Menschen, die Situation noch um ein vielfaches schlimmer gemacht werden. Und als abschließende Randnotiz, wer auch immer das gesamte Klopapier aufkauft, ich find’s scheiße.

• Appdevcon Website open_in_new