Schlagwortarchiv für: devcraft

.NET Legacy Software: Mit Approval Tests und Specflow fit für die Wartung

Wer kennt das nicht: Eine Software läuft seit Jahren stabil. Nun ändert sich die Rechtslage. Oder Teile der Infrastruktur, mit der sie läuft, werden vom Hersteller nicht mehr unterstützt. Häufig ist die Software jedoch nicht ausreichend mit Tests ausgestattet, um die notwendigen Änderungen durchzuführen. Entwickler stehen dadurch vor dem Problem, dass sie mit jeder vorgenommenen Änderung unvorhersehbare Nebeneffekte auslösen können. Ein Risiko, das kein Entwickler gerne eingeht. 

In diesem Artikel zeigen wir Ihnen drei Möglichkeiten, um Ihre Legacy Software zu warten, wenn diese nicht ausreichend mit Tests ausgestattet ist. Neben den jeweiligen Vor- und Nachteilen gehen wir vor allem auf den Einsatz des Approval Test Frameworks in Kombination mit Specflow ein. 

Wir haben diesen Ansatz gewählt, weil er kosteneffizient ist und die Testfälle ohne Programmierung erstellt werden können.

3 gängige Ansätze für die Qualitätssicherung von Altanwendungen

In der Praxis gibt es im Wesentlichen drei Strategien, mit der Qualität von Legacy Software umzugehen. Nicht alle erfüllen jedoch moderne Standards der Softwareentwicklung:

Testing beschränkt auf manuelle Tests
Es werden keine automatisierten Tests durchgeführt. Das heißt: Alle Tests müssen manuell durchgeführt werden. Das führt in der Regel zu einer höheren Unsicherheit. Beim manuellen Testen sind die Entwickler bzw. Tester stark von dem Know-how über die Anwendung abhängig. Automatisierte Tests kann hingegen jeder laufen lassen. Wenn ein Test fehlschlägt, muss der Entwickler nur die entsprechende Stelle analysieren.

Zusätzlich wird deutlich mehr Zeit benötigt, um manuelle Tests durchzuführen. Gleichzeitig ist die Wahrscheinlichkeit für (weitere) Fehlermeldungen höher. Manuell können selbst die besten Tester mal etwas vergessen. Der automatisierte Test läuft hingegen immer und prüft verlässlich alle definierten Szenarien.

Nachträgliche Ausstattung mit automatisierten Tests
Eine weitere Option ist es, dass Sie die Altanwendung nachträglich mit automatisierten Tests, wie zum Beispiel Unit Tests, oder automatisierten Akzeptanztests ausstatten. Letzteres ist die Standardlösung für neue Anwendungen. Sie wird daher als Erstes angedacht, wenn die Effizienz der Wartung von bestehenden Lösungen erhöht werden soll.

Eine nachträgliche Ausstattung ist in der Regel jedoch sehr teuer. Zudem muss tiefes Know-how über die Zusammenhänge der Domäne (wie die Logik der Anwendung) vorhanden sein. Daher ist diese Option nur mit großem Arbeitsaufwand umsetzbar. In einigen Fällen kann sie aufgrund der Architektur auch gar nicht eingesetzt werden.

Specflow-unterstützte Approval Tests
Mit einer Kombination aus Approval Tests und Specflow kann die Stabilität von Legacy Software nachgewiesen werden. Hierfür werden End-to-End-Tests eingesetzt. Das führt zu deutlich geringeren Kosten als die Nutzung von Unit Testing oder automatisierten Akzeptanztests (wenn man sie im Nachhinein einführt).

Denn mit Specflow-unterstützten Approval Tests lässt sich ein automatisierter Vergleich zwischen dem bestehenden Verhalten und dem Verhalten nach Änderungen umsetzen. So können die Entwickler nach Änderungen überprüfen, ob sich die Software insgesamt noch gleich verhält wie zuvor.

Approval Tests mit Specflow bietet aus unserer Sicht eine schlanke, erweiterbare, und gleichzeitig sichere Möglichkeit, um die Stabilität und Wartbarkeit einer Legacy Anwendung zu erhöhen.

So funktionieren specflow-unterstützte Approval Tests

Zur Umsetzung von Approval Tests mit Specflow werden folgende Schritte durchgeführt: 

  1. Feature Files erstellen: Es werden Feature Files (gherkins) erstellt, die die Eingangsparameter beschreiben und diese mit dem dazugehörigen Methodenaufruf verknüpfen.  
  2. Ergebnisse aufzeichnen: Beim Aufruf der Methode zeichnet das Approval Test Framework die Ergebnisse auf, die die Anwendung für die definierten Eingangsparameter liefert. 
  3. Golden Master erstellen: Die Ergebnisse werden als sogenannter Golden Master gespeichert. 
  4. Weitere Durchläufe: Bei weiteren Durchläufen (nach Umsetzung von Änderungen) dient dieser Master als Vergleichsbasis für den Integritätscheck des Verhaltens. 

Durch dieses Vorgehen ergibt sich eine Reihe von Vorteilen: 

  • Es entsteht kein Programmieraufwand für die Tests. 
  • Die Tests werden stets aktuell gehalten. Denn für jedes korrekt geänderte Verhalten wird der Master überschrieben. 
  • Außerdem können Sie diese Lösung schrittweise aufbauen, da sie für jede technische bzw. inhaltliche Komponente separat implementierbar ist. 
  • Ein weiterer Vorteil gegenüber z. B. Unit Tests ist, dass die Tests das Verhalten aus Usersicht prüfen. Damit ist es möglich, voll integriert zu testen.

Mehr Sicherheit und weniger Aufwand bei der Wartung von Legacy Software

Specflow-unterstützte Approval Tests bieten uns bei TechTalk die nötige Sicherheit, auch Anwendungen im letzten Drittel ihres Lifecycle verlässlich ändern und ausliefern zu können. Der Aufwand ist deutlich geringer als der Aufwand für eine nachträgliche Ausstattung mit Unit Tests. 

Für stark UI-lastige Anwendungen, vor allem wenn viel Logik im UI implementiert ist, empfehlen wir sie nicht. Bis auf diese Ausnahme ist die Methode theoretisch für alle Fälle geeignet. Aus unserer Sicht ist diese Methode vor allem für datengetriebene Verwaltungs-Domänen sinnvoll. 

Im Einzelfall muss jedoch stets die konkrete Architektur der Legacy Software betrachtet werden, um eine Entscheidung über die bestmögliche Methode zu treffen. Denn die gewählte Lösung muss immer zur jeweiligen Software passen.


Haben Sie Fragen?

  • Sie wollen mehr zum Thema specflow-unterstützte Approval Tests wissen?
  • Sie benötigen Unterstützung bei der Wartung Ihrer Legacy Software?

