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.
Weiterlesen…
Ich entwickle gerne Software, sowohl professionell, wie auch privat, doch manchmal gibt es einfach unschöne Aufgaben, nervige Bugs oder andere Situationen auf die man lieber verzichten würde. Die Top 5 der nervigsten Dinge beim Programmieren - für mich persönlich - möchte ich heute im Rahmen einer weiteren I’m a coder News vorstellen.
Unklare / nicht durchdachte Aufgabenstellung: Egal in welchem Kontext, immer mal wieder stolpert man über nicht fertig gedachte Ideen und Ansätze. Daraus resultiert dann oft eine Änderung der eigentlichen Aufgabe, noch während man initial dabei ist. Dadurch ändern sich auch gerne grundlegende Dinge, sodass ordentlich Hirnschmalz benötigt wird, um entsprechende Anpassungen zu machen ohne komplett neu beginnen zu müssen. Solche Dinge kann man durch ordentliche Planung einschränken, aber leider niemals komplett ausschließen. Gerade im privaten Bereich empfehle ich in diesem Kontext alles zu notieren und ein paar Tage reifen zu lassen, denn wenn man blind drauflos schreibt, landet man häufig in besagter Situation.
Trial and Error Bugfixing: Ein Bug wird entdeckt und die Jagd nach Ursache und Lösung geht los. Auf dem Weg zu Lösung gibt es einige Zwischenschritte und manchmal hat man das Pech einen nicht reproduzierbaren und entsprechend auch nicht wirklich lösbaren Bug zu finden. Dabei kann man dann nur herumprobieren, um sich an eine Lösung anzunähern. Ebenso sieht es aus wenn man zwar genau weiß wo das Problem ist, aber eine klare Lösung nicht erkennbar oder gar möglich ist. Somit kann man auch hier nur via Trial and Error Ansatz versuchen das Problem zu lösen. Am frustriertesten finde ich dabei die Menge an Zeit die man investiert ohne Fortschritte zu machen und ohne Code zu erstellten. Meistens kommt man trotzdem zu einer Lösung und alles ist wieder gut, es gibt allerdings definitiv dankbarere Aufgaben. Wirklich tun kann man gegen diese Art von Problemen leider auch nichts, denn diese Art von Bugs kommt bei der Entwicklung einfach auch vor.
Weiterlesen…
Der letzte I’m a coder Beitrag ist schon länger her, was nicht zwangsweise daran liegt das es nicht neues in diesem Bereich bei mir gibt, sondern eher daran das die Beiträge in anderen Sammlungen einsortiert werden. Doch wie ich auch immer, ich habe mal wieder etwas allgemeines, was gut in diese Sammlung passt.
Zuletzt kam ich durch die Droidcon auf das heutige Thema. Es geht um die Aktualisierung von Third-Party-Libraries, welche man in seinen Programmen, Tools oder Apps nutzt. Denn häufig hat man kleine praktische Bibliotheken, die einem Arbeit abnehmen und Funktionen verlässlich und schnell zur Verfügung stellen, ohne dass man das Rad andauernd neu erfinden muss. Ob man dabei alle Nase lang Fremdbibliotheken nutzt oder lieber alles selber schreibt, kommt auf das Projekt und die generelle Einstellung an. Das man bereits eingebundene Libraries aber aktualisieren sollte, sofern man welche nutzt, ist denke ich klar.
Doch warum fällt dies so schwer? Never Change a Running System, denn es funktioniert alles, ist häufig ein guter Grund. Auch häufig ist das fehlende Bewusstsein für diese Bibliotheken, denn wenn alles funktioniert schaut man oft gar nicht mehr nach diesen Inhalten und eventuell verfügbaren Updates. Damit einher gehen dann natürlich diverse Probleme, wie z.B. Abstürze. Unter Android sind häufig Plattformupdates ein guter Grund für ein Update von Libraries, denn oft gibt es nach größeren Systemänderungen Probleme. Doch häufig entdeckt man diese Probleme erst nach längerer Zeit und nach einigen unzufriedenen Nutzern. Reaktiv reagieren ist eben nur eine Notlösung und sollte nicht der permanente Zustand sein.
Weiterlesen…
Wer in der Android-Welt unterwegs ist dürfte bereits über Kotlin gestolpert sein, die neue moderne Sprache von JetBrains open_in_new (IntelliJ und Android Studio Entwickler). Die Sprache kompiliert zu JVM kompatiblen Code und wird offiziell von Google unterstützt. Aufgrund der Herkunft ist natürlich auch Android Studio in der Lage Kotlin Code zu erstellen und zu kompilieren.
Ich persönlich habe mir die Sprache etwas angeschaut und auf der Arbeit einer Kotlin Teaching Session beigewohnt. Die Sprache ist interessant, hat wirklich gute Konzepte und dürfte Boilerplate Code teilweise massiv minimieren. Doch es ist und bleibt eine neue Sprache, die gelernt und vor allem verstanden werden will. Für mich würde Java Programmierung an anderer Stelle weiterhin Pflicht sein (in Projekten abseits von Android), sodass ich diverse Kontextwechsel kompensieren müsste.
Weiterlesen…
Related Links
Eine App sollte keine Crashes produzieren. Diese Aussage ist denke ich für jeden erfassbar und verständlich. Um dies zu erreichen programmiert man natürlich sicher und effektiv. Doch hin und wieder kommt dann doch ein Crash rein und man muss ihn fixen. Doch reicht ein Guard um Crashes / Bugs wirklich zu beheben? Von Zeit zu Zeit sicherlich, doch dies hängt natürlich von der Situation ab und oft ist selbige durchaus komplexer und bedarf etwas mehr Zuwendung. Mit Guard ist in diesem Kontext z.B. ein null Check gemeint, welcher einen Code-Block vor Ausführung schützt.
Weiterlesen…
Die erste I’m a Coder News in diesem Jahr steht an. Thema ist dieses Mal zukunftsorientierte und abstrahierte Programmierung. Ich komme auf das Thema, weil ich zum einen in meinem eigenen Code, wie auch hin und wieder auf der Arbeit, über Dinge stolpere die optimierter sein könnten. Dabei geht es nicht darum eine foreach Schleife statt einer for Schleife zu nutzen. Es geht darum Dinge so zu entwickeln, dass man sie wiederverwenden kann und Code-Duplizierung vermeidet.
Weiterlesen…
Wie der Titel schon sagt geht es heute um PHP. Eine meiner frühen Sprachen, welche ich aktuell noch für Kundenprojekte einsetze und privat im Blog nutze. Begonnen hat alles mit besagtem Blog und Anfang 2008 weitete ich meine PHP Nutzung auf selbständige Kundenprojekte aus. In diesem Rahmen brachte ich mir die Sprache quasi komplett selbst bei. Anders als bei meinem vorherigen Beitrag zum Thema Java. Dies führt natürlich zu einer anderen Herangehensweise, was das Erlernen und das Einsetzen der Sprache angeht. Ich habe viel mit PHP geschrieben, vor allem um 2010 herum. Der Blog, Kundenprojekte, Clan-Websites und diverse andere Dinge setzte ich um und PHP macht mir durchaus Spaß. Ich setzte meistens weniger auf die objektorientierten Komponenten, da PHP für mich meistens lediglich den Datenbank <-> PHP <-> HTML Flow abdeckte und somit nur Mittel zum Zweck war. Gerade bei komplexeren Dingen war Objektorientierung aber durchaus ein Thema. Innerhalb der letzten fünf Jahre wurde es immer ruhiger was PHP angeht, lediglich der große Backend Rewrite meines Blogs und wenige große Kundenprojekte wurden noch mit PHP umgesetzt. Der Blog ist aktuell im Umbau und wird dann zum Großteil ebenfalls auf PHP verzichten. Denn durch Java und vor allem meinen Fokus auf Android, haben sich meine Prioritäten hier stark geändert. PHP ist meiner Meinung nach weiterhin sinnvoll für verschiedene Bereiche, allerdings bin ich in selbigen nicht mehr wirklich unterwegs. Somit vermute ich, dass bis auf einige Ausnahmen PHP zumindest bei mir aussterben wird. Wie sieht das bei euch aus, nutzt ihr PHP noch?
Meine I’m a coder News erfreuen sich recht großer Beliebtheit im Blog, nur komme ich leider mit den Themen nicht hinterher. Ich bin mittlerweile 10 Wochen hinter dem Zeitplan. Bis dato habe ich versucht einfach aufzufüllen, doch leider schaffe ich es nicht die geplante Anzahl an News zu schreiben. Deswegen ändere ich mein Vorgehen ab jetzt etwas. Von nun an versuche ich weiterhin möglichst oft zu schreiben, allerdings nicht mehr gebunden an irgendwelche Kalenderwochen. Dementsprechend ändert sich auch der Aufbau des Titels ein wenig, denn ich versuche ab jetzt das Thema des Beitrags dort direkt mit zu erfassen. Aber das sollte generell egal sein, denn ihr findet weiterhin alle Beiträge in der entsprechenden Newssammlung. Die Umstellung bedeutet im Umkehrschluss natürlich auch, falls Themen und Zeit vorhanden sind, dass mehrere Beiträge pro Woche möglich sind.
Das Rad neu erfinden, ist heute Thema meiner I’m a Coder News. Denn auch wenn man selbiges eigentlich nicht tun sollte und auch nicht will, so passiert es trotzdem häufiger als man denkt. Manchmal einfach aus dem Entwickler-Flow heraus und manchmal da man bestimmte Dinge auch einfach nicht kennt. Denn für vieles gibt es gute und mächtige Libraries, doch man kann niemals alle von ihnen kennen. Aus diesem Grund sollte man vor Grundsatzentscheidungen bei Implementierungen, sich erst einmal schlau machen ob nicht vielleicht stabile und gute Bibliotheken vorhanden sind. Auf der anderen Seite bin ich der Meinung, dass wenn man selber guten Code schreiben kann, ist auch dies nicht verwerflich. Eine Ausnahme ist hier meistens Code der auf Sicherheitsfunktionen bezogen ist, denn hier sollte man sich immer an die Standards halten. Tut man dies nicht, kann dies zu großen Problemen führen. Auch wenn selbiges ebenfalls bei etablierten Implementation passieren kann, ist dort zumindest das Risiko meistens geringer. Ich selber erwische mich von Zeit zu Zeit dabei die genannten Tipps selbst nicht zu beachten, versuche aber mich zu bessern. Vor allem wenn man seinen eigenen alten Code verwendet, ohne ihn noch einmal einem Review zu unterziehen, kann man sich gut selbst in die Falle manövrieren. Also immer über den Tellerrand schauen, seine eigenen Code-Snippets nicht als fehlerfrei ansehen und den guten alten gesunden Menschenverstand auch beim Programmieren nutzen, dann ist man auf einem guten Weg.
Heute gibt es mal wieder eine I’m a Coder News. Das Thema ist simpel, nämlich der Wechsel zwischen verschiedenen Programmiersprachen nach längerer Zeit. Zum einen ist dies interessant und bringt Abwechslung in den Entwickleralltag. Auf der anderen Seite ist es manchmal dermaßen verwirrend, dass man ausflippen könnte. Mein aktuelles Beispiel ist Java und PHP. Ich schreibe viel Code in Java und bin dementsprechend sehr an die Eigenheiten gewöhnt. Seit einiger Zeit habe ich aber mal wieder mehr Berührungen mit PHP und dies war am Anfang wirklich wieder eine große Umstellung. Stichwort ist hier die Syntax, so versuchte ich in PHP Klassen Methoden mit “Objekt.Methode” aufzurufen und habe sage und schreibe 10 Minuten gebraucht, um zu verstehen das “Objekt->Methode” vielleicht sinnvoller wäre. Dinge die mir seit Jahren geläufig sind, haben sich in meinem Kopf teilweise vermischt und vor allem auch Dinge wie “public, private und protected” und die entsprechenden Unterschiede in Java und PHP, haben mir zu schaffen gemacht. Man kommt schnell wieder rein, es ist etwas wir Fahrrad fahren, aber ein paar Mal legt man sich schon hin. Alles in allem läuft es bei mir wieder rund mit beiden Sprachen, aber mir zeigt dies etwas. Entweder man sollte kontinuierlich Sprachen immer mal wieder nutzen oder sie komplett und endgültig verwerfen. Wirklich lange Pausen sind nicht zielführend und eher verwirrend. Was sagt ihr zum Thema und hattet ihr bereits ähnliches Problematiken?