Dieser Episode beinhaltet keine Notizen

Alex: [00:00:01.95] Willkommen zurück bei eine neue Folge der „Macht der Craft“. Ich moderiere heute diese Folge alleine, weil wir einen ganz besonderen Gast haben wir, der Matthias. Matthias Sag Hallo

Matthias: [00:00:14.91] Hi! Sorry.

Alex: [00:00:17.97] In der heutigen Ausgabe möchte Matthias mit dir teilen, wie es ihm bisher in seiner Laufbahn in der Online Entwicklung ergangen ist. Angefangen bei den unerfahrenen Hochschulabsolventen bis zum begeisterten Softwarecrafter, der er heute ist. Du wirst erfahren, welche Tools, welche Skills er sich im Laufe der Zeit aneignen musste und durfte, um die Herausforderungen auch abseits der Software-Entwicklung selber, also das Programmieren selber zu meistern. Bestimmt ist das eine oder andere dabei, dass dir bekannt vorkommen oder dir auch bei deine Herausforderungen helfen könnte. Viel Vergnügen!

off: [00:01:00.33] Die Macht der Craft arbeitet für dich.

Alex: [00:01:04.95] Softwareentwicklung besteht nicht nur aus Programmieren. Matthias erzählt uns heute über einige Skills und Tools, die er gebraucht hat und warum sie wichtig für ihn waren zu der Zeitpunkt. Natürlich können wir nicht alle Themen hier abdecken, die in der Softwareentwicklung mit involviert sind. Aber machen wir einfach ein Anfang und gucken wir uns einige davon an. Matthias, wie hast du am Anfang deiner Karriere gearbeitet?

Matthias: [00:01:33.99] Ja, das waren noch Zeiten. Das war eben direkt nach dem Studium. Da habe ich in der kleinen Online Agentur angefangen. Wir haben Onlineshops umgesetzt für unsere Kunden und haben die dann eben auch betreut. Und ganz am Anfang meiner Karriere. Also wirklich direkt nach dem Studium war ich mit meinem damaligen Chef alleine. Wir waren zwei Entwickler und haben eben Onlineshops umgesetzt. Und es war eben so, dass wir damals, weil ich es auch nicht besser wusste, sehr rudimentär erst mal gearbeitet haben. Also meine erste Entwicklungsumgebung in Anführungszeichen war zum Beispiel Notepad++. Und da haben wir unsere Projekte, unsere Dateien verändert. Und wenn wir die auf irgendeinem Server bringen mussten, also unser Deployment sozusagen, ist dann über FTP passiert, zum Beispiel. Ja, das war damals am Anfang ne Handvoll Kunden betreut zu zweit und deswegen war das tatsächlich auch praktikabel. Also wie gesagt, mein mein Chef hat immer so schon gearbeitet und ich habe es im Prinzip von ihm so gelernt am Anfang. Also hier hast du deinen Computer hier, wenn du irgendeine Datei verändern muss, dass die hier rein Notepad mach mal so hat es alles angefangen bei uns. Genau.

Alex: [00:02:55.33] Ja, und das war auch ausreichend rudimentär. Aber es hat das gebracht, was ihr gebraucht habt.

Matthias: [00:03:02.70] Genau, ja,

[00:03:03.36] Von daher völlig okay. Aber was war wichtig bei der Nutzung dieser Tools?

Matthias: [00:03:07.65] Naja, wichtig war halt da am Anfang in erster Linie erst mal, dass ich überhaupt mal – weil wie gesagt, ich habe ja auch vorher in der Online Entwicklung überhaupt nichts gemacht. Ich musste dann auch erst mal mich damit auseinandersetzen, was bedeutet es eigentlich, wenn wir einen Onlineshop betreuen? Also wie kriege ich da überhaupt neue Dateien hin und alles mögliche? Also da war dann im Prinzip erst mal so wie funktioniert es überhaupt, dass ich mit FTP, sFTP oder wie es dann eben am Ende des Tages auch heißt, überhaupt eine Datei auf einem System verändern kann, so dass letztendlich im Internet dann auch die entsprechende Version rauskommt. Also das war so am Anfang mein ganz großes Learning, tatsächlich. Weil im Studium haben wir natürlich ja halt so mit C++ ein bisschen Dateien einlesen, Klassen gelernt und dieses und jenes. Aber ich hatte halt meine ersten richtigen Berührungen mit echten Projekten waren genau das erstmal zu verstehen, was bedeutet es überhaupt, wenn du eine Online Anwendung verändern willst? Also was musst du denn da eigentlich machen?

Alex: [00:04:10.92] Wie sah es damals bei euch mit Themen wie Dokumentation? Wie einfach war es Code zu ändern? Wie umfangreich war des Code? Habt ihr Tests geschrieben, um den zu testen? Wie habt ihr diese Themen handgehabt?

Matthias: [00:04:26.52] Also tatsächlich, Tests hatten wir damals gar nicht. Also wir haben. Im Prinzip sind wir so vorgegangen, dass wir, also wir hatten einen gemeinsamen Testserver, den haben wir uns geteilt. Also wir mussten uns dann auch immer, wenn wir auf unserem Testserver irgendwas hochladen mussten wir uns – aber da wir im selben Büro saßen, war das möglich – halt untereinander absprechen und sagen: „Hey, ich will da gerade mal was testen, halt mal du kurz die Füße still zu sozusagen.“ Und wie gesagt so lang zu zweit bist, ist es auch vollkommen okay gewesen. Und dann haben wir eben die Datei hochgeladen, die wir verändert haben. Und haben dann wirklich direkt im Browser geguckt, ob das, was wir erreichen wollten, erreicht worden ist. Es war sozusagen damals unsere Qualitätssicherung. Du hast es einfach direkt im Browser ausprobiert.