Thomas Korosa steht Ihnen für weitere Fragen über Xing oder Mail zur Verfügung.


Haben Sie eine Legacy Software im Einsatz die modernisiert gehört?

Nutzen Sie unser Angebot der kostenlosen Analyse im Rahmen des TechTalk Relax Application Management Service.

4 Mythen über agile Software Wartung, denen Sie keinen Glauben schenken sollten

„Wir können nicht agil arbeiten, wir machen nur Wartung!“ – Kommt Ihnen diese Aussage bekannt vor?

Finden Sie heraus, wie Sie mit den dahinterstehenden Annahmen aufräumen können und wie Sie mit einer agilen Arbeitsweise in der Wartung Ihre Geschäftsziele leichter erreichen.

Mythos 1: die ideale User Story

Das Team sagt: „Wir können nicht mit User Stories arbeiten, weil wir Issues zur Bearbeitung bekommen und kaum Features entwickeln.“ 

Egal, ob Sie in Ihrem Team von Issues, Fehlermeldung oder Bugs reden: Dieses Argument ist auf eine Idealvorstellung einer User Story zurückzuführen, die in den Schulungen vermittelt wird. Tatsächlich ist es auch bei laufender Software sinnvoll, Anforderungen nach den INVEST Kriterien zu formulieren, um sicherzustellen, dass sie effizient und effektiv umgesetzt werden können. 

Was sind die Besonderheiten der INVEST Kriterien in der Softwarewartung?

  • Independent: Die meisten Issues zu laufender Software sind unabhängig, da sie sich auf einen einzelnen Aspekt beziehen, der nicht oder nicht mehr wunschgemäß funktioniert. Wenn der Issue komplexer ist, spricht alles dafür, ihn in unabhängige Backlog Items aufzuteilen, damit die Umsetzung planbar wird.

  • Negotiable: Das Ergebnis einer User Story muss verhandelbar sein. Auch für Issues in laufender Software gibt es meistens mehr als eine mögliche Lösung. Auch in der Softwarewartung ist es sinnvoll, über die Lösung zu verhandeln, die die Anforderungen zu den geringstmöglichen Kosten erfüllt. 

  • Valuable: Eine User Story muss einen klar herausgearbeiteten Business Value haben. In der Wartung spielt es sogar eine noch größere Rolle, dass der Wert der Lösungen klar ist. Denn die Bereitschaft zu investieren, sinkt mit zunehmender Lebensdauer der Anwendung. Der Wert ist die Voraussetzung für eine Priorisierung, bei der jeweils der Issue umgesetzt wird, der aktuell den höchsten Business Value bringt. 

  • Estimable: User Stories müssen schätzbar sein, damit das Umsetzungsteam sich zu einem Umsetzungsplan verpflichten kann. Es spielt dabei keine Rolle, ob es sich um eine Neuentwicklung oder eine Änderung einer Software handelt. 

  • Small: User Stories müssen klein genug sein, dass sie innerhalb des Planungszeitraums, zum Beispiel eines Sprints, einen Business Value liefern. Die Diskussion darüber wird im Team hauptsächlich geführt, damit die Erwartungen auf den Tisch kommen. Dies gilt für Neuentwicklungen und Weiterentwicklungen, sowie Fehlerbehebungen gleichermaßen. 

  • Testable: Um nachweisen zu können, dass der vereinbarte Business Value geliefert wurde, muss jedes Backlog Item testbar sein. In der Wartung ist der Nachweis der Funktionsfähigkeit, abhängig vom Release-Zyklus, oft noch wichtiger als im Verlauf der Neuentwicklung.

Fazit: Es ist nicht unbedingt notwendig, dass jede Anforderung sich in eine idealtypische Story verpacken lässt. Die Orientierung an den INVEST Kriterien ist auch bei Altanwendungen sinnvoll und möglich.

Mythos 2: Scope Management ist unnötig

Der Produktmanager sagt: „Wir brauchen kein Backlog, wir machen ohnehin nur mehr Dinge, die wir unbedingt machen müssen.“

Diese Meinung drückt die Erwartung aus, dass die Benutzer nur absolut notwendige Arbeiten in Auftrag geben, da die Anwendung ihr Einsatzende fast erreicht hat. Diese Anwendungen wurden meistens nach dem Wasserfall-Modell entwickelt, das heißt alle Funktionalitäten wurden vorab spezifiziert und – häufig Jahre später – umgesetzt ohne noch einmal nach dem Nutzen zu fragen. Im Wasserfall-Modell geht man davon aus, dass alles umgesetzt werden muss, was spezifiziert wurde.

Gerade bei Altanwendungen am Ende ihres Lebenszyklus hilft ein agiles Vorgehen, weil es die Optimierung des Business Value in den Mittelpunkt stellt. Durch eindeutige Priorisierung und Umsetzung mit dem Business Value im Fokus kann die Entwicklung jederzeit beendet werden, sobald der zusätzliche Nutzen geringer ist als die zusätzlichen Kosten. Die Praxis zeigt, dass Benutzer und Umsetzer am besten gemeinsam über die optimale Nutzung des bereitgestellten Budgets entscheiden können. 

Fazit: Aktives Scope Management ist die Voraussetzung dafür, dass nicht nur das Budget im Rahmen bleibt, sondern auch das Ergebnis optimiert wird. Das gilt in der Wartung genauso wie bei der Neuentwicklung.

Mythos 3: Störungen haben Vorrang

Das Team sagt: „Wir können nicht mit der Bearbeitung dringender Fehlermeldungen warten, bis der Sprint vorbei ist. Wir müssen uns sofort darum kümmern.“ 

Dieser Mythos ist auf die herrschende Meinung zurückzuführen, dass nur eine sofortige Reaktion auf alle Inputs von Kunden oder Benutzerinnen als kundenfreundlich gilt. Nach dem Push-Prinzip werden alle Anforderungen, die vom Kunden dokumentiert wurden, sofort in Bearbeitung genommen. Viele werden aber lange nicht fertig, zum Beispiel weil es offene Fragen gibt oder weil das bemängelte Verhalten auf dem Testsystem nicht reproduzierbar ist. Die Konsequenz ist häufig, dass sich eine lange Liste von Issues „in Bearbeitung“ befindet. 

Die Wahrheit ist: Die meisten Issues sind gar nicht so dringend. Eine bewusste Priorisierung hilft dabei, die richtigen Anforderungen umzusetzen und so den Business Value zu optimieren. Das agile Team bearbeitet immer nur so viele Issues, wie tatsächlich umgesetzt werden können. Es stellt diese fertig, bevor es neue aus dem Backlog annimmt. 

