Software Qualität beschreibt Praktiken um die Qualität von Software zu messen und sicherzustellen und Fehler zu vermeiden. In diesen Episoden erkunden wir die verschiedenen Aspekte der Software Qualität, einschließlich Tests, Code-Reviews und Qualitätssicherung. Wir besprechen auch, wie Organisationen die Qualität ihrer Software verbessern und wie sie sicherstellen können, dass ihre Software den Anforderungen und Erwartungen der Benutzer entspricht.
Nur unsere eigene Lösung ist die beste: Das "Not invented here" Syndrome (NIH) Ihr kennt das bestimmt: Es gibt eine neue Herausforderung zu lösen. Das Team steigt sofort in die Planung ein, um die Anforderungen in Source-Code zu kippen. Ihr sitzt da und fragt euch: Das kann doch nicht sein, dass wir die einzigen sind, die dieses Problem haben. Da muss es doch schon was fertiges geben.”. Doch das Team wettert dagegen: “Unser Problem ist sehr speziell. Wir bezweifeln stark, dass es da etwas gibt, was unseren Anforderungen standhält. So oder so ähnlich spielt es sich jede Woche in etlichen Teams ab. Es wird die eigene Arbeit über externe Lösungen gestellt. Die Nachteile werden oft später sichtbar. Über dieses Thema sprechen wir in dieser Episode. Nicht nur, was die Gründe dafür sind, sondern auch, wie man dem etwas entgegensetzen kann. Bonus: Warum keiner vor dem "Not invented here"...
Liskov Substitution Principle: Das L in SOLID von Barbara Liskov Heutzutage wird die Informatik und Softwareentwicklung leider primär von Männern dominiert. Doch schaut man ein paar Jahrzehnte zurück, haben viele Frauen maßgeblich die heutige Software-Entwicklung geprägt. Eine Frau war Barbara Liskov. Liskov? Das kennt man doch irgendwoher? Genau. Sie ist unter anderem die Namensgeberin für das L in den SOLID-Prinzipien (die ersten 5 Prinzipien des objektorientierten Designs). Als zweite Frau überhaupt hat Barbara Liskov 2008 den berühmten Turing Award erhalten. In dieser Episode besprechen wir ihr Lebenswerk. Bonus: Barbara Liskov war an den Sprachkonstrukten Exceptions, yield, multiple assignments und multiple returns beteiligt. **** Diese Episode wird gesponsert von https://www.workshops.de Ob öffentliche Schulungen, die du einfach buchen kannst oder maßgeschneiderte Schulungen für...
DORA Metriken: Die Performance-Messung deines Software Development Teams bzw. die Ermittlung des Reifegrades von DevOps in deiner Organisation Softwareentwicklung ist ein kreativer Beruf. Jedes Projekt ist einzigartig und die geschriebenen Lines of Code sagen wenig über die dafür benötigte Zeit aus. Das Research-Programm DevOps Research and Assessment (DORA) versucht dennoch die Performance eines Software-Entwicklungs-Teams zu messen. Nicht via Lines of Code, sondern auf Basis von Aktivitäten, die Value liefern: Deployment Frequency, Lead Time for Changes, Mean Time to Recovery, Change Failure Rate und Reliability. Die Metriken selbst sind weit bekannt. Wie diese Metriken beeinflusst werden können, wer eigentlich dahinter steckt, und was die Organisation eigentlich für eine Kultur vorleben muss, damit es überhaupt zu einem positiven Ergebnis kommt, wissen viele nicht. Und genau darüber...
Zerstört die Anwendung von Clean Code die Performance deiner Applikation? Es war einmal Casey Muratori, ein Softwareentwickler mit Fokus auf Game-Engines, der sich ins Internet gestellt hat und sagte "Clean Code resultiert in schrecklicher Performance". Das YouTube-Video ging um die Welt, die YouTube-Kommentare wurden deaktiviert und Hackernews ging bis an die Decke. Auch der Kopf hinter "Clean Code", Uncle Bob, hat dies nicht auf sich sitzen lassen und ging in die Diskussion. Diese Episode handelt genau um das genannte Video. Wir besprechen, was die Key-Message des Videos ist, wer der Autor ist, was Clean Code ist und von wem es stammt und um was sich die Diskussion zwischen Casey Muratori und Uncle Bob dreht. Eine Art "Reaction-Podcast", sozusagen. Bonus: Was der heilige Gral der Teamentwicklung ist. Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so)
Alte Software akzeptieren oder lieber jedem Update hinterherjagen? Podcast als Video: https://youtu.be/94RZcJefzR8 Das ist die Balance, die jeder finden muss. Wann update ich Software? Wie lange kann ich alte Software betreiben? Ab wann ist alte Software ein wirkliches Risiko? Sollte ich bei jeder neuen Major-Version direkt updaten? Bringt es überhaupt etwas, eine alte Software auf etwas Neues zu migrieren, ohne neue Funktionalität zu bekommen? Welche Risiken verbergen sich hinter den Updates? Ist der klassische Spruch "Never touch a running system" noch aktuell oder sogar ein Fehler? All das und weitere Themenbereiche wie Long-Term-Support, End of Life-Dates, die Software-Metrik Dependency Drift, Dependabot und rostende Software besprechen wir in dieser Episode. Bonus: Warum früher alles besser war, sogar die Zukunft und warum Legacy immer das Geld verdient. Das schnelle Feedback zur...
Schuftest du noch oder automatisierst du schon? Heute gehts um die Faulheit von Entwicklern: Wir sprechen über GitHub Actions - Was es ist, wozu man es benutzen kann, wie es das eigene Leben erleichtern kann, wo der Unterschied zu Jenkins ist, wie das Engineering Kiosk es selbst einsetzt und welche Use-Cases von der Community oft genutzt werden. Bonus: Warum LinkedIn einen HTTP Status Code 999 sendet, wann wir Programmiersprachen wie Unterhosen wechseln und was Michael "Bully" Herbig mit der ganzen Sache zu tun hat.
Code Reviews: Jeder will schnelles Feedback, doch niemand hat Zeit dafür - Eine Hassliebe. Eine Komponente im Alltag jedes Software Engineers. Egal ob Junior, Senior oder Staff-Engineer. Jeder erstellt Code Reviews und kommentiert die Arbeit von den Kollegen. Doch wie sehen gute Code Reviews aus? Was gehört hinein, was bleibt besser draußen? Wie viel Reviewer machen Sinn? Wie geht man mit Nitpicking-Kommentaren und Gatekeepern um? Und allgemein: Zieht dieser zusätzliche Schritt nicht die Performance des Teams runter und ist sowieso Overhead? All das und noch viel mehr in dieser Episode zum Thema Code Reviews. Bonus: Was Faultiere und Markus Söder mit Code Reviews zu tun haben und warum Blubberwasser den Charakter verdirbt.
Kommentare im Quellcode und Git Commit Messages - Liest die überhaupt wer? Ein Streit, der so alt ist wie die Software Entwicklung selbst: Code ist Selbsterklärend und braucht keine Kommentare. Oder doch? Und die Git Historie ist auch eigentlich sinnlos. Warum sollte da jemand zurück gehen und sich die Commit Messages durchlesen? Diese Fragen und Themen wie Semantic Versioning, Idiomatische Programmier-Patterns, Merge Commits, Story-Tellung und was Fynn Kliemanns Kunst mit der Git Branch-Visualisierung zu tun hat, klären Wolfgang und Andy in dieser Episode vom Engineering Kiosk. Bonus: Warum Andy einen neuen Podcast-Partner sucht und Wolfgang lieber seinen Code angreift, anstatt Ihn zu entwickeln.
TeamSoftware EngineeringSoftware Qualität