Alex: [00:05:14.01] Das heißt nicht, dass ihr nicht getestet habt, sondern dass ihr keine automatisierte Tests hat.

Matthias: [00:05:18.63] Wir hatten keine automatisierten Tests, das ist der richtige Ausdruck, da hast du Recht.

Alex: [00:05:22.98] Also ihr habt schon getestet.

Matthias: [00:05:24.87] Genau.

Alex: [00:05:25.65] Aber halt einfach manuell, wie es auch früher als ich noch jung war. Es ist sehr lange her, üblich war, einfach alles manuell zu testen. Testautomatisierung ist eine ganz neue Sache. Ganz, ganz neu. So 20, 25, 30 Jahre, länger nicht. So und das hat sich aber jetzt im Laufe der Zeit verändert. Kannst du uns erzählen, was dazu geführt hat?

Matthias: [00:05:52.20] Naja, also letztendlich der ausschlaggebende Grund letztendlich, dass sich was ändern musste war einfach die Tatsache, dass die Firma gewachsen ist. Also wir haben innerhalb von den ersten ein, zwei Jahren, die ich dort gearbeitet habe, haben wir glaube ich vier oder fünf Entwickler dazubekommen und mindestens genauso viele Kunden. Also ganz genau kann ich es heutzutage natürlich nicht mehr sagen, aber wir hatten auf jeden Fall eine Phase, in der wir sehr stark gewachsen sind. Und da hat man dann eben auch sehr schnell festgestellt, dass unsere bisherige Arbeitsweise einfach nicht mehr funktioniert, weil was halt zu zweit noch möglich war, dass man sich in den Testserver geteilt hat. Das ist halt dann mit 5, 6 Entwickler Entwicklerinnen einfach nicht mehr praktikabel, weil du kannst da nicht von 5 anderen Leuten erwarten, dass sie für eine halbe Stunde das Arbeiten aufhören, nur weil du irgendwie mal was testen willst oder so. Und das war dann letztendlich so der Punkt – Also wir sind genau in diese Probleme gelaufen, also Leute haben sich gegenseitig Dateien auf dem Testserver überschrieben, niemand wusste mehr ganz genau: „Was ist denn jetzt eigentlich der wirklich aktuelle Stand.“ Und das war dann irgendwann so ein Punkt, wo wir festgestellt haben Wir werden ineffizient und wir müssen Dinge ändern.

Alex: [00:07:15.24] Und welche Sachen habt ihr geändert?

Matthias: [00:07:18.00] Naja, also zum Beispiel eines der ersten Dinge, die wir dann irgendwann gemacht haben, war, dass wir aufgehört haben per FTP Dinge direkt irgendwo hin zu laden. Also wenn es früher so war oder was ist früher ein Jahr vorher so war, dass wir eben quasi das Verzeichnis in dem wir unser Software Projekt liegen hatten. Das hatten wir schon aus zu Convenience-Gründen in unserem FTP-Programm auf Synchronität zu dem Server gesetzt. Soll heißen du hast in deinem – lokal in deinem Projekt was geändert gespeichert und das FTP Programm hat es dann direkt auf dem Server gespielt auf dem Testserver. Das war dann so das erste das wir aufgehört haben. Also wenn wir noch mal der Reihe nach geht. Wir haben zum einen dafür gesorgt, dass jeder der an einem Projekt was ändern sollte, einen eigenen Testserver hat, was im Prinzip erst mal ein Unterverzeichnis auf dem Testserver war, den wir eh schon hatten. Und zusätzlich haben wir eben dafür gesorgt, dass das Deployment nicht mehr per FTP passiert, sondern mit Git. Also wir haben dann quasi dafür gesorgt, dass auf dem Server auch ein Git installiert ist. Und dann konnte der Entwickler die Entwicklerinnen selber auf dem Server bestimmen, welche Stand des Projektes gerade aktiv sein soll. Und das hat dann natürlich auch bedeutet in dem Falle dann muss man sich dann relativ schnell damit auseinandersetzen: „Ja, wie kann ich denn überhaupt auf einem Server ein Branch wechseln, wenn da Git installiert ist?“ Also musste man sich schon so ein bisschen damit auseinandersetzen. Wie komme ich überhaupt zu nem Server? Und wenn ich mich auf den drauf schalten konnte, wie kann ich darauf arbeiten? Das war mir dann auch so wie der Learnings, die ich hatte, weil vorher überhaupt keine Berührungspunkte erst mal mit Linux oder Server Systemen vorhanden waren vorher.

Alex: [00:09:13.75] Du hast aber jetzt eine ganz wichtige Sache eingebracht. Ein ganz wichtiges Thema. Vielleicht könnten wir ein bisschen näher rangehen und dann uns erklären, warum das wichtig ist und welche Vorteile es euch gebracht hat. Nämlich Ihr habt zu diesem Zeitpunkt anscheinend das erste Mal tatsächlich auf ein Versioncontrol-System gesetzt. Kannst du noch mal bitte die Punkte durchgehen? Warum ist diese Alex: Versioncontrol wichtig? Was hat es euch gebracht?

Matthias: [00:09:46.84] Genau das kann ich gerne machen. Also es ist jetzt nicht ganz so, dass wir gar keinen Versionierung System vorher hatten. Wir haben tatsächlich vorher SVN eingesetzt gehabt.

Alex: [00:09:56.89] Ok,

