Boehrsi.de - Blog

Und wieder ist ein Monat vergangen. Der April ist vorbei und im unteren Teil dieser News findet ihr die beliebtesten Beiträge des letzten Monats. Selbige sind absteigend nach Anzahl der Klicks sortiert und bieten euch einen guten Überblick, darüber was es in der letzten Zeit an Beiträgen gab. Sowohl alte bekannte, wie auch recht aktuelle News sind dabei.

Nachdem ich bereits ein paar Worte darüber verloren habe, warum ich meine Services selbstgeschrieben habe, geht es heute mit den Anforderungen und der generellen Architektur weiter. Als ich vor zwei Jahren meine Java Services schrieb, war das Thema Microservices natürlich auch in meinem Kopf sehr aktiv. Das Resultat damals waren zwei komplett unabhängige Services, für die Suche und die Kommentare. Alles unabhängig, was natürlich seine Vorteile hat, aber eben auch Nachteile.
Die Nachteile wollte ich mit meinen neuen Diensten eliminieren, denn wenn man schon erneut auf der grünen Wiese startet, soll das Ganze natürlich auch ordentliche Verbesserungen bringen. Insgesamt überlegte ich mir die folgenden Anforderungen, welche auf meinen Erfahrungen mit meinen bis dato aktiven Services beruhen.

Ich habe schon oft über die Services, welche die Such- und Kommentarfunktion hier im Blog zur Verfügung stellen, gesprochen. Das ich selbige selbst entwickelt habe wurde auch schon oft breitgetreten, aber auf die Interna bin ich bis dato noch nicht eingegangen.
Dieser Beitrag macht nun den Anfang und ist der Start für eine neue News-Sammlung. Heutiges Thema soll die Frage sein, warum ich die genannten Services selber entwickelt habe und nicht einfach vorhandene Lösungen genutzt habe. Im allgemeinen lässt sich die Frage recht einfach beantworten, denn ich bin ein Softwareentwickler. Entsprechend baue ich meine Software falls selbiges sinnvoll ist, gerne selbst. Doch warum hatte ich in diesem Fall das Gefühl es wäre sinnvoll?

Eigentlich möchte man defensiv programmieren und entsprechend dem Nutzer möglichst viele Fehler vom Leib halten, das macht auch Sinn. Doch Workarounds und Fallbacks über und über einzusetzen, sodass man irgendwann eher Probleme einbaut als sie zu verhindern, ist meiner Meinung nach schlimmer als ein ordentlich kommunizierter Fehler. Als Beispiel würde ich hier ein Auto nehmen. Es hat Benzin im Tank und falls selbiger bald leer ist fährt man zur Tankstelle. Sollte diese geschlossen sein, macht es Sinn zur Sicherheit einen Kanister mit Benzin auf Reserve zu haben. Was aber eher wenig Sinn macht, ist alle zufällig herumstehenden Kanister des Nachbarn in den Tank zu schütten und zu hoffen es war Benzin dabei. Mit diesem Vorgehen hat man vielleicht in wenigen Fällen Glück, meist ist es aber eher eine wenig zielführende Idee.

Wie schon im letzten Jahr, ist Ostern auch dieses Jahr eher gewöhnungsbedürftig. Ich hoffe trotzdem, dass ihr das lange Wochenende zum entspannen nutzen könnt und ein paar schön Tage habt. Genießt die hoffentlich ruhige Zeit, telefoniert mit Freunden und Familie und passt auf euch auf.
Ich wünsche auf jeden Fall allen Besuchern frohe Ostern und freue mich darauf euch bald wieder hier im Blog mit neuen Inhalten begrüßen zu dürfen.

Da ist der März schon wieder vorbei und Ostern steht vor der Tür. Das bedeutet, es ist mal wieder Zeit für die monatliche Top 10 News. Die Liste der beliebtesten Beiträge des Monats März findet ihr wie gewohnt im unteren Teil der News. Sie ist sortiert nach der Anzahl der Aufrufe in Absteigender Reihenfolge. Es gibt wie gewohnt eine Mischung als älteren aber beliebten Artikeln und aktuell relevanten Artikeln. Schaut doch mal rein.

