Software Architektur im Stream

Auch Architektur-Entscheidungen müssen wirtschaftlichen Zielen unterordnen. Michael Mahlberg erläutert, warum das so ist - und wie bereits ein kleiner Werkzeug-Koffer dabei hilft, Architekturentscheidungen und -strategien bewertbarer zu machen. Material: https://bit.ly/oop2021-di24

Oft wird Software immer schlechter wartbar, je länger Entwicklungsteams an ihr arbeiten. Dazu hat sich die Metapher “technische Schulden” etabliert. Aber es ist nicht immer sinnvoll, technische Schulden zu beseitigen und sie können auch “einfach so” entstehen. Darüber sprechen wir - und über die Grundlagen der Metapher, wie sie bei der Kommunikation mit Managern hilf, warum die Metapher eigentlich nicht besonders gut gewählt ist und natürlich wie man mit technischen Schulden sinnvoll umgehen kann. Links Ward Cunningham über Technical Debt im c2 WikiWard Cunningham über Technical Debt bei YouTubeheise Podcast zu technische SchuldenBlog “Technische Schulden entstehen einfach so”Artikel über Qualitätsinvestitonen mit Felix Müller - ENArtikel über Qualitätsinvestitonen mit Felix Müller - DEArtikel Umgang mit technischen SchuldenSE Radio zu technical debt mit Sven Johann - ENArtikel Managing Technical Debt mit Sven Johann - ENTechnical Debt Conference

Simon Brown is the author of Software Architecture for Developers; a developer-friendly guide to software architecture, technical leadership and the balance with agility. He is also the creator of the C4 software architecture model and the founder of Structurizr, a collection of tooling to help software teams visualize, document and explore their software architecture. So naturally we will talk about software architecture - and how C4 and Structurizr help! Links: https://simonbrown.je/ https://c4model.com/ https://structurizr.com/

Eine der größten Herausforderungen, denen sich Software-Entwickler und Technical Leads stellen müssen, ist der Umgang mit Legacy und technischen Schulden. Diese Herausforderung wird immer schwieriger, da die Lebensdauer von Software mit dem Aufkommen neuer Technologien steigt und die Verweildauer in Unternehmen immer kürzer wird. Wie kann man diese Herausforderung angehen, ohne Software dauernd neu zu schreiben?

Patrick Kua was CTO and Chief Scientist at N26 in Berlin and is now an independent coach and mentor to CTOs and VPs Engineering. Patrick has written several books e.g. about how to talk to tech leads and he co-authored a book about evolutionary architecture. In this episode we will therefore discuss how software architecture can embrace change and support business goals in the long run. Patrick’s home page Patrick’s newsletter Command line tools for architecture decision records (ADRs) Architecture elevator (Gregor Hohpe)

Pattern für Software-Entwicklung gibt es schon seit mehr als 25 Jahren. Aber schon davor gab es Patterns für Dinge z.B. in der Gebäude-Architektur. Und mittlerweile sind auch Patterns für andere Bereiche entstanden. So erlauben sie den Zugriff auf Erfahrungen über den Umgang mit Code und Menschen. Sogar Refactorings sind eigentlich Patterns für den Umgang mit Code. Links Patterns Christopher Alexander: “The Timeless Way of Building”, 1979, Oxford University Press, ISBN 978-0-19-502402-9 Peter Gabriel: “Patterns of Software” Kevlin Henney, Frank Buschmann et al: “Pattern-Oriented-Software-Architecture 1-5” POSA 1-5 , besonders POSA 5 Gregor Hohpe, Bobby Woolf: “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions”, 2003, Addison Wesley, ISBN 978-0-32-120068-6 Gerard Mezaros: “xUnit Test Patterns: Refactoring Test Code”, 2007, Addison Wesley, ISBN 978-0-13-149505-0 Refactoring Michael Hungers Studienarbeit zu Refactoring Refactoring 2nd Ed Vortrag beim JUG Saxony Day Martin Fowler: “Refactoring: : Improving the Design of Existing Code”, 2nd Edition, 2018, Addison Wesley, ISBN 978-0-13-475759-9 Martin Fowler: Refactoring 2nd Edition Web Version Joshua Kerievsky: “Refactoring to Patterns”, 2004, Addison Wesley, ISBN 978-0-32-121335-8 Kent Beck: “Implementation Patterns”, 2007, Addison Wesley, ISBN 978-0-32-141309-3 Pramod Sadalage: “Refactoring Databases: Evolutionary Database Design”, 2011, Addison Wesley, ISBN 978-0-32-177451-4 Steve Freeman, Nat Pryce: “Growing Object-Oriented Software, Guided by Tests”, 2009, Addison Wesley, ISBN 978-0-32-150362-6 Adam Tornhill: “Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs”, 2015, O’Reilly, ISBN 978-1-68-050038-7 Adam Tornhill: “Software Design X-Rays: Fix Technical Debt with Behavioral Code”, 2018, O’Reilly, ISBN 978-1-68-050272-5 , Software Design jQAssistant Michael Feathers: “Working Effectively with Legacy Code”, 2013, Addison Wesley, ISBN 978-0-13-117705-5 Leute Dave Hoover, Adewale Oshineye: “Apprenticeship Patterns: Guidance for the Aspiring Software”, 2009, O’Reilly, ISBN 978-0-59-651838-7 Philip Armour: “The Laws of Software Process”, 2003, Auerbach, ISBN 978-0-84-931489-6 Linda Rising: “Fearless Change: Patterns for Introducing New Ideas”, 2015, Addison Wesley, ISBN 978-0-13-439525-8

In dieser Ausgabe diskutieren Uwe Friedrichsen und Eberhard Wolff das Für und Wider von Microservices.

Inner Source nutzt Open-Source-Methoden für die Entwicklung von Software innerhalb eines Unternehmens. Auf den ersten Blick scheinen Entwickler:innen so nur einfach Code teilen zu können, aber es hat weitreichende Konsequenzen und kann dazu dienen, Silos in Unternehmen einzureißen und so die Organisation zu verbessern. Prof. Dirk Riehles forscht in diesem Bereich und wird berichten, wie Inner Source in der Praxis funktionieren kann. Links zu Inner SourceInner Source Commons: Eine Non-Profit zur Verbreitung von Inner SourceFallstudien zu Inner Source (Video)Einfacher Rat, um mit Inner Source zu beginnen (Short Post)Was Dirk so zu Inner Source zu sagen hatBücher zu Forschungsmethoden im Software EngineeringFelder & Travassos, Contemporary Empirical Methods in Software Engineering, Springer 2020.Runeson et al., Case study research in software engineering, Wiley 2012.Wohlin et al., Experimentation in Software Engineering, Springer 2012.Das von Eberhard gennante Buch:Laurent Bossavit: The Leprechauns of Software Engineering

Anja Kammer erklärt in dieser Folge, warum und wie man keine DevOps Engineers einstellt - und warum DevOps als Begriff leider immer noch missverstanden wird. Dabei geht es auch um Team Topologys, mit denen die Organisation von Teams und die Kommunikation zwischen Teams visualisiert und optimiert werden kann. Links: DevOps Topologies DevOps Handbook Team Topologies

In dieser Folge diskutiert Johannes Seitz sokratische Gespräche. Das ist ein Möglichkeit, um nicht nur Grundlagen wie Information Hiding zu vermitteln, sondern die sich auch sonst gut für Consulting und Training eignet. Johannes hat vor allem in Remote-Szenarios damit gute Erfahrungen gemacht. In dieser Folge erläutert Johannes, was sokratische Gespräche sind und wie man sie führen kann. Links: Johannes Artikel Justice Course