Matthias: [00:09:57.82] Was eben auch gewisse Nachteile mit sich bringt oder für uns mit sich gebracht hat. Wenn man jetzt ganz einfach mal nur oberflächlich sagt. Zentraler Ansatz gegen dezentralen Ansatz, wo bei SVN der zentrale Ansatz ist. Das war einfach keine Lösung, die dann letztendlich für unsren UseCase möglich war. Deswegen haben wir dann zu Git gewechselt. Wir haben uns die Sachen dann migriert zu Git. Und jetzt zu den Vorteilen, was es uns gebracht hat. Also es ist natürlich so vorher auf den Servern hatten wir tatsächlich kein Versionssystem. Also die Server waren manuell bestückt vorher, eben per FTP. Entweder ein ganzes Verzeichnis, wenn ein ganzes Projekt irgendwo hin deployt werden musste oder eben einzelne Dateien wureden per FTP hochgeladen. Und das führt natürlich dazu, dass nirgends die ganze Wahrheit zu finden ist, weil niemand kann gewährleisten, dass an zum Beispiel auf dem Server genau der Stand steht, der da stehen sollte. Weil dadurch, dass Sachen manuell hochgeladen werden können und auch es gemacht wurde, hat es natürlich dazu geführt, dass das immer eine Differenz gab. Und auf der anderen Seite, wenn man ein Versionierungssystem auf dem Server einsetzt für seine Deployment, was jetzt nicht heißen soll, dass das die beste Lösung ist, um Deployment zu machen. Aber in unserem Fall war das zu dem damaligen Zeitpunkt zumindest eine gute Lösung, um sicherzustellen, dass auf dem Server genau die Version liegt, die dort liegen soll, nämlich zum Beispiel der Main Branch. Und auf der anderen Seite war es dann natürlich möglich, für jeden einzelnen Entwickler, für jede Entwicklerin, sich in dem Unterverzeichnis, in dem ihr Server lag, in Anführungszeichen die entsprechende Version auszuspielen, die sie gebraucht haben, einfach in dem sie einen Branch wechseln.

Alex: [00:12:01.60] Also durch die Einführung von Git habt ihr aufgehört, unterschiedliche Stände oder sagen wir es anders: Der Live Stand der Anwendung war nicht mehr eine Ansammlung von Dateien, die auf unterschiedliche Entwickler kamen, sondern wurde zentral auf dem Git Server Repository in dem Master Branch gepflegt und deployt wurde dann live nur das diese Master Branch. Habe ich das richtig verstanden?

Matthias: [00:12:29.65] Genau, ja.

Alex: [00:12:31.99] Ok. Und ihr habt aber weiterhin zum testen manuell auf euer eigene, du nennst es Verzeichnise, ich gehe davon aus, es waren also unterschiedliche Webservices oder Webserver, genau wo ihr getrennte Bereiche einfach verwendet hat.

Matthias: [00:12:49.22] Genau das war ein relativ großer Server bei einem relativ großen Hoster, also mit relativ viel Power. Und dann wurden dort letztendlich die Webserver Einstellungen so konfiguriert, dass wenn eine bestimmte Subdomain glaube ich war es damals aufgerufen wird, wird eben auf ein anderes Verzeichnis geroutet. Aber das war damals zum Glück schon komplett getrennt vom Live-System. Also das war zum Glück ein Zustand, den wir übersprungen haben, weil ich habe das auch von anderen Leuten gehört, die tatsächlich auch Entwicklungs Systeme auf dem Live Server hatten, was das also der Kelch ist und mir zum Glück vorbei gegangen.

Alex: [00:13:31.93] Okay, okay. Ja, verstehe ich. Coole Sache, coole Sache. Ich habe dir jetzt in dieser Git-Phase, sagen wir mal so gearbeitet. Also ihr habt habt ihr schon CI gemacht, Continues Integration Test geschrieben. Arbeitet ihr immer noch mit Notepad++ oder hat sich das geändert?

Matthias: [00:13:49.91] Naja, also im Laufe der Zeit hat sich das natürlich auch geändert. Also die Firma ist relativ schnell gewachsen von den Projekten, die wir umsetzen mussten und irgendwann, je mehr Projekte man hat und man betreuen muss. Man muss dazu sagen, wir haben ja nicht nur Projekte umgesetzt, sondern abgegeben und nie wieder gesehen, sondern im Normalfall war es so: Wenn ein Kunde zu uns kam, für den wir einen Onlineshop umgesetzt haben, dann hatten wir meistens auch den danach weiter betreut. Also das waren im Prinzip, wenn wir den Kunden dazubekommen hat, dann war der da so und kein anderer vorher ist weggefallen. Das heißt, wir haben immer mehr Aufgaben gehabt, die in der gleichen Zeit von nahezu der gleichen Anzahl an Leuten, also wir haben immer mal einen dazubekommen oder so. Aber im Grunde immer mehr Arbeit mit gleicher Zeit und gleichen Leuten. Und da muss man dann natürlich trotzdem dann irgendwann anfangen, noch mehr in Richtung Automatisierung zu gehen. Und da war einer der ersten Schritte tatsächlich eine vernünftige Entwicklungsumgebung. Also nichts gegen im Texteditor programmieren, aber ich persönlich habe schon gern meine Entwicklungsumgebung, wo ich meine Shortcuts kennen, wo ich ein Terminal direkt eingebaut habe und alles mögliche. Und für mich war das dann eben die IntelliJ, die wir irgendwann für uns entdeckt haben und die hat uns wirklich sehr gute Dienste geleistet. Zum Thema CI, also da sind wir jetzt, wo wir uns gerade in der ganzen Historie befinden, noch ein bisschen von entfernt. Das kommt erst noch. Zu dem Zeitpunkt haben alle unsere Deployment noch manuell stattgefunden. Auch das Erstellen zum Beispiel von Release Branches war ein manueller Prozess. Da hatten wir zeitweise einen abgestellt, der nichts anderes eigentlich gemacht hat, als Releases so zu organisieren. Also der hatte dann am Anfang von der Woche das eine Projekt, wo er dann das Release erstellt hat, wo quasi alles, was in den ein, zwei Wochen vorher eben passiert ist und noch in Feature-Branches war, wurde dann eben in ein Release Branch gemerged, was dann auf ein Staging Server deployt wurde. Und ja, das war alles noch ein manueller Prozess, zu dem Zeitpunkt. Was sehr viel Zeit – also wie gesagt eine komplette Person eigentlich Vollzeit beschäftigt hat.