Fazit: Wer nach dem Pull-Prinzip vorgeht, statt nach dem Push-Prinzip, arbeitet effizienter, erledigt mehr und wird mit den wirklich wichtigen Aufgaben verlässlich fertig. Dies gilt auch in der Wartung.

Mythos 4: das Highlander Syndrom

Die Entwickler sagen: „Wir sind kein Team. Jeder von uns hat sein Spezialgebiet.“

In der Vergangenheit waren Produktentwicklungsteams häufig eher eine Gruppe von Spezialisten als ein Team. Die zugrundeliegende Annahme war, dass Experten Probleme aufgrund ihres tiefen Wissens effizienter lösen, jedoch wurden bald die Nachteile dieser Arbeitsteilung evident:

  • Viele Kommunikationsschnittstellen zwischen den einzelnen Experten 
  • Langwierige Fehleranalysen unter Beteiligung mehrerer Experten 
  • Jede Person wird zum Flaschenhals für das ganze System und verursacht bei Abwesenheit oder zu hoher Auslastung lange Wartezeiten für das gesamte System

Mit der Verlagerung zu Full-Stack Entwicklung und T-Shaped oder M-Shaped Skills rückt auch die Zusammenarbeit stärker in den Vordergrund. Teams mit bewusst gestalteter Zusammenarbeit bauen gemeinsames Wissen auf und können gerade komplexe Probleme in Altanwendungen schneller lösen. Personalwechsel können so auch wesentlich leichter kompensiert werden. In Summe überwiegen die Vorteile der Zusammenarbeit nach agilen Prinzipien.  

Fazit: Agile Teamarbeit unterstützt die hohen Anforderungen, die in der Softwarewartung an Reaktionsfähigkeit und Aufrechterhaltung des Wissens gestellt werden, besser als Expertentum.  

Kein Mythos: die wahre Herausforderung für Agilität in der Softwarewartung

Die wahre Herausforderung für Agilität liegt bei Altanwendungen meistens in der Qualitätssicherung. Mangelnde Wissensteilung, geringe Abdeckung mit dokumentierten – am besten automatisierten – Tests und eine intransparente Schnittstelle zum Betrieb sind die unausgesprochenen Gründe, warum viele Entwickler nicht in der Wartung arbeiten wollen. 

Hinzu kommt ein hoher Aufwand für die Qualitätssicherung auf allen festgelegten Ebenen (Stages). Es muss sichergestellt sein, dass Änderungen im Code keine unerwünschten Nebenwirkungen verursachen. Hierfür sind zahlreiche manuelle Schritte mit langen Wartezeiten und enormem Koordinationsaufwand notwendig.

Zu den wichtigsten agilen Prinzipien gehört, häufig zu releasen und inkrementelle Änderungen für die Benutzer bereitzustellen. Bei Altanwendungen hilft das agile Vorgehen oft, die Flaschenhälse zu identifizieren und Schritt für Schritt zu beseitigen.

Schlussendlich wird auch eine Releaseplanung mit fixen Releasezeitpunkten durch agiles Arbeiten unterstützt. Durch laufende Priorisierung wird sichergestellt, dass die jeweils wichtigsten Features (bzw. Fehlerbehebungen) umgesetzt werden und der Releasetermin eingehalten wird.  

Wie schaut agiles Arbeiten in der Softwarewartung konkret aus?  

Bei TechTalk arbeiten wir in der Wartung agil mit einem fixen Team. Das bedeutet für unsere Kunden geteiltes Wissen und garantierte Reaktionsfähigkeit – auch langfristig. 

Wir kombinieren ein Kanbanboard mit regelmäßigen Retrospektiven und Plannings nach Scrum. Das Kanbanboard erlaubt einerseits flexible Reaktion, wenn ein dringender Fehler gemeldet wird, unterstützt aber andererseits auch jederzeit die Selbstorganisation des Teams. Die Prioritäten werden klar abgebildet, was kontinuierliche fokussierte Umsetzung bedeutet. Die sogenannte „Emergency Lane“ zeigt auf einen Blick, ob etwas Dringendes außerplanmäßig zu erledigen ist.  

Sowohl Kanban als auch Scrum bieten einen Rahmen, in dem Entwickler fokussiert arbeiten können.  

Die Elemente aus Scrum erleichtern den Abgleich mit der Roadmap aus der Planung und unterstützen die laufende Evaluierung und Anpassung der Prozesse. Durch die regelmäßige rollierende Planung haben auch unsere Kunden mehr Transparenz. Planänderungen können von beiden Seiten frühzeitig eingebracht und auf ihre Konsequenzen geprüft werden.  

Im Umsetzungsteam sind agile Praktiken etabliert, mit denen ein durchgängiger Qualitätsstandard sichergestellt wird. Mehr Informationen dazu finden sich im Experteninterview mit Thomas Korosa


Haben Sie eine Legacy Software im Einsatz, die modernisiert gehört?

Nutzen Sie unser Angebot der kostenlosen Analyse im Rahmen des TechTalk Relax Application Management Service.

Get to know TechTalk: Interview mit Senior Dev Michael Altmann

In unserer Interviewserie “Get to know TechTalk” stellen wir TechTalk Mitarbeitende vor. Diesmal verrät uns Senior Developer und Tech Lead Michael Altmann, der bereits seit 2013 bei TechTalk tätig ist, mit welchen Methoden er arbeitet, was die Rolle eines Tech Leads ausmacht und welche Herausforderungen es im Entwicklungsprozess gibt.

Was ist dein aktuelles Aufgabengebiet bei TechTalk?

An vier Tagen pro Woche arbeite ich als Tech Lead eines 7-köpfigen Developer Teams für einen Kunden aus dem öffentlichen Bereich. Freitags bin ich meist im TechTalk Büro. Dabei unterstütze ich unter anderem Teams und Developer innerhalb der TechTalk bei der Umsetzung von Projekten, führe Bewerbungsgespräche und trage durch die Organisation sowie Moderation von internen Formaten wie z.B. dem TechDiscuss zum Wissensaustausch bei.

Was macht die Rolle des Tech Leads aus und was gefällt dir besonders daran?

Ich finde die Rolle des Tech Leads sehr spannend und vor allem abwechslungsreich. Gemeinsam mit dem selbstorgansierten Team werden technische Lösungen entworfen und umgesetzt. In Zusammenarbeit mit Product Ownern sowie UX Designern bei der Anforderungserhebung ist man mit dem technischen Input auch am Produktdesign beteiligt. Die Rolle erfordert aber auch Leadership-Fähigkeiten. Die Skills jedes Teammitglieds müssen erkannt und Dynamiken im Team beobachtet werden. Nichtsdestotrotz muss auch Zeit zum Programmieren bleiben, damit die Beziehung zum Code nicht verloren geht.