Ich hatte schon häufiger das Thema der Codequalität hier im Blog und habe dafür geworben selbige hochzuhalten. Soll heißen bestehenden Code auch mal zu modernisieren, während der Entwicklung Dinge zu optimieren, statt zu duplizieren und Fehler die man zwischendurch entdeckt direkt zu beheben. Es gibt noch viele, viele weitere Möglichkeiten die Codequalität zu steigern, doch darum soll es heute gar nicht gehen.
Ich wollte mal konkret mitteilen warum ich es für wichtig halte nicht nur links und rechts Dinge anzubauen, sondern eben auch das große Ganze im Blick zu behalten. Ich habe vor kurzem die Ehre gehabt in ein halbwegs umfangreiches Projekt eine neue Funktion einzubauen, welche auf bestehender Logik aufsetzt und diese erweitert. An sich war der Ansatz recht simple, denn es sollte einfach ein bestehender Flow erweitert und mit verschiedenen Kontexten erneut ausgeführt werden. Alle anderen Abläufe, die auf diesem bestehenden Flow aufsetzen, mussten entsprechend angepasst werden, sodass sie den neuen Kontextbezug auch erfassen. Generell wäre das ein Aufgabe für einige Tage gewesen, allerdings wurde alles wesentlich umfangreicher.

Schon ist wieder ein Monat vergangen und entsprechend wird es Zeit den letzten Monat im Kontext des Blogs zusammenzufassen. Diese tue ich wie gewohnt in Form einer Top 10 Liste. Diese beinhaltet die am meisten von euch gelesenen Beiträge im besagten Monat. Die Liste findet ihr absteigend nach Anzahl der Aufrufe sortiert im unteren Teil der News. Dieses Mal sind diverse aktuelle Themen und ein paar Dauerbrenner mit von der Partie.

Der Januar ist schon wieder vorbei und entsprechend wird es wieder Zeit die Top 10 zu erfassen. Die Liste der beliebtesten Beiträge des letzten Monats findet ihr wie gewohnt im unteren Teil der News. Sie ist nach Anzahl der Aufrufe absteigend sortiert. Neben dem einen oder anderen Dauerbrenner-Beitrag sind auch diverse aktuelle Beiträge mit von der Partie.

Was macht eigentlich einen guten Entwickler aus? Über viele Punkte kann man hier sicherlich streiten, aber nach diversen Gesprächen mit Kollegen und befreundeten Softwareentwicklern, habe ich den einen oder anderen Punkt zusammengetragen, bei dem wir uns einig waren. Hierbei sollte vorab erwähnt werden, dass diese Liste natürlich nicht vollständig ist.
Beginnen möchte mit der guten alten Annahme, dass weniger Code immer besser ist, was definitiv nicht der Fall ist. Natürlich sollte man unnötigen Code vermeiden, aber manchmal ist es besser ein paar Zeilen extra zu schreiben, die klar machen warum eine Abfrage geschieht, statt unklare Konstrukte einfach so stehen zu lassen. In solchen Fälle erstelle ich lieber eine gut benannte Methode, spare mir Kommentare, halte den Code in einem wartbaren Zustand und füge entsprechend einige Zeilen extra hinzu. So wenig wie möglich, aber so viel wie nötig, um alles verständlich und wartbar zu halten.
Neu ist immer besser und Never change a running system, zwei Sprüche die bestimmt schon jeder Entwickler mal gehört hat. Beide entsprechen zum Teil der Wahrheit, sollten aber immer hinterfragt werden.
Ersterer ist meist der Einstieg, um ein neues Framework oder eine neue Library zu nutzen, was oft spannend ist, aber nicht immer sinnvoll. Hier sollte man wohlüberlegt handeln und sich nicht von coolen Buzzwords blenden lassen. Auch neue Techniken sollten grundlegend zu bestehenden Ansätzen und Konzepten passen und vom gesamten Team getragen werden.
Auf der andere Seite steht das Gegenteil, denn Never change a running system ist gerne die maskierte Aussage “das haben wir schon immer so gemacht, das ändern wir doch jetzt nicht mehr”. Vor allem als Entwickler der lange in einem Bereich mit bestimmten Techniken gearbeitet hat, sollte man trotzdem immer ein offenes Ohr für neue Ideen haben. Denn nur weil man Senior Developer o.ä. ist, heißt dies nicht das ein neuer Junior nicht vielleicht gute Ideen hat. Auch hier gilt abwägen ist wichtig, aber zuhören und offen sein sollte man immer.