Alex: [00:16:26.08] Was aber bedeutet, wenn eine Person einen Tag braucht um ein Projekt zu releasen, könnt ihr fünf Projekte die Woche releasen, wenn ihr nur einen Mensch dafür habt.

Matthias: [00:16:34.99] Ungefähr.

Alex: [00:16:36.38] Das bedeutet, wenn ihr sagen wir mal 100 Projekte betreut, ja, da darf von Projekt A nur jede 100 Tage ein Release gemacht werden. Und alle andere wollen auch released werden. Naja, also

Matthias: [00:16:48.46] Des ist dann natürlich auch irgendwann der der Flaschenhals. Also du kannst nicht einfach diese manuellen Prozesse beliebig in die Breite skalieren, oder es ist halt auch nicht effizient, da weitere Personen einzukaufen, die auch nichts anderes machen. Und deswegen hat sich das dann im Laufe der Zeit auch noch geändert. Aber da sind wir tatsächlich zeitlich gesehen wahrscheinlich noch ein bisschen weg.

Alex: [00:17:10.96] Okay, aber für mich wichtig: Diese Entwicklungsumgebung, ja? Die Entwicklungsumgebung ist der Tool, die wir für das ureigenes Programmieren verwenden. Und egal für welche man sich jetzt entscheidet, du hast jetzt IntelliJ genannt. Es gibt aber viele andere, die man verwenden kann, abhängig von Programmiersprache usw..

Matthias: [00:17:33.61] Klar, vor allem auch kostenlose.

Alex: [00:17:36.61] Was ist aber für dich das Wichtigste, die eine von dieser Entwicklungsumgebung mitbringen sollen? Was muss alles dabei sein? Und wie stehen wir gegenüber dieser Entwicklungsumgebung? Was müssen wir können?

Matthias: [00:17:51.36] Hmmm, also was ich an meiner Entwicklungsumgebung mit am meisten schätze, ist tatsächlich die Navigation innerhalb eines Projektes. Also dass ich, wenn ich mich in irgendeine Datei befinde, mit einfachsten Mitteln in andere Klassen springen kann, sehen kann: Wo werden Methoden verwendet? Wer implementiert alles dieses Interface des ich gerade vor mir sehe. Dann kann ich mir direkt angucken, wie wird dieses Interface implementiert und solche Spielereien? Das finde ich super nützlich. Habe ich die ganze Zeit benutze ich dieses Feature sozusagen. Was natürlich ganz nett ist, ist wenn eine git Integration gleich mit drinnen ist. Also wenn ich auch meine Commits direkt über die Entwicklungsumgebung machen kann und nicht übers Terminal machen muss. Also ich mache auch viel übers Terminal. Ich liebe das Terminal, aber wenn es schön in der Entwicklungsumgebung integriert ist, finde ich ist es auch etwas, was ich gern dort mach. Des Weiteren hat man natürlich die Möglichkeit der Entwicklungsumgebung eine Unmenge an Plugins zu installieren, also zumindest in denen, die ich kenne, die einen andere Dinge noch erleichtern. Also wir werden vielleicht später noch ein paar andere Tools hören, die dann später relevant geworden sind in meiner Zeit, die sich alle über Plugins auch in die Entwicklungsumgebung integrieren lassen. Also dass man dann eben auch für solche Tools und deren Konfigurationen Syntax-Highlighting und Autovervollständigung bekommt. Und diese ganzen Geschichten finde ich unglaublich nützlich.

Alex: [00:19:34.24] Okay, ich habe sehr vieles gehört git Integration, Plugins, Erweiterbarkeit, aber auch Themen wie Syntax-Highlighting und Autovervollständigung sind super Sachen, die uns die Arbeit als Entwickler erleichtern.

Matthias: [00:19:51.64] Was ich noch vergessen habe, sorry, was ich noch vergessen habe, ist natürlich das Debugging. Also wenn eine Entwicklungsumgebung einen integrierten Debugger hat, ist es natürlich auch nochmal Gold wert, weil ich dann natürlich meinen Programmcode innerhalb meiner Entwicklungsumgebung direkt auch zur Laufzeit untersuchen kann. Also welche Werte haben Variablen? Zu welchem Zeitpunkt? Kann diese Variablen unter Umständen auch manipulieren und kann schauen, wie verhält sich das Programm mit anderen Werten und das ist auch ein sehr wertvolles Feature.

Alex: [00:20:27.33] Ja und natürlich muss man diese Entwicklungsumgebung blind kennen. Es dauert halt seine Zeit. Aber man muss wissen, wo die Sachen sind, welche Sachen man machen kann und welche Schritte man dafür braucht. Es ist für jede Entwicklungsumgebung anders, aber für mich hat sich gezeigt – Ich möchte jetzt wissen, ob es für dich auch so war – dass eine der Sachen, die mir sehr viel Zeit spart, ist, wenn ich nicht dauernd mit dem Maus arbeiten muss, sondern einfach direkt auf die Tastatur arbeiten kann. Heißt wenn ich diese sogenannte Shortcuts verwenden kann, weil das spart mir einfach Zeit, weil ich die Hände nicht von der Tastatur nehmen muss, sondern kann da deutlich schneller arbeiten. Wie ist des bei dir?