Mit welchen Methoden löst du Herausforderungen im Entwicklungsprozess?

Als Tech Lead löse ich Herausforderungen an mehreren Fronten. Je nach Problem, Ziel und Team setze ich entweder eine spezifische oder eine Kombination aus mehreren Methoden ein, wobei ich darauf achte, dass mich die Methode im Daily-Doing unterstützt und nicht einschränkt. Dabei kommen immer agile Vorgehensweisen zum Einsatz, meistens Scrum, manchmal auch Kanban.

Darüber hinaus nutze ich bei komplexeren Domänen das Konzept des Domain Driven Designs. Das Ziel ist ein vereinfachtes Modell der Domäne, die das gesamte Team versteht, im Code abzubilden. Domain Driven Design lässt sich sehr gut mit Behavior Driven Development kombinieren, da beide eine gemeinsame Sprache zwischen Entwicklungsteam und Stakeholder als Ziel haben. Impact Mapping und Story Mapping sind ebenfalls Methoden, die ich regelmäßig verwende. Darüber hinaus ist Continuous Integration/Continuous Delivery wichtig, um in kurzen Zeitabständen das System in Betrieb zu setzen und Business Value liefern zu können. Wir experimentieren aber auch gerne mal und probieren unterschiedliche Methoden wie Event oder Story Storming aus.

In welchen Projekten hast du bei TechTalk bereits gearbeitet?

Zu Beginn meiner Karriere habe ich vor allem in In-House sowie Wartungsprojekten gearbeitet. Das waren eher kleine Teams, in denen ich meist mehrere Rollen übernommen habe, zum Beispiel die des Entwicklers und auch die des Product Owners. Besonders spannend war, in die verschiedenen Positionen hineinschnuppern zu können. Hierfür bin ich TechTalk sehr dankbar, dass so viel Vertrauen in mich gesetzt wurde. Mittlerweile bin ich hauptsächlich für Kundenprojekte zuständig. Beim aktuellen Kunden haben wir ein Scrum-of-Scrum Setup, welches aus 7 “cross functional teams” besteht.

Wie sieht dein Arbeitsumfeld aus?

Unabhängig vom Projekt ist es generell so, dass die TechTalk eine flache Hierarchie hat. Für mich bedeutet das, dass ich mich aktiv einbringen kann und so der Wissensaustausch unter Devs, UX Designern und Testern gefördert wird. Was ich zudem sehr schätze sind die netten Kolleginnen und Kollegen, von denen man sehr viel lernen kann. Ich bin bereits fast sieben Jahre bei TechTalk, dabei sind schon einige gute Freundschaften entstanden.

Wie kann man sich den Wissensaustausch unter EntwicklerInnen bei TechTalk vorstellen? Wie teilt ihr euer Wissen?

Zum einen gibt es den Austausch intern im Projektteam. Damit jedoch keine Wissenssilos entstehen, wurden bei TechTalk einige Formate etabliert, die dazu beitragen, den Austausch über Teamgrenzen hinweg zu fördern. In diesen Sessions werden unterschiedliche Themen diskutiert – von „Code Kommentare“ bis zu „Aufgaben des Tech Leads“ ist alles dabei. Aber auch Coding Dojos und Projektvorstellungen werden regelmäßig abgehalten. Dabei stehen immer die Diskussion sowie der Austausch im Vordergrund. Durch die verschiedenen Formate werden regelmäßig Entwickler-News, Updates oder Buchempfehlungen geteilt. Eine meiner Empfehlungen ist das Buch „Unit Testing Principles Practices Patterns“ von Vladimir Khorikiv.

Wie unterstützt dich TechTalk, damit du dich Themen abseits deiner Kundenprojekte widmen kannst?

In dem Rahmenbedingungen geschaffen werden, um Ideen zu diskutieren und diese auch umsetzen zu können. Das fördert den Mut, Experimente zu machen. Generell ist man nicht zu 100% seiner Arbeitszeit in Projekten verplant. Zudem gibt es sogenannte  Circles, Interessensgruppen, welche dazu motivieren, sich der Themen abseits des Arbeitsalltags anzunehmen und voranzutreiben. Hier kann man unabhängig einer Rolle beitreten und mitwirken.

Welche Konferenzen und Meetups würdest du Devs ans Herzen legen – auch in Zeiten von Corona?

Ich wähle Konferenzen und Meetups, die ich besuche, je nach persönlicher sowie beruflicher Weiterentwicklung und Interesse aus. Derzeit ist das Domain Driven Design, weil es mir eine Sammlung von Methoden bietet, mit denen ich gute Erfahrungen gemacht habe. Erst vor kurzem habe ich am remote DDD Meetup in London teilgenommen. Zum Schluss ein kleiner Tipp: Jetzt in Zeiten von Corona bieten die meisten Meetups Videoübertragungen an – wieso also nicht mal ein Meetup in New York, Oslo oder Sydney besuchen?

Auch die TechTalk organisiert regelmäßig Trainings und Workshops mit international hochkarätigen Speakern. Wirf einen Blick auf unser Trainingsangebot oder kontaktiere uns gerne direkt.

Möchtest auch du Teil der TT Familie werden?

Dann sieh dir hier die aktuellen Jobausschreibungen an:

Questions About Test Frameworks: Q&A Part #3 with J.B. Rainsberger

This is the third chapter of our three-part Q&A blog series with J. B. Rainsberger. In this chapter he adresses questions about „Questions About Test Frameworks. The first chapter and the second chapter is in our blog in case you missed it.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.


J. B. Rainsberger helps software companies better satisfy their customers and the business that they support.

Our next remote course Surviving Legacy Code from 12 – 15 April 2021.


If the code base is too old even for any available test frameworks, how you handle it?

**Testing does not need frameworks. Testing never needed frameworks.** You can always start by just writing tests and refactoring them. If you do this long enough, you will extract a testing framework. If you’ve never tried it, then I recommend it! Kent Beck’s _Test-Driven Development: By Example_ included this exercise.

Every test framework began life with `if (!condition) { throw Error(„Test failure.“) }`. If you can write this, then you can build a testing framework; if this suffices, then you don’t need a testing framework. Start there!

If you can execute one part of the system in isolation from the rest, then you can write unit tests. In the early days of web browsers, we could only execute Javascript in the browser, because even so, we could (and did!) write unit tests without frameworks. We merely had to run those tests in a browser window. Eventually, someone decided to run Javascript outside the browser, which made it easier to write microtests for Javascript code. This made it _easier_ to write tests, but we were writing tests long before NodeJS existed.

If you can invoke a function (or procedure or division or block of code) and you can signal failure (such as by raising an error), then you can write tests without waiting for someone else to build a framework.

