Ja, Moin ihr Lieben hier sind wieder Gerrit und Burkhard aus
Hamburg zum Podcast. Gerrit, wie siehts aus?
Ich weiß natürlich, was los ist, aber ich glaube, ich kann nicht
erzählen. Wie sind die Hörer verwirrt?
Also ich geb dir das Wort mal gucken wieviel wird am Ende die
Zuhörenden sind also lass uns heute sprechen über das Software
Ökosystem und den Software Lebenszyklus.
Was gehört alles dazu? Wir hatten ja mal das Thema
Software und 100 genau und sehr, sehr technisch, teilweise sogar
theoretisch und heute mal ganz praktisch.
Was werden für Tools benutzt, was gibt es für Prozesse?
In der Softwareentwicklung ne also angefangen von Planung,
über Entwicklungen, über das Testen, das Deployen, das Hosten
von Software und natürlich auch die Pflege und Wartung das ist
unser Thema, das ist ein riesiges Thema.
Ich glaube, da würden andere wahrscheinlich irgendwie ein
Buch drüber schreiben, aber wir versuchen das mal in der Kürze
der Zeit. Wir können alles gleich n
bisschen, aber das reicht vielleicht auch.
Genau das ist die Idee, dass man einfach als Zuhörer Zuhörerinnen
ein Gefühl dafür bekommt, was alles dazu gehört und wo auch
Stolpersteine. Sind ja ja OK alles klar soll
ich mal anfangen oder total gerne ja ja, wir haben genau 10
haben wir gesagt und schreiben von Software und so weiter, aber
bevor man überhaupt das erste Stück Funktionen Code irgendwas
schreibt, glaube ich kommt noch kommt schon ein riesiges Kapitel
vor ja. Das ist zum Beispiel, glaube ich
1 von den. Hab ich früher auch gemacht, ne
wenn nur Entwickler ist dann natürlich Spaß dran und
irgendwie schnell was programmieren weil dann sieht
man ja auch was und so weiter und fühlt sich so an, als käme
man schnell voran. Aber ich glaube wenn man früh
anfängt einfach los zu entwickeln, dann dann wird das
einfach nicht gut, ja also so ne Software ist halt klar wenn du
kleines schreibst du irgendwas kannst du dann hast du das
irgendwie im Kopf so und dann schreibst du das hin und dann
ist das fertig. Aber wenn wenn das Ding n
bisschen größer ist, dann software ich ich mach gerne so
ein Vergleich mit. Das klingt ein bisschen
philosophisch. Aber ich finde eine sehr große
Software, die sehr gut geschrieben ist.
Am Ende des Tages und gut funktioniert wie eine Symphonie
den Komponist komponiert hat. Also da gibt es brauchst Themen
du brauchst roten Faden, du brauchst verschiedene Aspekte
und so weiter und ja, der die das sind quasi die Noten, aber
ich glaube so Komponist, wenn einfach schreibt irgendwelchen
Hingeklatscht so, dann klingt das halt auch wenig.
Ja also man braucht schon ein Konzept, einen Plan und es
braucht eine gewisse Eleganz irgendwie in diesem ganzen Ding
so das macht es glaube ich ja. Ich sag ja philosophische Last,
aber also für mich ist das ein bisschen so ja klar und also es
fängt an mit der Planung und da scheiden sich die Geister und
ich glaube, da gibt es keinen, also das macht jeder anders.
Ich bin ein Mensch der. Ich versuche, mir vorzustellen
wie sieht das finale Produkt aus?
Und wenn es nicht gerade irgendwas ist, was nur im
Hintergrund arbeitet, als mittelbare oder irgendwas, wo
man nichts visuelles hat, dann dann versuche ich mir also, wenn
es grafisch ist, dann versuche ich mir vorzustellen wie könnte
die finale Anwendung aussehen und wie?
Ich müsste die bedienbar sein was würde ich als Nutzer, wenn
ich klicke und und und Dragon Drop und so weiter erwarten
wollte? Story in?
Ja, so ich genau, das kann man auch sehr, sehr chemisch
betreiben dieses also, da gibt es richtig viele Prozesse, also
User Stories aufschreiben lastenheften formulieren genau
alles ausarbeiten und so weiter. Da bin ich auch nicht der Typ.
Aber ich glaube, es ist total gesund, sich mal so auf dem und
ich bin auch nicht der Typ, der es gibt, dann wieder Software
Tools, die machen, so Mock UPS, wo man quasi dann irgendwie
schon so hin mocken kann so n bisschen powerpoint mäßig ne wie
das alles aussehen würde mach ich auch nicht, dass mir dann
auch zu fusselig irgendwie aber ich nehme schon NA 4 Seite und
im Bleistift. So wie vielleicht die
Architekten ganz früher das gemacht haben, so ne ganz grobe
Linie, und dann versuche ich zu verstehen welche Komponenten
habe ich und so weiter und fokussiere mich drauf und denke
es aber ich denke Software immer vom Ende her, also von der
Nutzbarkeit und dann versuche ich quasi rückwärts zu denken
was muss man dafür alles bauen, ne?
Und tatsächlich das ist glaube ich, die größte Herausforderung
für tatsächlich. Für Softwareentwickler ist, sich
zurückzunehmen und zu sagen OK, ich sitze halt vielleicht ein
234 Tage oder sowas mach gar nix ich denke nur nach mach mir paar
Notizen irgendwie will Sammlung. Recherchiere ganz viel wir
hatten jetzt ne Folge schon über über Open Source und so weiter
recherchiere, weil ich vielleicht gar nicht weiß wie
kann ich was realisieren, mit welchen Tools, was gibt es da
schon? Gucke mir an, welche Open Source
Komponenten kann ich vielleicht reinziehen?
Wie funktionieren die, was bräuchte ich dann noch als
Schnittstelle, als Glycose quasi um das mit einer anderen und so
weiter zusammenzubasteln macht also einen groben Plan erstmal?
Da muss man sich zusammenreißen, dass man hat n schlechtes
Gefühl, sag ich mal ne also als Softwareentwickler ist man n auf
Drogen, sag ich mal ja, wenn du wenn du Software schreibst, dann
hast du sofort ein Ergebnis, das ist total befriedigend, du
schreibst was du siehst es du kannst es klicken kannst es
nutzen oder was machst du irgendwas?
Ja, das ist sehr befriedigend. Und wenn du als Software gar nur
3 Tage nachdenkst, hast ich auf deinem Schreibtisch nur du hast
deine Gedanken im Kopf und ein paar Zettel lose liegen dann ist
das ziemlich unbefriedigend. Erstmal so in das ist auch
glaube ich gerade für jüngere Softwareentwickler.
N Problem ja, aber man muss sich.
Und man muss dann quasi auch als Teamleiter irgendwie das ganze
Team zusammenhalten, sagen OK, wir müssen doch schon erstmal
Design und planen, deswegen gibt es auch die Architekten den Bau,
ja also dann einfach hergehen und ich schon mit den Steinen
zumauern und sagt Oh, das wird schon passen beim beim Bau so
mache ich das so, wie ich es irgendwie will.
Ich glaube, das wird nichts oder Software nicht da hab ich jede
Menge Sachen zu kommentieren ich jetzt auslassen kann erstmal
bestätigen, dass du so vorgeht und weiß ich nicht 3 Viertel der
Zeit planst und dann oftmals in wirklich kürzester Zeit da n.
Ergebnissen nutzbares Ergebnis was ich dann sogar als Anwender
schon benutzen kann Hinzauberst das ist wirklich Wahnsinn wäre
ich gar nicht der Typ für ich muss immer sofort irgendwas kann
ich irgendwann fang ich halt an. Ich sage auch nicht, dass ich
dafür bin. Ich muss mich zusammenreißen,
das ist wirklich Willenskraft. Willenskraft der Macht das auch
keinen. Also Spaß macht schon immer
Spaß, aber das ist also macht schon mehr Spaß?
Irgendwie ist dann zu machen und direkt zu sehen ja genau und
dann hast du jetzt gerade, du sprichst von Bau und
Architekten, aber es gibt ja auch Architekten ja, genau die
Arbeit eines Software ja genau, wenn ich glaube, wenn man
richtig krass auf die Spitze treibt, dann ist ein Software
Architekt, der muss gar nicht grün können, es gibt sogar
krasser Weise informatikstudiengängen, das
weiß ich, wo du nicht beigebracht bekommst, wie man
Code schreibt oder Code entwirft.
Du lernst nochmal Programmiersprache oder
irgendwas also nur abstrakt. Konzepte ja klar
objektorientierung und so weiter.
Die Konzepte der Software alles im Detail und Netzwerktechnik
und den ganzen Kram, Laufzeit, Abschätzung sehr theoretisches
Studium. Das versetzt sich in die Lage,
genau das zu tun, also sehr abstrakt über über eine große
Software nachzudenken und das ist wirklich also große Software
ist wirklich ne, also hat richtig viel Quellcode und die
Sachen müssen gut ineinander Haken und arbeiten.
Das halte ich aber auch für komplett falsch.
Ja, weil das ist am Leben vorbei, das ist ja das ist halt
so der akademische Elfenbeinturm wenn du, wenn du so arbeitest
weil. Ich glaube, auch der beste
Architekt ist jemand, der auch nicht nur ganz akademisch vom
Studium her weiß, wie man es zu machen hätte.
Denn wenn du nämlich nicht weißt, welches sind die
aktuellen Materialien, was gibt es für tolle Möglichkeiten,
Fenster irgendwo einzubauen oder fassadenverkleidungen oder vom
Material her und von der Verarbeitung her und so weiter?
Wenn die Prozesse nicht kennst, dann kannst du auch nicht.
Dann kannst du dann bist du nicht dabei, einen Zeitplan zu
machen, dann kannst du nicht abschätzen also ich glaube, man
muss auch schon von dem Handwerk, wenn man vergleicht
das Handwerk ist das Coden ja mit verschiedenen
Programmiersprachen, man muss sein Handwerk auch können als
Architekt oder wissen zeitgemäß solardach heutzutage oder ne
Wärmepumpe ja genau weil die Architektur muss ja mit
einfließen hat gesagt die Technologien ja du findest du
schreibst ja nicht von Scratch, sondern du musst wissen was gibt
es und was was führt mich da schneller zum Ziel?
Wenn du das nicht weißt, dass das Handwerk Teil des Handwerks
das nicht weißt? Ist auch nicht richtig so, weil
es stimmt schon der Architekt ist mehr Designer, der muss auch
nicht selber machen, aber er sollte wissen, was er tut ja OK,
das war die Planung haben wir doch jetzt bisschen länger
gesprochen und irgendwann geht's hoffentlich auch mal in die
Entwicklung. Genau die Entwicklung geht ja
was brauchst dafür also wir haben schon mal über
Entwicklungsumgebung hab ich gesagt, dann angriff sowie
Visual Studio Code ja genau das ist ja e also es genau das
Integrated Development environment.
Das ist ein bisschen so wie gehabt, was wir auch in der Open
Source schon mal haben, ja, vielleicht ein bisschen, jetzt
kommts jetzt kommts ziemlich stark drauf an.
Wer geht in die Ausführung? Wie viele gehen in die
Ausführungen? Das ist vielleicht der
wichtigste Punkt. So ja also es macht einen riesen
Unterschied, ob du jetzt nach der Planung irgendwie sagst.
K 120 Köpfiges Entwicklungsteam setzt das jetzt um oder wir 2?
Und zwar aus mehreren Gründen du musst ja erst mal deine
Planungen also wenn du die nicht gerade irgendwie einen tollen
powerpoint s fertig hast wo. Wo sich da ein mentales,
abstraktes Bild, das du in deinem Gehirn angesammelt hast,
als Planung quasi widerspiegelt und erklärbar wird für den
nächsten das ausführen soll. Dann musst du ja irgendwie den
Erklärbär machen du musst irgendwie den Umsetzer so ein
bisschen was von deiner Perspektive mindestens den Teil
der jetzt gerade dran ist, mal irgendwie erklären können und so
weiter ja, das ist natürlich bei Windows 20 Leuten erklären wir
ne andere Nummer als wenn du irgendwie 2 Leuten erklären
willst, so ja, genau das ist das eine und dann kommt noch bei der
Umsetzung drauf an also wir haben mehrere Komponenten.
Wir müssen ja erstmal. Wir müssen ja schreiben in einem
Editor, ja also früher hat man tatsächlich gab es eigentlich IO
Max. Entweder war die mein alter
Chefarzt I Typ. Da gab es halt, das war so krass
ist so, Linux ist richtig, Nerd mäßig so ja, das war quasi ein
Notrad für Entwickler, ja aber auch nicht viel besser also es
war eigentlich nur ein n besserer Texteditor und die
hatten ganz viele Shortcuts auf dem auf dem Keyboard so ja, also
eigentlich. Das ging nur deswegen schnell.
Du musst halt tausende 1000 n Schrott auswendig können und
dann machst du das Ding, kannst markieren, einfügen und dass ich
alles und entweder hast du halt die I schaut Katze im Kopf
gehabt oder die von Emails, die man anders so ja und wehe man
musste wie bedienen da völlig aufgeschmissen.
Umgekehrt heute haben wir noch viel krassere Editoren, also die
nennt sich d Integrated Development, weil die eigentlich
der nicht nur erlauben, den Text zu schreiben, sondern die sind
halt voll integriert, das heißt. Du kriegst dann die
Dokumentation, wenn es irgendeine Open Source
Komponente ist, dann noch eingeblendet ist, das macht er
automatisch einen Syntaxcheck, das formatierte, das auf einen
Knopfdruck formatiert ihr das ganze Dokumente in bestimmten
Art und Weise und so weiter das nimmt dir extrem viel Arbeit ab,
dass du du siehst wie Sprache. Du musst schon, aber es wird ja
echt. Ganz viel Arbeit abgenommen so,
und das hat dann jeder Entwickler unter der Hand und
ich ja genau, ich mache Werbung für Microsoft Visual Studio Code
das ist ne freie Entwicklungsumgebung ist mega
mächtig so ich hab lange herumexperimentiert und jetzt
bin ich schon seit sehr vielen Jahren.
Bei diesen Dingen ist echt cool da aber genau kann man mal
gehört haben wieder vergessen so und dann und dann ist das hab
ich schon mal gesagt, dann ist es ja so wenn wir jetzt über die
Symphonie denken, dann ist aber nicht nur Mozart, ja der Sinn
komponiert, sondern wir haben jetzt einmal ganz also der hat
sich ausgedacht und jetzt gibt es viele.
Ausführen, die das Schreiben müssen und jetzt fangen?
Jetzt müssen die, aber es ist schon so, dass es halt ein Stück
Symphonie Noten, die müssen jetzt von mehreren
aufgeschrieben werden. An der richtigen Stelle und so
weiter. Das ist ein riesen
Koordinationsaufwand ja und oft ist nicht perfekt im ersten Mal
da muss nochmal bearbeitet werden und so weiter, dann
passiert es mal, dass 23 Mitarbeiter an der gleichen
Stelle irgendwas rum editieren. Ja, da kriegst du dann Konflikte
in dem Dokument und so weiter und da gibt es genau da gibt es
jetzt sionssysteme ist ganz wichtig.
Das muss man kennen. Also g ist da heute.
Das das Standard Ding früher hieß es VN und davor CVS.
Das sind Managementsysteme, die die managen für viele für viele
Leute zusammen das Erstellen einer Codebasis ja und und
regeln alle diese Konflikte, da passieren dass Emerging das
zusammenführen und so weiter, weil du am Ende wie Du schreibst
nur einen ein Buch mit vielen Leuten, also ganz konkret, wenn
2 Personen in einer gleichen Zeile Code editieren, dann gibt
es da einen automatischen. Wie geht das denn, der wieder in
ja genau? Das gibt es tatsächlich, dann
gibt es keinen automatischen Weg, das ist die einzige Sache.
Es gibt ganz viele Automatismen, aber wenn tatsächlich 2
unabhängig 2 verschiedene Versionen der gleichen Stelle
Code gemacht haben, dann auch das dann auch die
Automatisierung nicht mehr wissen was ist richtig?
Dann muss man sogenanntes Konflikt kriegt man Konflikt mal
angezeigt, dann kriegt man angezeigt hier sagen wir mal,
ich hätte mir gedacht der Gerrit hat diese Teile so geändert und
ne, das kommt jetzt vom Server rein bei dir und du hast die so
geändert was sollen wir denn jetzt nehmen?
Ja, dann muss man diesen Konflikt.
Immer Reserven, sagt man so ja, dann muss man leider auch als
Softwareentwickler kommunizieren.
Wird nach persönlicher ist Scheiße, ja, das
Konfliktmanagement ist da also auf dem Code ist da aber die
sind die Idee ist ja die sind die s und in denen ist quasi
dieses früher war alles repariert.
Aber ist genau das alles mit eingebaut.
Schon da ist dann geht es mit drin genau genau du siehst auch
sofort wenn du wenn du ein Stück hast und ihn zu editieren macht
das farbig ne was hast du geändert?
Was ist alles total transparent? Da geht es jetzt nicht.
Lab Nee geht es geht es quasi, die geht ein kleines Stück Code
ist tatsächlich Onlineshop vom. Ich glaube, vom Linus Torvalds
geschrieben. Der Autor von von Linux hat er
also ich glaube, die Anekdote ist, dass mehr oder weniger am
Nachmittag zusammengepackt hat und jetzt die ganze Welt immer
noch seit Jahren benutzt. Das auch G Lab ist quasi ist
noch mehr drumherum, da hast du quasi eine Weboberfläche, wo du
dann auch Reviews machen kannst und so weiter.
Dann kommen wir noch zu, wenn Du ein großes Team hast, dann hast
du noch mehr Prozesse als nur n bisschen Konfliktmanagement hast
du quasi Junior Entwickler und Senior Entwickler und so weiter
und bevor dann irgendwie ein Stück Code von einem
Juniorentwickler in den. Man sagt Master Branches
meistens, gibt verschiedene Modelle, gibt meistens quasi in
Hauptentwicklung Branch quasi immer die aktuellste Version.
Das muss nicht dierelease.de, also die dem Kunden zugespielt
aktuellste Version sein, aber die aktuellste Version
Entwicklungsstand quasi aufgebaut wird, bevor da was
reinfließen kann, muss auch mal ein Stück Software, vielleicht
auch auf Qualität geprüft werden.
Ja, wenn Junior ist ganz normal ja auch selbst wenn er sich
anstrengt genau ist doch egal ob es ist auch egal ja, aber genau.
Aber es muss natürlich einen Review.
Ach ja, das machen natürlich typischerweise die Seniorinnen
Entwickler, um zu gucken hierarchisch da gibt es nicht
einfach n sag ich mal 4 Augen Prinzip unabhängig von gibt es
bestimmt auch total je nach je nach Firma, ne aber ich würde
also in meiner Firma aber immer so, dass die, die die
erfahrensten Entwickler die Reviews machen, weil Erfahrung
also ich will überhaupt keinen sprechen können alle ganz
intelligent sein und du kannst ja auch als Junior Entwickler
total intelligent sein. Intelligenz schützt dich aber
nicht vor schlechtem Code. Nur Erfahrung ist ne ganz krasse
Meinung, also ist hilft nur Erfahrung, Erfahrung, Erfahrung
du musst ganz viel gesehen haben, ganz viele Fettnäpfchen
abgetreten haben. Und nur dann kommst du soweit,
dass du Sachen siehst im Code, die später kaputt gehen, ne weil
man muss sich ja, wenn man so Code liest, man muss sich ja
quasi schon also bei mir fühlt sich immer das Programm quasi
schon im Kopf aus, was dann so passiert ja und ich glaube man
kann nur mit Erfahrung irgendwie die ganzen Seiteneffekte
mitbedenken. Das hat man als Junior einfach
nicht drauf. Ich glaube, das ist Intelligenz.
Quotienten unabhängig ja sind wir denn jetzt schon im Test des
kommt jetzt sind wir noch ne ja jein eigentlich schon, weil so
ne man schreibt quasi ja, wenn man Code schreibt.
Schreibt natürlich der irgendwie finale Anwendungen widerspiegelt
und dann schreibt nochmal genauso viel Code den Code.
Die finale Anwendungen widerspiegelt.
Testet also man testet Software mit Software.
Man hofft darauf, dass die Frameworks und frei sind, sie
auch. Und genau das ist relativ viel
Aufwand und typischerweise ist es so und so haben wir es auch
gehandhabt in allen Firmen. Ich war, wo wir mehr als ein
Entwickler waren, man ist angehalten, zu jedem Feature
zurück, dass neu schreibt auch n Test.
Zu schreiben, der das testet, was man gerade geschrieben hat
ja. So und zum Testen können wir
nochmal Eigenkapital machen, da gibts halt verschiedene Ebenen,
auf denen ich abstraktionsebenen ich testen kann.
Das kleinste Level ist Unit Testing müssen wir gehört haben
und dann gibt es die Integration Testing und n Testing und so
weiter. Man kann sich quasi.
Ja, du kannst dir vorstellen und testen dann schreibst du halt
eine Funktion hin und dann überprüft Unit Test wenn ich da
was eingebe ob das rauskommt? Was also testet eine Funktion
erwartest du ja das kleinste atomische Level ich testen kann
ne? Sehr aufwendig und es entsteht
wieder sehr viel Code Test Code. Ja, also ich bin gar nicht so
ein Freund von und dann kannst du leben.
Kannst du Komponenten testen, dann sagst du zum Beispiel wenn
I hab ne Web API oder irgendwas nicht knallt das Ding da rein
dann erwarte ich, dass da rauskommt ne w ist glaube ich
und was das ist ich aber vielleicht irgendwer erklären
oder ein anderes Beispiel ja also was ist eine typische
Komponente? Also wir haben ja die Folge
schon über Microservices gehabt, ne Komponenten typischerweise in
Microservices heutzutage gepackt und eine Microservice.
Hat immer eine standardisierte Schnittstelle nach außen, ne und
im Container drin sind ganz viele Funktionen, ne?
Die könnten die Tests abdecken, die ganzen Funktionen drinne, so
aber jetzt kann der Container an sich dann ja auch quasi ein
Label dran machen und sagen wenn ich da das Reingebe sollte.
Nach Durchlaufen von x Funktionen, das wieder
rauskommen, ja und das kann ich auch testen ja, ich nicht n Loch
im Schlauch ist, sondern das Fahrrad rollt n bisschen ja,
genau das ist vielleicht ein gutes Beispiel ja, genau du
guckst beim Fahrrad quasi. Jede Schraube an, sondern erst
einmal um Block und wenn das Ding sich irgendwie stabil
anfühlt und ordentlich gefahren ist, dann weißt du impliziert,
dass auch die Schrauben fest waren.
So deswegen finde ich eigentlich wertvoller die Tests auf einer
höheren Abstraktionsebene zu schieben, weil du implizit
vieles mit testet. Das ist irgendwie irgendwann
nicht mehr ganz richtig, weil du ne.
Ne kombinatorische Explosion von allen Möglichkeiten hast die du
nicht von oben alles testen kannst am Ende hast du ja auch
nicht also am Ende hast du auch bestimmte Anwendungsfälle, die
du für deine Software vorsieht. Für den Kunden und wenn du die
gut durch Test, dann hast du schon viel geschafft so.
Ja, genau genau und das testen die User sich anders verhalten
als man dachte ja genau, das ist ja das ist ja der meiste Grund
warum du hast also was wieso machst, warum klickt ihr denn da
hin? So ja Ach, das geht auch so
verdammt, da bin ich Kandidat ja genau.
Man braucht dann so die die ja OK gut, aber das testen wird mit
also das ist halt auch alles integriert, also in diese es und
in diese ganzen Plattformen und so weiter das das kannst du
alles aufschreiben, das läuft dann automatisch repariert man
dann irgendwie als Testcode gehabt den eigentlichen ja auf
jeden Fall. 6 deklariert man auch ganz anderer Art und Weise,
ist auch getrennt von dem von dem von dem Anwendungsquote darf
auch zum Schluss nicht mehr ausgeliefert werden.
Der würde ja das alles langsamer machen und auch einfach dicker.
Das ganze Paket, das muss alles raus dann, so ist dann alles
organisieren und planen übrigens gar nicht so einfach.
Da diese Tests auch die Tests zu schreiben und zu planen, also
kompliziert der gute Test zu schreiben ist nicht einfach.
Da gibt es eigene Stellen rollen, die sich nur ums Testen
kümmern, ja, genau sagen Qualitätsmanagement ja, es ist
also ein Software Projekt ist am Ende.
N ein komplexes Projekt so und da gibt es alles, was im
normalen Leben auch gibt, so Planung, Ausführungen,
Qualitätssicherung und dann kommen wir zum Ausrollen.
Vielleicht können wir jetzt auch schon mal ansprechen.
Oft ist das oft versucht man uns heute zu integrieren, sich
Continuous Integration und Continuous Deployment CICD also
man versucht quasi hinzukommen, dass man sagt wenn ich den ich
habe ja gesagt es gibt n Master Master Branch also quasi so ne
Art. Den aktuellen Entwicklungen
aktuellen Entwicklungsstand genau und wenn ich, wenn ich
jetzt alles gut designt habe, das quasi die Software, die
reinkommt, schon voll durchgetestet ist und jedes Mal,
wenn wenn sich dieser dieser neuesten Entwicklungsstand
ändert, dass der quasi das passiert heute, der stößt quasi
automatisch anders machen muss, stößt er quasi nochmal das
testen an meistens gar nicht mehr auf meinem persönlichen
Rechnern alles in der Cloud. Da wird quasi der, der der Code
von dem Master stand, einfach reingezogen in eine Testumgebung
wird ausgeführt. Ja.
Rechner oft meistens gibt es sogar so weit geht, wenn Open
Source Projekt hast, kriegst du alles umsonst, dann riesige
Software zur Verfügung, die einen durch und wenn das noch so
aufwendig ist. Scheißegal ja Ach, das war das,
was du in der Folge erwähnt hattest, dass wenn du deine
Software unter Open Source Lizenz veröffentlicht, kriegst
du diese genau das. Denn zum Beispiel wenn du hast
ja genau das ist super ja, das ist alles super organisiert und
das das läuft alles von alleine durch und dann kannst du sogar
so weit gehen, dass du sagst OK dann nicht weiß, dass der Code
gut getestet und es funktioniert nicht.
Bin ich auf meine Tests verlassen?
Kannst ja auch schon könntest du schon ausrollen zum User das
passiert halt auch und dann das CD Continuous Deployment und
dann quasi und besaß ist besonders spannend.
Da kannst du quasi sofort wird interne Versionsnummer
hochgezogen machst du auch nicht mehr haha und sofort die nächste
Version zur Verfügung wird getagt wird vorbereitet, kannst
du runterladen vom Server oder ist halt quasi schon online und
wenn das nächste Mal wenn der wenn der Nutzer irgendwie die
App aktualisiert ist schon ne, dann musst du dich überhaupt
nicht mehr ums Deployment kümmern.
Was heißt aktualisiert einfach auf Macht?
In dem Fall aufmacht ja aber das hat natürlich ganz viel zu tun,
das kann nicht jeder Anwendung machen.
Es kommt drauf an was will der und so weiter?
Aber theoretisch versucht man quasi also von der Software
Seite her sich das alles durch zu automatisieren.
Das geht halt aber auch noch nicht so lange, weil es.
Alles dies sind, so Enabler Technologien durch diese ganze
Cloud Software als Service Docker containerisierung Sachen
sind auch quasi diese ganzen Tool links drum herum, um das um
dieses Projekt Software zu entwickeln, so viel besser
geworden, dass man das Halt leisten kann, ne früher Grüße
Anekdote früher kam in einer anderen Firma kam immer die
Entwickler und oft müssen die Juniors da dran ist n bisschen
Abi, aber die müssen halt, weil Deployment das ist halt
irgendwie so. Das ist richtig Arbeit so wenn
man das nicht gut vorbereitet hat, dann muss hier noch per
Hand und da getestet und geguckt ist ja und dann mal einen Junior
Developer hat immer so. Irgendwie zu Hause und dann,
wenn es halt irgendwie Last Day war, dann mit dem Baum schon
morgens an, dann dürfte man nicht ansprechen, aber den
ganzen Tag haben Release so ja, ich muss da hart werkeln, ne und
wenn er 2 Tage den Helm auf hatte, da wusste, dass irgendwas
gar nicht gut gelaufen ist so ja und das ist immer.
Für einen Softwareentwickler ist, dass der Stress überhaupt
so, ja also neues Release rauszubringen, so und dann
hoffen und beten und dann irgendwann verpackt und fertig
und ausgeliefert so und dann ist der Drops gelutscht, so wenn
etwas falsch ist, dann. Ja, das ist halt Mist, dann ist
schon beim Kunden, dann kannst höchstens noch ein Release
machen, das wixen und so aber dann siehst du natürlich wieder
als Softwarefirma so ja, die haben grad rausgebracht und
irgendwann später gibt es schon 301 den ersten Bugfix ja, aber
das ist doch nicht geschafft habe so ja, aber so ist es halt
ja und das das löst aber das Problem löst sich, wenn du n
bisschen besser strukturiert und quasi diese Continuous Delivery
Continuous. Ich weiß nicht was nicht
deployment aber bist du noch im wenn du das halt aufbaust, so
ja, dann ist ja auch der Stress bei den Softwareentwicklern weg
also. Wenn es eigentlich Zeit wissen
cool, das läuft alles so ja, wir haben ja keine ja gerade in dem
Fall, sondern eigentlich n Kreislauf durch die durch das
CICDS passiert, laufen der, dass die Code oder der Text geändert
wird. Und wie genau aussieht, laufen
genau und man muss, das muss man einmal verstehen.
Vielleicht auch zuhören. Also Software ist halt irgendwie
fertig. Ja, das ist zwar ein Aufreger
für alle, für alle, die Software benutzen die sagen ja verdammt,
jetzt muss ich schon wieder und so weiter einspielen.
Es ist aber. Es ist aber einfach Fakt der
Dinge, dass ich ja um mich herum ändert, sich ja ständig alles
ja, ich glaub neue Hardware ich hab ne auf einmal gibt es
Smartwatches und so weiter. Ich habe ständig neue
Anforderungen an den Code, alle alle Bibliotheken um mich rum
die ich benutze, ändern sich ja auch das heißt, ich muss ständig
eigentlich meinen Code pflegen. Das heißt dieser Kreislauf ist
genau das Richtige, ja, weil eine sagen es kann ja schon mal
sein, dass du so ne Art Feature Freeze hast also du sagst jetzt
mal neue Funktionalität kommt jetzt nicht dazu.
Wir sorgen nur dafür, dass die bestehende Funktionalität weiter
und dann hast du schon genug zu tun, ne?
Ja, das ist doch erstmal alleine das ist schon Kreisverwaltung,
dann ne ja genau das ist die Maintainance.
Und je größer deine Codebases, also je größer deine dein
Produkt ist, desto mehr hast du quasi schon an diesen an diesem
Grundrauschen zu tun, ne und das kann richtig substanziell sein,
ne nur ne Software am Leben zu erhalten mit Feature Freeze was
du gesagt hast, also keine passiert gar nichts mehr.
Ich muss nur funktionieren, also du siehst es nicht, aber der
Firma die Software zur Verfügung stehen riesige Kosten nur für
diese Maintainance. Das ist ein gewaltiger Aufwand,
das ist völlig unsichtbar für den Nutzer.
Auch das ist glaube ich auch unsichtbar, so im im im Wissen
so ne von unseren Zuhörern. Deswegen will ich nochmal sagen
und deswegen ist es auch richtig und wichtig, dass gute Software,
die gut gepflegt ist und von der man erwartet dass sie
funktioniert, zu jedem Tag, dass sie auch ein bisschen was
kostet, ja, weil die weil da entstehen halt auch ganz viele
Kosten so. Das muss, irgendjemand muss ja
irgendwann mal bezahlt werden, ne?
Genau also, das ist schon was macht man da konkret, wenn man
eine Software flegt? Ist das auch ne Rolle, die jetzt
wieder bestimmte Softwareentwickler und einfachen
oder ist das etwas? Was übernimmt man für ein
bestimmtes Projekt für immer die Verantwortung oder ist man immer
die Person, die ja Features weiter pflegt oder so?
Also gibt Einteilung, der ich glaube, dass sie das irgendwie
am Fließband auch ist, ne gibt es verschiedene Firmen, man hat
glaube ich auch schon vieles ausprobiert und alles
ausprobiert, ja also, es gibt ja auch ich glaube, w arbeitest,
dann gibt es auch das Modell macht der eine Mitarbeiter immer
nur diese eine Schraube an der Stelle rein so und kann dann
total gut und FF ja also das hat viele Vorteile ja.
Oder und das andere Modell wäre so, dass die Mitarbeiter
rotieren es nicht mehr, weil du nämlich, weil du nämlich in der
Birne wird, immer das gleiche machst und dann bist du
irgendwie so ne irgendwie. Es hat nämlich Vorteile hat die
Nachteile bei der Software ist genauso ja also es gibt, ich
würde sagen in einem Team und wir hatten diese Folge mit
agilem Entwicklungen. Deswegen macht man das auch
gerne so agil entweder Kanban oder Sprint ist ja auch egal,
aber ich hab ja diese Arbeitspakete und maintainance
Qualitätsmanagement Test schreiben Feature entwickeln
Bugfixes und so weiter. Das sind ja alles einfach
Tickets so ja, die sind erstmal gleichwertig und werde sich
schnappt. Das steht auf einem anderen
Blatt Papier und wenn man agil macht, dann kann sich immer
jemand mal was Neues schnappen, ja und wenn man Lust hat, als
Softwareentwickler auch mal über den Tellerrand zu gucken man hat
halt irgendwie immer geschrieben und will mature entwickeln.
Damit spricht man das im Team und nimmt sich halt so featuring
raus. So ja.
Und so funktioniert es, glaube ich, in vielen Firmen, und das
ist eigentlich eine gesunde Eigenschaften, will auch die
Entwickler auch gerade die Union.
Die wollen auch ein bisschen mehr sehen wollen, natürlich
ihre Arbeiten bisschen weiterentwickeln, persönlich
auch richtig so. Gut, dann ist es bis dahin
eigentlich n Kreislauf. Wobei ne Planung muss ich
anfangen, wenn ich eine Software ganz neue Form Scratch mache
wahrscheinlich ein bisschen mehr machen und dann und dann
vielleicht noch genau genau mach dann noch ne und neue Version
und der Rest ist dann ein gewisser Kreislauf, also die
Entwicklung, das testen, was unter Umständen komplett
parallel läuft und dann gibt es noch einen Punkt kann natürlich,
der brennt mir auf dem Herzen sofort loswerden und vergesse es
dann auch noch OK cool das sogenannte Refactoring.
Das ist die, das ist der, das ist das macht den Chefs allen
weiße Haare und die, die richtig sauer, wenn man das Wort
refactoring sagt ja, ich finde, es ist so wichtig und muss in
jedes in jedem Zeit und Budgetplan von einem
Softwareprojekt sofort von Anfang an mit eingeplant werden
und ich würde sagen, mindestens 20% da.
Weil wir sind ja nicht die Mozarts und Beethovens ja die
der Mozart hat sich ja, der hatte dann irgendwie seine.
Sein sein so nett oder seine Symphonie da im Kopf und hat die
quasi in Reinschrift einmal hingeklatscht, aber das quasi
fertig, ja also ich kann das nicht also auch nicht im Code
also und das heißt selbst wenn man sich noch so viel Mühe
gegeben hat ist zu planen, wenn das Projekt nur groß genug ist,
wird man sehen irgendwann verflixte Kiste hier haben wir
echt noch das Mist so, das haben wir schlecht geplant hieß das
Design. Die Ausführung ist OK, laut Plan
aber das Design hier das krankt hier noch hier müssen das Misste
man erkennt das halt oft, wenn man es erst erstmal hingebaut
hatte und dann muss man find ich die Zeit und die Muße haben und
auch das Geld zur Verfügung gestellt bekommen von ganz oben
Management, das man dann. Das nochmal intern umbaute, ja
so, als würde ich den Motor nochmal ein bisschen neu
strukturieren, ja und das schlimme ist man sieht nichts ja
von außen also. Fixed WLAN n Bug noch gibt es
ein neues Features völlig unsichtbares verbrennt einfach
nach außen verbrennt einfach nur Zeit und Geld, so ja und
deswegen hassen die Chefs das so ja, es ist Todeswichtig für eine
Software, weil nur dann kannst du sonst auch technische
Schulden aus. Auch Technical Debt is so ein
wichtiges Wort. So technische Schulden heißt es.
Ich weiß eigentlich, dass das. Nicht ganz richtig ist und
irgendwann komme ich da nicht mehr weiter.
Das ist, wie wenn ich mein Fahrrad nicht vorbereitet, also
sagen wir mal, ich hab da irgendwie noch 8 Hinterreifen so
und so wenn ich langsam genug fahren es steht egal ja so bloß
irgendwie noch Features Fahrrad dran machen ja auch irgendwann
Gepäckträger und das müssen wir alles machen.
Ich sag halt, kümmert sich früh genug um die 8 im Reifen, dann
irgendwann, sagt der Chef oder die Kunden jetzt geht aber mal
Gas, ja und dann fällt das ganze Fahrrad wieder komplett
auseinander, weil die 8 und die Unwucht drin hat alles zu Tode
gemacht Chris. Probleme, Skalierung zum
Beispiel richtig ja und das ist und das und das wird teurer, je
länger du das nicht behandelt. Das Problem ja, je länger du
dann hast du nämlich investiert in deine Klingel, in dein Licht,
in deinen Gepäckträger und zum Schluss fällt dir das alles
wieder auseinander kannst du gerade alles nochmal neu machen?
Ne, so ist es. Ich weiß nicht, ob das gut
passt, aber das passt eigentlich nicht schlecht.
Also refactoring refactoring. Ich hab quasi keinen echten
Fehler und ich habe auch keinen echtes Feature Quest aber ich
weiß halt. Alle Softwareentwickler fühlen
das und sehen das hier muss mal neu gemacht werden, ist wichtig,
nicht mal unbedingt Tuning, sondern wirklich n Verbesserung
des Status quo genau und da gibt es natürlich also man muss sich
auch erwehren, davon ist alles neu schreiben zu wollen.
Das ist auch so n das hat man gerade als als deswegen sag ich
mal Erfahrung also man muss auch genau im Mittelmaß finden, sonst
denn alles neu schreibt so, dann hat man wieder ein neues
Refactoring, wenn s da auch wieder nicht alles ne.
Also man muss sich schon iterativ dem annähern.
Aber man muss reflektieren dürfen und die Zeit dafür.
Ganz wichtig ja. Das Thema was ich noch hatte,
war jetzt OK. Wir haben diesen Kreislauf
bestehend aus Wartung und Pflege und dem auch dem Refactoring.
Hoffentlich laufen wir irgendwann, ist dann auch dann
doch ein Ende von Software erreicht oder?
Des Lebenszyklus erreicht. Es gibt da manchmal abkündigung
oder ach so ja genau ja das stimmt.
Jetzt hatten wir das vor kurzem im Gespräch mit einem mit einem
potenziellen Kunden. Sagte ja, wir haben halt auf die
Io t Suite, sag ich mal SAP gesetzt in dem Fall also auch
closed Source Software und es AP aus welchem Grund?
Man kann nur mutmaßen, hat er gesagt.
Na ja, das verfolgen wir nicht weiter, und das wird dann damit
eingestellt und abgekündigt passiert immer wieder.
Wie wird das Gehändelt einmal aus Sicht von der Softwarefirma
selber da? Passiert das überhaupt noch?
Sangen das ist ja gekündigt werden und?
Vielleicht den zu schließen zu Open Source ist da mal erwähnt
kann ich da irgendwie als Firma auch vorsorgen, indem ich
vielleicht gleich auf Open Source setzen oder zumindest mir
den Quellcode irgendwie zugänglich mache?
Also ich glaube, das ist irgendwie schwierig, ne entweder
also wird dir was abgekündigt oder kündigst du selber was aber
genau das sind 2 Perspektive sind 2 p genauso also das
schlimme ist natürlich, wenn irgendwas angekündigt wird, so
ja tut mir leid so war oder irgendwas aus irgendwelchen
Tausenden anders gibt irgendwie das Projekt mehr ja.
Ja, dann stehst du natürlich da und dann ist halt die Frage wie
kannst du das quasi tatsächlich loswerden?
Alles und durch ein neues ersetzen?
Das ist bestimmt kostenintensiv und aufwendig, ja und die andere
Möglichkeit, die hast du aber nur dann, wenn es vielleicht
open Source war, ist dann zu überlegen OK, das ist vielleicht
ist es die schlankere und bessere Alternative ist selber
in die Hand zu nehmen, zu warten, oder?
Ist eine oder vielleicht quasi wie groß genug bist, kannst du
ja quasi ein kleiner extra Firma gründen, die nur das Macht, dass
sie quasi das, was vorher gemacht wurde, durch eine andere
Firma wieder übernimmt und weiterentwickelt.
Das kann man glaub ich nicht generalisieren, aber also die
Option alleine hast du nur dann wenn Source ja aber Software ist
nicht zwingend von Anfang an so geplant, dass es irgendwann Ende
gibt, das hat man eigentlich nicht singen.
Ich weiß nicht, ob ich der richtige Antwort Partner bin für
weil also. Schönerweise muss ich sagen, in
meinem Leben habe ich immer Software Projekte entwickelt,
die eigentlich auf unendliche Zeit leben sollten, wenn es geht
ja und sich weiterentwickeln sollten, also bestimmt nicht die
ursprünglichen Codes so aber eigentlich keine kündigungs
Grenze hatten also bei dem zum Beispiel, bei dem ich glaub er
bei dieser Anlage die ich halt allein die Anlage geplant locker
2030 40 Jahre zu stehen und das ist natürlich für Software
Projekte gigantische Zeit, ja vielleicht Quantencomputer, dann
irgendwo hin aber es ist immer darauf angelegt gewesen, dass er
ist. Also es gibt natürlich auch
wegwerfware, ich mag irgendwie App für irgendwas so ja so dann
klar das knallt irgendwie hin so und dann braucht ihr irgendwie
einen ja und dann interessiert auch keinen mehr ja, aber ich
tatsächlich war in solchen Projekten involviert so ja ist
auch ganz schön, das ist ein bisschen wie beim Aftersales, da
kennst du dich besser aus, ne, aber hast du natürlich so hast
du also wenn du ein Software Projekt langlebig hast du einen
After sales Alarm so und hast du natürlich so ein Tamagotchi, was
da einmal raushaust und dann ist auch egal ja, dann ist natürlich
einfacher. Ich habe noch Windows gedacht,
was er jetzt wieder der Fall ist.
Glaub ich Windows 10 jetzt auch wieder keine Updates mehr erhält
also abgekündigt ja genau der jetzt wenn man gezwungen auf
Windows 11 zu gehen um noch weiterhin Updates zu erhalten.
Für die Software Firmen natürlich angenehm irgendwas
anzukündigen und den Produkt an sich Windows bleibt ja da ist
eben nur wieder ne neue Version. Na ja, das stimmt ja ja, aber du
hast natürlich mit der neuen also mit sowas gut.
Das ist natürlich Beispiele sind Betriebssysteme, das die
Endstufe von Software irgendwie? Aber ich glaube, das ist auch
ganz gesund, es geht gar nicht ne, also man kann hohe
Erwartungen ich also zum Beispiel eine ein Beispiel C
plus Plus war als Programmiersprache ist ja auch
quasi krasser Weise die Programmiersprache selber
irgendwie Software, die waren ganz lange dafür bekannt und hat
ewig lange Zyklen. C plus Plus war total stabil,
ewig ja und jetzt haben die C plus 11 haben die angefangen
irgendwie auch ein bisschen schneller zu machen und auch
mal. Denn das ist extrem.
Es ist extrem schwierig, quasi rückwärts kompatibel zu bleiben,
so dass alles noch geht. Das ist aber bei Sprache
natürlich noch wichtiger als bei allen anderen ne, aber es ist
für n für Entwicklung und für eine Software insgesamt
natürlich auch ganz heilsam irgendwas abzuschneiden, ne und
du kannst ja nicht immer den ganzen alten Kram mit dir
herumschleppen und so ja und irgendwann, wenn du mal die
Möglichkeit hast n Neues herauszubringen und sie sagen OK
die alten Kram den Support nicht mehr, dann wird natürlich auch
wieder ganz Kreislauf den du hast ein ganzes Stück schlanker,
weil du nicht so ne so ne riesen Gießkanne.
Den alten Krempel irgendwann kommt ne genau, man muss sich
einfach nur dessen bewusst sein, was es mit sich bringt, wenn man
da ein bisschen abschneidet. Ja, es mag der andere ein
bisschen mehr Aufwand haben, vielleicht sein, aber
langfristig oder auch vielleicht sogar mittelfristig einfach viel
mehr. Das ist halt die Kunst des
richtigen Business, sag ich mal die richtigen Entscheidungen zu
treffen, am Markt zu bleiben und gleichzeitig irgendwie.
In meinem eigenen Einsatz irgendwie schlank zu bleiben,
das ist irgendwie, das war eine richtige Erfolge fand ich ne,
ich hab aber trotzdem was gelernt über Softwareentwicklung
worauf achten ist, ich denke der oder die andere kann da auch was
mitnehmen und würde jetzt aber sagen passt soweit oder Deckel
drauf hast du noch was hinzuzufügen?
Nö, ich lass mal erstmal so wie es ist, glaube ich, dass ihr
denkt daran uns mal ne Bewertung dazulassen ne gute im besten
Fall ja öfter mal gesagt, aber das bringt uns wirklich viel
dass. Sehr nett und ansonsten würde
ich sagen, bis nächste Woche danke zu hören und wenn auch
hier, vielen Dank fürs Zuhören. Hamburg ciao.
Vielen Dank fürs Zuhören dieser Folge von einfach komplex die
Folge gefallen dann lass uns doch ne gute Bewertung da oder
Teile die Folge mit jemanden aus seinem Netzwerk für Kritik
zufolge Anregungen und Fragen für neue Folgen, freuen wir uns
auf deine Email an Podcast dateiserver.com Abonniere jetzt
unseren Podcast, um keine Folge zu verpassen bis zum nächsten
mal Tschüss aus Hamburg h.