Matthias: [00:21:16.83] Absolut, also Shortcuts sind tatsächlich eines, das ich auch noch vergessen habe, ja. Nein, also benutze ich ständig und bin auch ein Freund der Tastatur Bedienung. Also wenn ich die Shortcuts kenne, nutze ich sie.

Alex: [00:21:34.68] Also was ich damit sagen will eine der Sachen, die man auch sich angewöhnen sollte oder könnte, ist diese Shortcuts zu kennen und zu verwenden, weil die uns zumindest uns anscheinend Zeit spart. Da würde ich jede Entwickler an ans Herz legen. Gut, wir haben jetzt von den Anfängen auf ein bisschen später sind wir gekommen und haben mal gesehen, wie viel sich da geändert hat. Von alles per Hand zwei Entwickler auf ein größeres Team mit die entsprechende Komplexität, die sich daraus ergeben hat, da sind neue Tools dazugekommen, wie zum Beispiel Git als Ersatz für SVN oder eine ordentliche Entwicklungsumgebung. Ja und da kommen wir auf einen weiteren Punkt, die auch durchaus sehr wichtig sein kann. Und das ist nämlich der Terminal. Du hast es schon erwähnten. Ein Terminal in die Entwicklungsumgebung ist eine tolle Sache. Vorher habt ihr es außerhalb der Entwicklungsumgebung. Hast auch erwähnt, du liebst dein Terminal und deine Tastatur und alles eintippen. Was ist an das Terminal wichtig? Muss man da überhaupt was können? Wenn man eh eine Entwicklungsumgebung hat?

Matthias: [00:22:52.32] Ja, würde ich schon sagen. Ich meine es fängt schon mal damit an, wenn ich tatsächlich mal auf den Server muss, – aus welchem Grund auch immer -, muss ich schon mal irgendwie zum Beispiel in der Lage sein, mich per SSH dahin zu verbinden. Also das heißt, da wäre schon mal das erste Tool, was so ein. Also ich meine, alles was ich jetzt wahrscheinlich erzählen werde, sind erst mal standard Unix Tools, die es in den meisten Bashes oder Shells muss man eigentlich sagen geben wird. Also und SSH ist zum Beispiel halt eins davon ist einfach ein kleines Progrämmchen, das es mir ermöglicht, mich über eine sichere, verschlüsselte Verbindung auf einen Server zu verbinden. Und dort habe ich dann aber natürlich wieder im Terminal. Das bedeutet, egal was ich dort machen will, wenn ich eine Datei suche, wenn ich also was zum Beispiel eine Use Case bei uns war, ist von irgendeinem Server ist die Festplatte voll gelaufen, die Seite wird nicht mehr ausgespielt. Du hast nur noch eine weiße Seite, weil jeder Zugriff auf die Festplatte wird quittiert mit einem „Ja, geht nicht, sorry“. Und dann ist es halt so. Dann mussten wir herausfinden Ja, wo liegen denn gerade die größten Dateien, die wir gerade löschen können, damit der Server wieder in die Gänge kommt? Sozusagen. Und da gibt es dann auch wiederum Unix Command Line Tools, die das relativ einfach ermöglichen. Und in meinen Augen geht es nicht darum, dass man diese Tools auswendig kennt oder auswendig beherrscht, sondern es geht vielmehr darum zu wissen, dass es sie gibt, was man damit erreichen kann und wo man die notwendigen Informationen findet, wenn man sie braucht. Also zum Beispiel wüsste ich jetzt auch nicht, wie der Befehl lautet, um zum Beispiel alle Dateien in dem Ordner XY nach der Größe sortiert mehr ausgeben zu lassen oder so müsste ich nachschauen, aber ich wüsste halt, wo ich ungefähr nachschauen muss und weiß halt grundsätzlich, wie so Command Line Tools zu bedienen sind.

Alex: [00:25:01.38] So würde ich resümieren und sagst mir, ob ich da richtig liege oder falsch liege. Es wäre wichtig, einen guten Umgang mit dem Terminal zu pflegen, also in der Lage sein, den zu bedienen in der Lage sein, damit zu arbeiten.

Matthias: [00:25:17.62] Es gibt zum Beispiel noch andere nützliche Tools, die ich auch sehr häufig benutzt habe, wie zum Beispiel „grep“. Also „grep“ es so ein Tool, mit dem man wunderbar Dateien und auch ganze Verzeichnisse nach Wörtern durchsuchen kann. Das hat sich zum Beispiel in der Logfile Analyse für uns super bewährt. Man wusste, nach was man sucht und wurde es ungefähr zu finden ist also von „Die Datei liegt in dem Verzeichnis“ dann kann man da mit „grep“ in Sekundenschnelle unfassbare Mengen an Dateien scannen und findet relativ schnell die, die man braucht. Zum Beispiel,

Alex: [00:25:59.14] So, dann erzähl weiter, was – Was gab es noch für Änderungen?