In addition, you don’t need to write your tests in the same language or environment as the running system. Golden Master technique helps us write tests for any system that offers a text-based interface. Any protocol could help us here: for example, think of HTTP as „merely“ a special way of formatting requests and responses with text. If you have (or can easily add) this kind of interface or protocol to your system, then you can write tests in any language that might offer a convenient test framework. Use Python to test your COBOL code. Why not?

Finally, not all testing must be automated. As I wrote earlier, programmers have a strong habit of forgetting alternatives to techniques that they’ve found helpful. If you don’t know how to automate your tests easily, then don’t automate them yet. Instead, make them repeatable and document them. One day, someone will have a good idea about how to automate them.

You may have to write your own test framework but it can prove a daunting task.

In addition to what I wrote in the previous answer, I encourage you to follow the general advice about building any software with a Lightweight (Agile, Lean, …) approach: build the first feature that you need, then start using it, then add more features one at a time. You don’t need to build a fully-featured testing framework before you start to benefit from it. Start with `if (!assertion) throw Error()` and then use it! The testing framework SUnit was built incrementally. All the testing frameworks you know began from there. You can do it, too. Merely start, then take one step at a time.

You also need this refactoring-without-tests skill, to effectively refactor your tests!

Maybe! I don’t say you _need_ it, but it would probably help you. Your production code helps you to refactor your tests: if you change your tests and they now expect the wrong behavior, then your production code will fail that test for „the right reasons“. It doesn’t provide perfect coverage, but it helps more than you might expect. In that way, the production code helps to test the tests.

There are testing frameworks for COBOL and NATURAL. What could be older?

Indeed, the „framework“ portion of testing relates to identifying tests, collecting test results, and reporting them in a unified way, as well as adding standard mechanisms for „set up“ and „tear down“. We don’t need those things to start writing tests, although eventually we will probably want to have them. **Simply start writing tests, then remove duplication in any way that your programing language allows.** I don’t know what might be older than COBOL or NATURAL.


➡️ Also read our last two Q & A Blogposts with J.B. Rainsberger Part #1 „Managing the Uncertainty of Legacy Code“ and Part #2 „The Risks Related to Refactoring Without Tests„! Follow us on Twitter or LinkedIn to get new posts.


The Risks Related to Refactoring Without Tests: Q&A Part #2 with J.B. Rainsberger

This is the second chapter of our three-part Q&A blog series with J. B. Rainsberger. In this chapter he adresses questions about „The Risks Related to Refactoring Without Tests. The first chapter and the third chapter is in our blog in case you missed it.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.


J. B. Rainsberger helps software companies better satisfy their customers and the business that they support

Our next remote course Surviving Legacy Code from 12 – 15 April 2021.


What we should say to project planners who are afraid to let us do refactoring without tests, because some folks in our team are not very good at refactoring and make mistakes? How to convince them it can work for some good programmers?

First, I recognize that if I were the project planner, then I would worry about this, too! I probably don’t know how to judge the refactoring skill of the programmers in the group, so I wouldn’t know whom to trust to refactor without tests. Moreover, I probably can’t calculate the risk associated with refactoring without tests, so I wouldn’t know when to trust _anyone_ to refactor without tests, even if I feel confident in their skill. Once I have thought about these things, it becomes easier to formulate a strategy, because I can ask myself what would make _me_ feel better in this situation? I encourage you to ask yourself this question and write down a few ways that you believe you could increase your confidence from the point of view of the project planner. I can provide a few general ideas here.

I encourage you to build trust by telling the project planner that you are aware of the risks, that you care about protecting the profit stream of the code base, and that you are prepared to discuss the details with them. It often helps a lot simply to show them that you and they are working together to solve this problem and not that you are doing what helps you while creating problems for them.

I would ask the project planners what specifically they are worried about, then matching my strategies to their worries. For example, microcommitting provides one way to manage the risk of refactoring without tests, because it reduces the cost of recovering from a mistake. At the same time, if the project planner worries about different risks than the ones I have thought about, then my strategies might not make them feel any more secure! If I know more about which risks affect them more or concern them more, then I can focus my risk-management work on those points, which also helps to build trust.

I would emphasize that we do not intend to do this as a primary strategy forever. We don’t feel comfortable doing it, either! Even so, we _must_ make progress _somehow_. We refactor without tests because it would be even more expensive to add „enough“ tests than to recover from our mistakes. Of course, we have to be willing to explain our judgment here and we have to be prepared that we are wrong in that judgment! I am always prepared to take suggestions from anyone who has better ideas, but outside of that, they hired me to do good work and make sound decisions, so if they don’t trust me, then I must try to earn their trust or they should give my job to someone that they trust more. I don’t mean this last part as a threat, but merely as a reminder that if they hire me to do the job, but they never trust me, then they _should_ hire someone else!

How about pair-refactoring?

I love it! Refactoring legacy code is often difficult and tiring work, so pair-refactoring fits well even in places where „ordinary“ pair programing might not be needed. Refactoring legacy code often alternates periods of difficulty understanding what to do next with long periods of tedious work. Working in pairs significantly increases the profit from both of those kinds of tasks.

You also need this refactoring-without-tests skill, to effectively refactor your tests!

Maybe! I don’t say you _need_ it, but it would probably help you. Your production code helps you to refactor your tests: if you change your tests and they now expect the wrong behavior, then your production code will fail that test for „the right reasons“. It doesn’t provide perfect coverage, but it helps more than you might expect. In that way, the production code helps to test the tests.

Moreover, tests tend to have simpler design than the production code. This means that we might never need to refactor tests in certain ways that feel common when we refactor production code. I almost always write tests with a cyclomatic complexity of 1 (no branching), so the risk when refactoring tests tends to be much lower than when refactoring legacy code. This makes refactoring tests generally safer.


➡️ Also read our two Q&A Blogposts with J.B. Rainsberger Part #1 The Risks Related to Refactoring Without Tests“ and Part #3 „Questions About Test Frameworks„! Follow us on Twitter or LinkedIn to get new posts.


Managing the Uncertainty of Legacy Code: Q&A Part #1 with J.B. Rainsberger

In this first chapter of our three-part Q&A blog series he adressed questions that came up during his session.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.

Our next remote course Surviving Legacy Code from 12 – 15 April 2021.

J. B. Rainsberger helps software companies better satisfy their customers and the business that they support.

Here are some questions that came up during this session and some answers to those questions.

One of the issues is that the legacy code base consists of useful code and dead code and it’s hard to know which is which.

Indeed so. Working with legacy code tends to increase the likelihood of wasting time working with dead code before we feel confident to delete it. I don’t know how to avoid this risk, so I combine monitoring, testing, and microcommitting to mitigate the risk.