Matthias: [00:26:03.70] Naja, also ich mein im Laufe der Jahre, die Arbeit ist nicht weniger geworden. Die Kunden sind nicht kleiner geworden und deswegen mussten wir halt die Automatisierung noch weitertreiben. Und was ich eben vorhin noch zu CI eben gesagt habe, ist jetzt der Punkt, der sich ändern musste. Also die eine Person, die alle Releases koordiniert, hat nicht mehr gereicht und somit muss für uns auch da letztendlich was neues überlegen und sind dann eben auf das Thema CI gekommen. Also das war auch tatsächlich so, das war glaub ich zu dem Zeitpunkt wo diese ganze CI / DevOps Geschichte Continuous Delivery wo es so langsam auch aufkam und in den Mainstream gekommen ist sozusagen. Und da haben wir eben uns angefangen mit zu beschäftigen und es hat halt eben dann auch eine Reihe weiterer Implikationen. Man kann jetzt natürlich dann ein System, das man bisher immer manuell getestet hat. Das kann man natürlich. Also man kann es machen. Aber es ist vielleicht nicht die schlauste Idee des automatisiert auszuspielen und permanent. Und deswegen mussten wir dann da ganz viel ändern. Also es kam dann eben dazu, dass wir auch angefangen haben, Tests zu schreiben und auch da dann erst mal eine relativ steile Lernkurve hatten. Also es ist halt auch einfach nichts Triviales, vor allem wenn du bestehende Systeme hast, für die keine Tests existieren. Dafür nachträglich Tests zu schreiben, damit du sicher CI machen kannst, ist halt auch Arbeit. Aber die haben wir damals reingesteckt und letztendlich hat sich’s rentiert, würde ich sagen.

Alex: [00:27:49.89] Du hast erwähnt, ihr habt angefangen, tatsächlich Tests zu schreiben zu dem Zeitpunkt

Matthias: [00:27:54.43] Automatisierte Tests,

Alex: [00:27:55.50] Automatisierte Tests. Kannst du mir sagen, warum? Was hat es euch gebracht? Warum war es notwendig?

Matthias: [00:28:01.68] Naja, also wie ich anfangs erwähnt hatte, war es ja quasi so. Also wir haben ja am Anfang immer alles manuell ausgespielt oder manuell getestet. Vielmehr und es ist natürlich, wenn man das ganze als wenn man den ganzen Deployment Prozess automatisieren will, ist es natürlich nicht mehr praktikabel, weil man kann sich halt dennoch nicht sicher sein, dass selbst wenn der einzelne Entwickler seine eigenen Sachen auf seinem Testserver durchgetestet hat, kann man sich halt trotzdem nicht sicher sein, dass wenn alle Features, die in dem Zeitraum eben gemacht worden sind, in den Main Branch gemerged worden sind, dass die zusammen funktionieren. Also weil das kennen wahrscheinlich auch einige, dass sich da einfach dann Konflikte auftun, die man einfach auch nicht ohne Weiteres verhindern kann, weil Leute an den gleichen Dateien gearbeitet haben, es wurden Klassen umbenannt, die im anderen Branch noch verwendet werden mit dem alten Namen. Es sind halt alles Sachen, die kann derjenige zu der Zeit wo es entwickelt nicht manuell testen.

Alex: [00:29:15.33] Also was du meinst ist eigentlich die Integration der Arbeit von den verschiedenen Menschen gestaltet sich nicht immer so leicht, wie man es sich wünschen würde.

Matthias: [00:29:28.26] Genau.

Alex: [00:29:28.86] Deswegen helfen diese Tests.

Matthias: [00:29:32.58] Also letztendlich war das auch der Grund, warum wir diese eine Person für die Releases gebraucht haben, weil seine Hauptaufgabe damals war sicherzustellen, dass wenn alle Einzel-Branches zusammengemerged werden, dass das danach auch das macht, was in den Einzel-Branches verlangt ist. Also er musste dann tatsächlich alles zusammenbringen auf einem extra Server ausspielen und dort quasi dann der Reihe nach die einzelnen Storys durchgehen und gucken ob die Sachen tatsächlich auch funktionieren. Und es war halt immer so, dass halt irgendwas dann nicht so war. Und dann hat man sich das angeguckt. Warum ist das so? Und dann sind es halt irgendwie so Kleinigkeiten gewesen, die halt einfach dazu geführt haben, dass das, was vorher im Einzelnen Feature Branch noch funktioniert hat, dann auf einmal im gemergedten Zustand nicht mehr funktioniert hat.

Alex: [00:30:29.15] Okay, aber jetzt mal eine Entschuldigung. Eine ketzerische Frage:.

Matthias: [00:30:33.45] Ja,

Alex: [00:30:34.05] Hat diese Mensch, diese Person nie Urlaub gemacht? War er nie krank?

Matthias: [00:30:38.88] Doch, aber dann gab es halt eine Vertretung und es hat dann jemand anders gemacht in der Zeit.

Alex: [00:30:43.36] Also ich meine diese arme Mensch hat irgendwie Urlaub auch verdient wenn er die einzige war,

Matthias: [00:30:50.07] Den hat er tatsächlich auch gekommen.

Alex: [00:30:52.34] Wenn nun mal nur mal so, ich meine, wenn nein, worauf also worauf hier nicht hindeuten will, ist das da baust du dir selber ein Problem, wenn du diese Geschichte manuell machst?

Matthias: [00:31:03.72] Genau, aber wie gesagt, dafür, dass wir halt dann um dahin zu kommen, dass wir das automatisieren konnten, mussten wir eben diese Vorarbeit leisten, dass wir mussten da relativ viel Zeit investieren. Also beim ersten Projekt, wo wir es gemacht haben, naturgemäß mehr als bei allen danach, weil beim ersten hast du halt dann eben die extreme Lernkurve, weil du etwas noch nie gemacht hast. Dadurch dauert es automatisch ein bisschen länger. Aber wir mussten halt einfach dieses System zumindest sagen wir mal grundlegend so automatisiert abtesten, dass wir sicher sein können, dass zumindest – da wir im E-Commerce waren, war das halt immer das Entscheidende, dass der Checkout funktioniert, also dass der Kunde was kaufen kann. Das war das Minimal-Set an Tests, dass wir halt eben gebraucht haben, um diesen Release Prozess zu automatisieren.

Alex: [00:32:00.72] Okay, also die Automatisierung voranzutreiben war euer nächste Schritt auf der auf der Leiter.

Matthias: [00:32:08.10] Genau das hat mit CI eben angefangen und wir reden jetzt hier über einen Zeitraum, der auch wieder dann weitere vier Jahre angehalten hat. Eher drei wahrscheinlich. In der Zeit ist dann ganz viel passiert. Also wir haben dann letztendlich sind wir von physikalischen bzw. virtuellen Servern auf physikalischen Kisten sind wir irgendwann ganz weg und Richtung Cloud. Und da ist dann noch mal der Automatisierungs-Regler enorm nach oben gedreht worden. Also am Ende von der Geschichte sozusagen hatten wir eigentlich so gesehen so gut wie alles automatisiert, was nicht mit der Programmierung zu tun hatte.

Alex: [00:32:54.28] Also heißt auch Bereiche, die in der Softwareentwicklung zumindest in letzte in den letzten Jahren dazugekommen oder sich dazu gesellt haben, wo früher eine ganz strenge Trennung gesehen hat zwischen Programmieren und Deployen

Matthias: [00:33:09.96] Und Betrieb

Alex: [00:33:11.75] Diese Devs und diese Ops ja auf eher so eine gemeinsame Sache gehen, die sogenannte DevOps, wo wir nicht nur uns um das Entwickeln und das Codieren kümmern, sondern auch um das Deployen der Anwendung auf den Live Server zum Beispiel.

Matthias: [00:33:29.97] Genau. Also wir sind auch voll auf diesen DevOps-Zug aufgesprungen. Also wir haben da wirklich alles mitgemacht. Also wir haben am Ende, also ich kann es ja mal ganz kurz umreißen. Also, wir haben am Ende unsere virtuellen Maschinen, in dem Fall waren das EC2-Instanzen, haben wir selber sozusagen, mit Terraform in dem Fall, in Code gegossen, wie das ganze später in der Cloud laufen soll. Wir haben mit Ansible, das ein Tool für Configuration Management ist, haben wir dafür gesorgt, dass diese Server richtig konfiguriert sind. Am Anfang hieß es bei uns: Ja, da ist die richtige PHP Version drauf und ja, da ist ein OPcache oder sowas installiert. Aber später ging es dann so weit, dass wir sogar per Ansible die Server Images gehärtet haben. Also das sieht man. Wir haben da relativ, sind tief eingestiegen und wir haben am Ende sogar unsere Infrastruktur getestet. Da gibt es auch Tools für was einen eben ermöglicht gegen seine Infrastruktur, die in der AWS laufen würde, zum Beispiel auch Tests auszuführen, also dass wirklich nur die Ports offen sind, die offen sein sollen. Dass zum Beispiel – das ist nämlich auch so ein Ding, das man sich zum Beispiel nicht als root auf dem Server anmelden darf. Das sind Sachen, die haben wir über inspec einfach sichergestellt und da ist es dann wirklich ganz viel passiert. Also da waren wir dann teilweise wirklich weit, weit weg von der Programmierung. Aber Automatisierung macht halt auch irgendwie Spaß.

Alex: [00:35:12.73] Ja, also auch im Bereich Operations sehr viel gelernt, sehr viel neu implementiert, neu gemacht. Du hast da Tools genannt wie Terraform und Ansible. Sei dahingestellt, ob diese Tools sind oder irgendwelche anderen. Warum müssen wir Operations machen?

Matthias: [00:35:30.78] Also jetzt aus der Sicht eines Online Entwicklers, also aus meiner Sicht jetzt, würde ich sagen, wir brauchen das, um einfach wie soll man sagen das Gesamtpaket abbilden zu können. Also in der heutigen Zeit finde ich, ist es halt einfach nicht mehr praktikabel zu sagen, in der Softwareentwicklung kümmern wir uns nur ums Programmieren und wenn es dann darum geht, dass das Produkt irgendwo landet, dann soll sich ein komplett anderes Team darum kümmern und am besten auch noch die Verantwortung dafür übernehmen, wenn das Ganze, was wir über den Zaun geworfen haben, nicht funktioniert. Ich vertrete eher den Ansatz. Also um es ganz kurz zu sagen „You build it, you run it“. Also soll heißen, wenn ich Software entwickl, sehe ich mich auch in der Verantwortung, sie betreiben zu können. Also es kann auch ein Server aus Blech sein. Also die ganzen Tools, die wir später auch für die Cloud benutzt haben, also zum Beispiel ein Ansible kann problemlos auch mit einem Blech Server funktionieren, sogar mit einem Raspberry PI. Ich kenne Leute, die setzen zum Beispiel auch ihren Laptop mit Ansible auf, weil das einfach den Vorteil hat: Du kannst sagen, die Kiste soll nach dem Ansible Run genau so konfiguriert sein, wie sie hier beschrieben ist. Und das ist nicht nur beschränkt auf die Cloud, was ich gerade erzählt, aber in unserem Feld – Online Entwicklung – ist in meinen Augen tatsächlich wichtig, dass man auch weiß, zum Beispiel wie ein Webserver funktioniert und wie ich einen nginx oder einen Apache auch mal um konfigurieren kann.