Microcommits make it easier to remove code safely because we can recover it more safely. Committing frequently helps, but also committing surgically (the smallest portion of code that we know is dead) and cohesively (portions of code that seem logically related to each other) helps. If our commits are more independent, then it’s easier to move them backward and forward in time, which makes it easier to recover some code that we mistakenly deleted earlier while disturbing the live code less. We will probably never do this perfectly, but smaller and more-cohesive commits make it more likely to succeed. This seems like a special case of the general principle that as I trust my ability to recover from mistakes more, I feel less worried about making mistakes, so I change things more aggressively. When I learned test-driven development in the early years of my career, I noticed that I become much more confident to change things, because I could change them back more safely. Practising test-driven development in general and microcommitting when working with legacy code combine to help the programmer feel more confident to delete code—not only code that seems dead.

Even with all this, you might still feel afraid to delete that code. In that case, you could add “Someone executed this code” logging statements, then monitor the system for those logging statements. You could track the length of time since you last saw each of these “heartbeat” logging messages, then make a guess when it becomes safe to delete that code. You might decide that if nothing has executed that code in 6 months, then you judge it as dead and plan to remove it. This could never give us perfect confidence, but at least it goes beyond guessing to gathering some amount of evidence to support our guesses

More testing, especially microtesting, puts more positive pressure on the design to become simpler: less duplication, better names, healthier dependencies, more referential transparency. I have noticed a pattern: as I simplify the design, I find it easier to notice parts that look irrelevant and I find it clearer that those parts are indeed dead code. Moreover, sometimes obviously dead code simply appears before my eyes without trying! This makes it safer to delete that code, using the microcommitting and monitoring as a recovery strategy in case I get it wrong.

So not all legacy code adds value to the business… but it is hard to know which part does.

Indeed so. We have to spend time, energy, and money to figure this out. I accept responsibility as a programmer to give the business more options to decide when to keep the more-profitable parts running and to retire the less-profitable parts. As I improve the design of the system, I create more options by making it less expensive to separate and isolate parts of the system from each other, which reduces the cost of replacing or removing various parts. Remember: we refactor in order to reduce volatility in the marginal cost of features, but more-generally in the marginal cost of any changes, which might include strangling a troublesome subsystem or a less-profitable feature area.

The Strangler approach describes incrementally replacing something in place: adding the new thing alongside the old thing, then gradually sending traffic to the new thing until the old thing becomes dead. Refactoring the system to improve the health of the dependencies makes this strangling strategy more effective, which gives the business more options to replace parts of the legacy system as they determine that a replacement would likely generate more profit. As we improve the dependencies within the system, we give the business more options by reducing the size of the smallest part that we’d need to replace. If we make every part of the system easier to replace, then we increase the chances of investing less to replace less-profitable code with more-profitable code.

This illustrates a general principle of risk management: if we don’t know how to reduce the probability of failure, then we try reducing the cost of failure. If we can’t clearly see which parts of the legacy code generate more profit and which ones generate less, then we could instead work to reduce the cost of replacing anything, so that we waste less money trying to replace things. This uses the strategy outlined in Black Swan of accepting small losses more often in order to create the possibility of unplanned large wins.

What do you think about exploratory refactoring? Do you use this technique sometimes?

Yes, I absolutely do! I believe that programmers can benefit from both exploratory refactoring and feature-oriented refactoring, but they need to remain aware of which they are doing at any time, because they might need to work differently with each strategy to achieve those benefits.

When I’m refactoring in order to add a feature or change a specific part of the code, I remind myself to focus on that part of the code and to treat any other issues I find as distractions. I write down other design problems or testing tasks in my Inbox as I work. I relentlessly resist the urge to do those things “while I’m in this part of the code”. I don’t even follow the Two-Minute Rule here: I insist on refactoring only the code that right now stands between me and finishing the task. Once I have added my feature, I release the changes, then spend perhaps 30 minutes cleaning up before moving on, which might include finishing a few of those Two-Minute tasks.

The rest of the time, I’m exploring. I’m removing duplication, improving names, trying to add microtests, and hoping that those activities lead somewhere helpful. This reminds me of the part of The Goal, when the manufacturing floor workers engineered a sale by creating an efficiency that nobody in the sales department had previously thought possible. When I do this, I take great care to timebox the activity. I use timers to monitor how much time I’m investing and I stop when my time runs out. I take frequent breaks—I use programming episodes of about 40 minutes—in order to give my mind a chance to rise out of the details and notice higher-level patterns. I don’t worry about making progress, because I donI ’t yet know what progress would look like—instead I know it when I see it. By putting all these safeguards in place, I feel confident in letting myself focus deeply on exploring by refactoring. I avoid distracting feelings of guilt or pressure while I do this work. I also feel comfortable throwing it all away in case it leads nowhere good or somewhere bad. This combination of enabling focus and limiting investment leads me over time to increasingly better results. As I learn more about the code, exploratory refactoring turns into feature-oriented refactoring, which provides more slack for more exploratory refactoring, creating a virtuous cycle.

What is your experience with Approval Tests, in cases where writing conventional unit tests might be to expensive?

I like the Golden Master technique (and particularly using the Approval Tests library), especially when text is already a convenient format for describing the output of the system. I use it freely and teach it as part of my Surviving Legacy Code course. It provides a way to create tests from whatever text output the system might already produce.

I get nervous when programmers start going out of their way to add a text-based interfaces to code that doesn’t otherwise need it only for the purpose of writing Golden Master tests. In this case, checking objects in memory with equals() tends to work well enough and costs less. I notice it often that programmers discover a helpful technique, then try to use it everywhere, then run into difficulties, then invest more in overcoming those difficulties than they would invest in merely doing things another way. Golden Master/Approval Tests represents merely another situation in which this risk comes to the surface.

I get nervous when programmers start choosing to write integrated tests for code where microtests would work equally well. When programmers think about adding Golden Master tests, they tend to think of these as end-to-end tests, because they often judge that as the wisest place to start. Just as in the previous paragraph, they sometimes fall into the trap of believing that “since it has helped so far, we must always do it this way”. No law prevents you from writing unit tests using Golden Master/Approval Tests! Indeed, some of the participants of my Surviving Legacy Code training independently discover this idea and use it to great effect. Imagine a single function that tangles together complicated calculations and JSON integration: it might help a lot to use Approval Tests to write Golden Master tests for this function while you slowly isolate the calculations from the JSON parsing and formatting. The Golden Master tests work very well with multiline text, such as values expressed in JSON format, but probably make the calculation tests awkward, compared with merely checking numeric values in memory using assertEquals().

When programmers use Golden Master/Approval Tests, they need to treat it as just one tool in their toolbox. This is the same as with any technique! I tend to treat Golden Master as a temporary and complementary technique. I use it when I focus on writing tests as a testing technique, even though I tend to prefer to write tests for design feedback. Not everyone does this! If you find yourself in the stage where you’re drowning in defects and need to focus on fixing them, then Golden Master can be a great tool to get many tests running early. Once you’ve stopped drowning, it becomes easier to look at replacing Golden Master with simpler and more-powerful unit tests—eventually microtests.


➡️ Also read our two Q&A Blogposts with J.B. Rainsberger Part #2 The Risks Related to Refactoring Without Tests“ and Part #3 „Questions About Test Frameworks„! Follow us on Twitter or LinkedIn to get new posts.


Approval Testing: What It Is and How It Helps You To Manage Legacy Code

Emily Bache is a Technical Agile Coach, she helps software development teams to get better at the technical practices needed to be agile, including Test-Driven Development, Refactoring, and Incremental Design. Emily is known as the author of the book, “The Coding Dojo Handbook”. For the second time, we organize a training course with Emily on Approval Testing. In this email interview we asked Emily what counts as legacy code, how to get into approval testing, and what her upcoming book will be about.

What is the optimal way of learning Approval Testing? What is the role of Gilded Rose Kata and other exercises in this process? 

Approval Testing is a style and approach to writing automated tests that changes the way you verify behaviour. Basically, the ‘assert’ part of the test. As with any new tool or approach, it helps to have actual code examples to play with when you’re learning it. Once you start to see it in action then you’re bound to have lots of questions so it’s good to have people around you to discuss it with.

The Gilded Rose Kata is a fun little exercise that I maintain. It actually comes with approval tests, as well as being translated into about 40 programming languages. Whatever your coding background and language preferences, you can try it out and see how it works for yourself. When you’ve done that, you should easily be able to find other people to discuss it with, since it’s quite a popular exercise. For example Ron Jeffries recently wrote 13(!) blog posts about his experience with it.

You talk about refactoring and handling legacy code? What is actually legacy code? How would you define it? 

Many developers struggle with code they inherited which has poor design and lacks automated tests. On their own, any one of those difficulties could probably be overcome, but in combination developers get a kind of paralyzing fear of changing the code. That’s how I would define legacy code. Code that you need to change but you’re afraid to in case you break it.

The antidote to that fear, I find, is feedback. High-quality feedback telling the developer when they are making safe changes. The feedback that gives them the confidence to improve the design and get in control. Approval testing is one way to get that feedback – you create regression tests that give you good information when behaviour changes.

What are the main things one should know before starting working with Approval Testing? 

Since it’s a style of automated testing, it helps to have experience with unit testing already, perhaps with JUnit or similar. Approval Testing is often used in larger-granularity tests too, so experience with tools like Selenium or Cucumber would give you a good perspective, although it works a bit differently. This way of testing also fits extremely well into Agile methods, BDD, and Specification by Example. If you are working in a more traditional process, you may find adding these kinds of tests will help you to increase your agility.

For which situations is Approval Testing the best solution? When shouldn’t it be used? 

If you’re facing legacy code, this can be a great addition to your strategy for getting control. I wouldn’t discount it for new development though, particularly if your system will produce some kind of detailed artifact where the user really cares about how it looks. For example I’ve seen this approach used to verify things like invoices, airline crew schedules, 3D molecular visualizations, and hospital blood test results.

Of course there are situations where I wouldn’t use Approval Testing, for example where the output is a single number – the result of a complex calculation. If you can calculate the expected result before you write the code, testing it with an ordinary assertion is a sensible approach.

Can Behaviour Driven Development be considered as the future of the industry and Approval Testing as an essential part of it? Why is it so?  

The main priority of BDD is to improve collaboration and communication so we build the right software. In my experience Approval testing promotes good conversations. I’m giving a keynote speech at Cukenfest soon, (a conference about BDD), and I’m going to be talking about exactly this topic. For the test automation part of BDD most teams use the Gherkin syntax with Cucumber or SpecFlow. I think you can use Approval testing in a similar way.

You have been working on this topic for a while  – what excites you about it? 

There is so much potential for this technique! I see a lot of legacy code out there, and I see a lot of test cases that are unnecessarily difficult to maintain. If I can spread these testing techniques to even a small proportion of all those places it will make a huge positive difference to the quality of the software in the world.

You wrote a book about Coding Dojo, what can we expect from your follow-up book? 

The motivation for my upcoming book “Technical Agile Coaching” is largely the same as for the previous one – I write for people who want to make a difference and improve the way software is built. In 2011 I published „The Coding Dojo Handbook“ which is full of advice and experiences setting up a forum for practicing coding skills. You can see my new book as an expansion of those ideas, seasoned with ten years of additional experience.

The focus of the coaching method I describe in the book is specifically on technical practices and how people write code. There are two main elements to the coaching. Firstly teaching techniques via interactive exercises and code katas. Secondly coaching a whole team to work effectively together as they do mob programming.


Das .NET Framework ist tot, lang lebe .NET!

Auf der diesjährigen Microsoft Entwickler- Konferenz Build, wurde neben der aktuellen .NET Core Version 3 bereits die nächste Version mit dem neuen Namen .NET 5 angekündigt. Um eines gleich zu Anfang klarzustellen, .NET 5 ist nicht der direkte Nachfolger vom .NET Framework 4.8 sondern der direkte Nachfolger von .NET Core 3. Scott Hunter (Director Program Manager für .NET) hat dies ebenfalls in einem Blogpost bestätigt.

Was ist noch einmal .NET Core?

.NET Core ist eine neue Implementierung des .NET Frameworks, welche in Version 1.0 im November 2014 erschienen ist. Mit den Erfahrungen der letzten 12 Jahre am .NET Framework, wurden viele Teile neu implementiert und verbessert. Mit einer modulareren Architektur ist es erstmalig möglich mehrere .NET Core Versionen systemweit nebeneinander betreiben zu können. Dadurch kann eine neuere Version von .NET Core installiert werden, ohne bestehende Anwendungen im Betrieb zu beinflussen. Alternativ zur systemweiten Installation ist es jetzt auch möglich, die .NET Core Runtime mit einer Anwendung selbst mit auszuliefern ohne sie systemweit installieren zu müssen.

Die Release der aktuellen Version .NET Core 3 erfolgte übrigens am 23. September 2019 während der .NET Conf 2019 und für November 2019 ist bereits die Release für .NET Core 3.1 geplant. Diese wird vor allem eine Bugfix- Release werden, welche dann auch als LTS-Version (Long Term Support) gekennzeichnet wird. Long Term Support bedeutet, dass Microsoft für 3 Jahre lang nach der ursprünglichen Release kritische und kompatible Fehlerbehebungen zur Verfügung stellt. Nicht-LTS-Versionen, welche als Current bezeichnet werden, werden bis zu 3 Monate nach dem Release der nächsten Version offiziell unterstützt.