Matthias: [00:37:14.74] Das sind Sachen, die waren mir am Anfang meiner Laufbahn A) net bekannt und B) egal, weil ich musste mich nicht drum kümmern. Wir waren auf einem Managed Server. Der Hoster hat sich darum gekümmert, dass die ganzen Routen richtig laufen und so weiter und so fort. Es musste mich nicht kümmern, aber das war halt tatsächlich mehr so. Der Ansatz wir schieben das dahin und dass das ganze erreichbar ist, ist Aufgabe des Hoster sozusagen. Und haben uns aber halt dann hin entwickelt, sondern jetzt eine Geschichte, wo wir wussten, wie unsere Webserver konfiguriert sind. Und wir wussten halt auch ganz genau, was möglich ist und was nicht. Und es ist halt auch einfach Gold wert gewesen. Also ist eine kleine Anekdote, die ich zum Beispiel noch erzählen könnte, wäre, dass ich in den ersten Jahren, wenn es darum ging, dass irgendeine Umleitung gemacht werden sollte. Also sagen wir Seite XY von dem Onlineshop sollte nicht mehr erreichbar sein, sondern umgeleitet werden auf die Startseite. Das habe ich ganz am Anfang, weil ich es nicht besser wusste über die .htaccess gelöst. Also über eine .htaccess Datei kann man ja auch solche Um-/Weiterleitungsregeln und sowas formulieren. Später hätten wir das nie mehr so gemacht, sondern da haben wir solche Regeln halt dann letztendlich in unsere Ansible-Konfiguration für das jeweilige Projekt eingetragen. Dann wurde Ansible ausgeführt und dann wurde auf Server Seite der Webserver entsprechend konfiguriert.

Alex: [00:38:42.22] Okay, also wir haben jetzt sehr viele unterschiedliche Sachen gehört. Ich würde jetzt mal so kurz zusammenfassend über Tools und Skills, die man so braucht oder die du gebraucht hast, die eine betreffen oder einige betreffen die Entwicklungsumgebung und des lokales entwickeln. Wie entwickeln wir, welche Tools nutzen wir da? Welche Entwicklungsumgebung Terminal Shell wasauchimmer, Versionskontrolle. Andere betreffen Themen wie die CI oder das Deployment, auch Themen, die sehr nah an Operations liegen oder die eigentlich Operations sind. Aber auch Themen, die in der Programmierung selber hineinkommen, wie Testautomatisierung haben angesprochen. Alles wichtige Themen. Möchtest du als letztes zum Aufrunden von deine gesamte Erfahrungen in diesen Jahren? Was ist die Quintessenz oder wie bist du zum Softwarecrafter geworden?

Matthias: [00:39:48.45] Ja einfach – Ja, ich habe einfach immer versucht vor Problemen nicht zu kapitulieren, sondern sinnvolle Lösungen zu finden, die es ermöglichen, trotzdem A) mit einer guten Qualität und B) ohne sich kaputt zu machen, arbeiten lassen. Des soll heißen, ich habe mich nie dagegen verschlossen was neues zu lernen. Habe viel Erfahrungsaustausch mit anderen Menschen auf Veranstaltungen wie Barcamps und ähnlichen gehabt, um einfach den Horizont zu erweitern. Und die Software-Craft-Geschichte war dann tatsächlich eine Konsequenz dadurch. Also das hat sich so entwickelt. Also ich habe einfach diese. Also sobald du dich mit Automatisierung beschäftigst, musst du dich in meinen Augen eigentlich auch zu einem gewissen Grad mit Qualität, Testen und so weiter und sofort beschäftigen. Und es hat mir einfach so unfassbar viel Spaß gemacht, dass ich mich heute sehr gerne als begeisterte Softwarecrafter bezeichne. Sagen wir es so,

Alex: [00:40:59.50] Softwarecrafter per accident

Matthias: [00:41:00.76] Genau den Schlüsselmoment an sich gibt es nicht. Also da sind so viele Einflüsse. Ich könnte von den Leuten, mit denen ich zu der Zeit, wo wir gerade geredet haben, zusammengearbeitet habe. Mit denen habe ich so viel coole Sachen gelernt, viele Erfahrungen gesammelt, viel Blut und Tränen vergossen und ja war eine coole Zeit auf jeden Fall. Und wie gesagt, es hat mich letztendlich zu dem Softwarecrafter gemacht, der ich heute bin.

Alex: [00:41:33.13] Okay, wunderbar. So, das war es auch für heute. Du hast eine Menge über Tätigkeiten und Methoden gehört, die uns in unser Leben als Softwareentwickler treffen werden und die nicht unbedingt und direkt mit der Programmierung zu tun haben. Das ist für mich die Quintessenz, diese Folge. Es gibt viel mehr zu können als nur zu programmieren, um eine professionelle Laufbahn als Softwareentwicklerin hinzulegen. Denke daran, es ist wichtig, dass du dich auch mit diesen Tools auseinandersetzt und beherrscht oder beherrschen kannst. Natürlich wird die Wahl der Tools, die du brauchst, nicht die gleichen sein, welche Matthias benötigt hat, aber da lassen sich Parallele bestimmt finden. Die nächste Folge erscheint wie immer in drei Wochen und wir hoffen, du wirst sie dir auch anhören. Und wenn du unsere Podcast interessant findest, sei so gut und verbreite es weiter, damit jeder mit uns gemeinsam lernen kann. Vielen Dank, Matthias, dass du deine Erfahrung mit uns geteilt hast und du darfst die letzte Worte sagen.

Matthias: [00:42:50.42] Sehr gern. Ich bedanke mich auch fürs Zuhören und gebe hier noch mal einen kleinen Shoutout an mein Team, mit dem ich zu der Zeit, wo die Geschichte gehandelt hat, zusammengearbeitet hat habe. Sorry, war eine coole Zeit. Ciao Ciao

off: [00:43:08.97] Die Macht der Craft arbeitet für dich.