Ein weiterer großer Unterschied zum .NET Framework ist, dass .NET Core komplett als Open Source Software entwickelt wird und es nicht nur auf Windows, sondern auch auf Linux und Mac OS läuft.

Was ist neu an .NET 5 außer die Versionsnummer?

.NET 5 ist die nächste Evolutionsstufe von .NET Core und vereint alle bisher unterstützten Platformen unter einem .NET. Ob Windows, Linux, Mac OS, iOS, Android, tvOS, watchOS oder WebAssembly, alle laufen unter der gleichen Runtime und Framework.

Zusätzlich kommen Features von anderen Implementierungen (z.B. Xamarin) in .NET. Das wären unter anderem Java, Objective-C und Swift-Interoperabilität und statisches Kompilieren (AOT, Ahead Of Time).

Wann kommt .NET 5 und was kommt danach?

Microsoft plant .NET 5 im November 2020 zu veröffentlichen. Um es für uns EntwicklerInnen leichter zu machen, hat sich Microsoft dazu entschieden ein Release pro Jahr zu veröffentlichen. Ab November 2020 erscheint jedes Jahr im November eine neue Version von .NET.

Jedes zweite Jahr erfolgt die Veröffentlichung einer LTS (Long Term Support) Version, für welche Microsoft länger Support garantiert. Wie lange ist noch nicht klar, ich vermute dass es bei den jetzigen 3 Jahren bleibt. Man hat also von LTS zu LTS Versions-Upgrade ein Jahr Zeit dieses durchzuführen.

Mehr Details zu .NET 5 inkl. Schedule findet man im Blogpost von Richard Lander (Program Manager .NET Team).

Was verwende ich jetzt für meine neuen Anwendungen?

Die kurze Antwort ist: .NET Core.

Die etwas längere Antwort ist: es hängt davon ab, aber wahrscheinlich .NET Core in der Version 3.

Microsoft selbst hat einen kurzen Leitfaden erstellt, wann .NET Core oder .NET Framework verwenden werden soll. Nach diesem Leitfaden soll .NET Framework nur dann verwendet werden, wenn Abhängigkeiten auf Technologien oder Bibliotheken bestehen, welche heute noch nicht oder nicht mehr in .NET Core unterstützt werden.

Was mach ich jetzt mit meinen bestehenden .NET Framework Anwendungen?

Kurzfristig ändert sich für .NET Framework nichts. Als Teil des Betriebssystems wird Microsoft weiterhin Sicherheitspatches für .NET Framework bereitstellen. Detailierte Information finden sich in der offiziellen Lifecycle FAQ. Innovationen finden heute bereits ausschließlich unter .NET Core statt.

Mittel- bis langfristig sollte man sich überlegen, ob es sich lohnt bestehende Anwendung auf .NET Core zu portieren.

Mit dem .NET Portability Anlazer stellt uns Microsoft ein Werkzeug bereit, mit dem Entwickler bestehende Bibliotheken und Software auf Kompatibilität mit .NET Core analysieren können.

Mit der aktuellen Version von .NET Core ist es erstmals möglich auch bestehende WPF und Winforms Desktop Anwendungen nach .NET Core zu portieren und zukünftig mit .NET 5 weiterzuentwickeln.

Fazit

Mit dem Ausblick auf .NET 5 im November 2020 ist jetzt der richtige Zeitpunkt sich Gedanken über eine Portierung von bestehenden .NET Framework Applikationen zu machen.

Gerne unterstützen wir Sie hands-on bei der Planung und Analyse Ihres konkreten Vorhabens.


Wenn Sie Unterstützung bei der Architektur Ihrer nächsten .NET Anwendung brauchen, können Sie sich gerne direkt an mich wenden. Gerne beantworte ich Ihre Fragen. Kontakt: daniel.sack@techtalk.at

The Global Day of Coderetreat 2019 am 16. November

Es ist wieder mal soweit, ein weiteres Jahr ist vorüber und der nächste „Global Day of Coderetreat“ (GDCR) steht vor der Tür.

Was ist aber nun der Global Day of Coderetreat und warum sollte mich das interessieren?

Die Website coderetreat.org sagt dazu:

„A Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice away from the pressures of ‘getting things done’, the coderetreat format has proven itself to be a highly effective means of skill improvement.“

Am Global Day of Coderetreat treffen sich also auf der ganzen Welt Gruppen von Software-EntwicklerInnen um unter fachkundiger Anleitung mehrmals an einer Aufgabe zu arbeiten. Im Gegensatz zum realen Projektleben geht es aber nicht darum fertig zu werden, sondern sich in einem Pair der Aufgabe immer wieder von einer neuen Seite zu nähern. In gemeinsamen Retrospektiven wird über die vergangene Session reflektiert. Auf diese Weise sammeln die Teilnehmerinnen im Laufe des Tages viele Erfahrungen und Erkenntnisse, die sie auch im zurück im Projektalltag gewinnbringend einsetzen können.

Im Zuge vom Global Day of Coderetreat 2016 haben wir die Gelegenheit genutzt ein paar Eindrücke und Impressionen einzufangen. Diese kannst du dir im folgenden Video ansehen:

TechTalk Stories – Coderetreat 2016

Als Facilitator dürfen wir heuer Sandra Parsick (@SandraParsick) und Peter „CodeCop“ Kofler (@codecopkofler) begrüßen.

TechTalk ist heuer bereits zum vierten Mal in Folge Gastgeber und Sponsor des GDCR in Wien, diesmal in den Räumlichkeiten Donau City Spaces by TechTalk. Die Hosts vor Ort sind die TechTalk-Kollegen Paul Rohorzka (@paulroho), Daniel Sack (@DanielTheCoder) und Raoul Holzer (@RaoulHolzer). Für Fragen (z.B. „Ist das eine Veranstaltung für mich?“) können sie jederzeit kontaktiert werden.

Details zur Anmeldung zum Global Day of Coderetreat 2019.

Du schaffst es nicht zum Global Day of Coderetreat? Gar kein Problem! Wir als TechTalk sind auf vielen Community Events und Trainings anzutreffen, einige davon findest du unter Meet TechTalk.

Hinweis:

Da der GDCR heute zum zehnten Mal stattfindet, gibt es in Wien auch am Tag davor die Möglichkeit an einer anderen Ausgabe des GDCR 2019 teilzunehmen. Die beiden Veranstaltungen werden unabhängig voneinander organisiert.

Wir wünschen dir viel Spaß beim Global Day of Coderetreat oder einen der nächsten Community Events!