Wenn Sie schnell liefern möchten, haben Ihre Tests das letzte Wort

Nachricht

HeimHeim / Nachricht / Wenn Sie schnell liefern möchten, haben Ihre Tests das letzte Wort

Jul 11, 2023

Wenn Sie schnell liefern möchten, haben Ihre Tests das letzte Wort

InfoQ-Homepage-Artikel, wenn Sie möchten

InfoQ-Homepage-Artikel Wenn Sie schnell liefern möchten, haben Ihre Tests das letzte Wort

06. Juni 2023 23 Minuten Lesezeit

von

Jorge Fernandez Rodriguez

rezensiert von

Matt Campbell

Ich denke, Sie werden zustimmen, dass Software-Engineering im Vergleich zu anderen Berufen etwas Besonderes ist. Die Dinge ändern sich drastisch und schnell. Es erfordert viel Gehirnleistung, um auf dem Laufenden zu bleiben.

Vielleicht halten wir deshalb an einigen etablierten allgemeinen Praktiken oder Ideen fest (auch wenn sie uns Probleme bereiten oder in manchen Fällen nicht passen). Diese Praktiken versuchen, die meisten Fälle abzudecken, können jedoch nicht alle Fälle abdecken. Diese Praktiken spenden uns jedoch Trost. Wir brauchen etwas, das sich nicht ändert, das sich sicher anfühlt und das unseren Geist von der Last befreit, darüber nachzudenken, ob es tatsächlich passt oder nicht. Wir wechseln in den Autopilot-Modus.

Das Problem dabei ist, dass wir wollen, dass sich die Softwareentwicklung wie ein Fließband verhält: Sobald das Fließband gebaut ist, berühren wir es nie mehr. Wir agieren immer auf die gleiche Art und Weise. Das mag mit unseren CI/CD-Spuren eine Zeit lang funktionieren, aber leider funktioniert es nicht immer gut mit unserem Code.

Migrieren Sie ganz einfach in die Cloud und entwickeln Sie unglaublich schnell Innovationen mit Kalix! Erstellen Sie leistungsstarke Microservices und APIs, NoOps erforderlich. Erfahren Sie mehr.

Es wird sogar noch schlimmer, weil die Botschaft manchmal so oft übermittelt wird, dass sie ihre Essenz verliert und wir diese Praxis irgendwann als Teil unserer Identität betrachten, sie verteidigen und keine unterschiedlichen Standpunkte zulassen. Vor allem wenn sie offenbar mehr Aufwand erfordern. In anderen Fällen wollen wir einfach dazupassen und keine neuen Ideen vorschlagen.

Wenn wir programmieren, müssen wir dagegen ankämpfen und in jedem Fall darüber nachdenken, ob die Praxis zum aktuellen Szenario passt. Stellen Sie sich „Best Practices“ als „beste generische Praktiken“ vor.

Ein Beispiel dafür sind die vielen Möglichkeiten, auf die Agilität fehlinterpretiert werden kann. In einigen Fällen ist das Wesentliche verloren gegangen.

In diesem Artikel argumentiere ich, dass die Essenz von Agilität oft verloren geht, weil sich die Implementierung von Agilität oft auf die falschen Dinge konzentriert. Per Definition kann etwas Agiles leicht die Richtung ändern und schnell auf Veränderungen reagieren.

Wir versuchen, diese Reaktionsfähigkeit mit Praktiken unterschiedlicher Art zu erreichen: technischer Art wie CI/CD (Continuous Integration/Continuous Deployment) und strategischer Art wie die Entwicklung in Iterationen. Allerdings vergessen wir oft die Agilität, wenn wir uns mit dem Kern der Softwareentwicklung befassen: dem Codieren. Stellen Sie sich vor, Sie bereiten Ihr Lieblingsgericht oder Dessert ohne die Hauptzutat des Rezepts zu. Das ist es, was wir tun, wenn wir nach Agilität streben, ohne den Code zu berücksichtigen.

Das kann passieren, weil die Verbesserung des Codes beängstigend und kompliziert klingt oder weil man leicht in Kaninchenlöcher gerät (all dies kann man leichter beseitigen). Vielleicht liegt es einfach daran, dass die negativen Auswirkungen einiger Lösungen auf unsere Manövrierfähigkeit nicht leicht zu erkennen sind. zukünftige Entwicklungen in einen Albtraum verwandeln: das Gegenteil von Agilität. Anstatt sich auf den Code zu konzentrieren, wird zu viel Wert darauf gelegt, die Perfektion unserer Prozesse (von Methoden wie Scrum) zu erreichen, die weniger wichtig sind und versuchen, das Problem zu lösen, ohne das Hauptproblem anzugehen.

Abschließend schlage ich vor, dass wir die Auswirkungen des Kodex auf zukünftige Entwicklungen (und infolgedessen auf die Zukunft des Unternehmens) besser sichtbar machen müssen. Hoffentlich kann uns die KI dabei helfen, dies mit so etwas wie einem Koeffizienten zu quantifizieren, der uns nicht nur die Qualität verrät, sondern auch vorhersagt, wie viel langsamer die Entwicklung aufgrund unserer potenziellen Entscheidungen sein wird. Ich denke, so etwas könnte Unternehmen dabei helfen, zu erkennen, dass sie in eine nachhaltige Entwicklung investieren müssen. Die Diskussionen darüber, wann technische Schulden angegangen werden sollten, würden der Vergangenheit angehören.

In diesem Artikel werde ich mich auf eine Codierungspraxis konzentrieren, die oft nicht ausreichend hinterfragt wird und eine entscheidende Rolle für die Agilität spielt: die herkömmliche Art des Testens.

Ich werde auch „Immunität gegen Veränderungen“ vorstellen, eine Strategie, die ich kürzlich entdeckt habe und die Ihnen helfen kann, Ziele zu erreichen und viele Gewohnheiten zu ändern; nicht nur Codierungsgewohnheiten, sondern auch andere Gewohnheiten in Ihrem Leben. Darüber hinaus veranschaulicht es einen der Punkte, die ich in meinem vorherigen Artikel erwähnt habe: Wir wollen Manövrierfähigkeit erreichen, indem wir einige Praktiken/Gewohnheiten ändern, aber wir sabotieren uns unbewusst selbst, weil wir nicht wissen, welche Rolle die Codierung bei der Erreichung dieses Ziels spielt.

Wir sind uns hoffentlich einig, dass (gute) automatisierte Tests uns einen großen Vorteil bringen: Wir können Code ändern und schnell überprüfen, dass keine bestehende Funktionalität kaputt geht. Tests sind unser Sicherheitsnetz.

Allerdings sind sie nicht billig, sodass die Kosten kompensiert werden müssen, was erst nach einiger Zeit geschieht. Je öfter es ausgeführt wird, desto mehr Nutzen ziehen wir daraus. Wenn wir den Test jedoch ändern, wird der „Nutzenzähler“ für den Test auf Null zurückgesetzt.

Neben der Kompensation der Kosten müssen wir noch etwas anderes bedenken: Wenn wir einen Test erstellen, tun wir unser Bestes, um die Korrektheit des Tests zu gewährleisten, können uns aber nicht hundertprozentig sicher sein. Wenn wir sicher sein könnten, dass jeder Code, den wir schreiben, korrekt ist, bräuchten wir gar keine Tests, oder?

Tests geben uns erst im Laufe der Zeit Vertrauen. Bedenken Sie Folgendes: Stellen Sie sich vor, jedes Mal, wenn ein Test ausgeführt wird, gibt uns das einen Vertrauenspunkt. Wenn es 1000 Mal ausgeführt wird, gewinnen wir 1000 Vertrauenspunkte.

Wenn wir irgendwann einen Fehler im Test entdecken, verlieren wir die 1000 Vertrauenspunkte. Wir dachten, es würde uns schützen, aber das war nicht der Fall.

In ähnlicher Weise können wir nicht mehr sicher sein, dass entweder die Geschäftslogik oder der Test korrekt sind, wenn wir die durch den Test und die Testunterbrechungen verifizierte Logik umgestalten müssen. Wir verlieren auch die „Vertrauenspunkte“, die wir gesammelt haben. Es ist, als würden wir ein neues Sicherheitsnetz aufbauen.

Es ist eine Investition in die Zukunft. Menschen und Unternehmen denken selten an langfristige Investitionen, aber zum Glück werden die Vorteile automatisierter Tests weithin akzeptiert (obwohl ich von Zeit zu Zeit Geschichten von jemandem höre, der automatisierte Tests immer noch nicht akzeptiert).

Andere langfristige Investitionen wie die Aufrechterhaltung der Flexibilität des Codes durch Refactorings sind leider nicht so weit verbreitet. Hoffentlich helfen die in diesem Artikel erwähnten, überhaupt nicht innovativen Ideen dabei, Hindernisse zu beseitigen.

Jedes Mal, wenn ich neue Funktionen hinzufüge, bin ich dankbar für die Tests, die geschrieben wurden, insbesondere bei großen Diensten mit vielen Funktionen. Ich kann mir nicht vorstellen, jeden einzelnen von ihnen manuell überprüfen zu müssen. Es wäre Unsinn, wenn man bedenkt, wie viel langsamer ich wäre.

Sie können jedoch auch Nachteile mit sich bringen, wenn wir nicht die richtige Strategie für unseren Fall verfolgen. Eine ungeeignete Teststrategie kann die Bereitstellung verlangsamen und die Zufriedenheit und Erfahrung der Entwickler beeinträchtigen.

Finden wir sie zusammen mit den folgenden Fragen heraus:

Überprüfen alle Ihre Unit-Tests Klassen oder Methoden isoliert?

Wenn die Antwort „Ja“ lautet und Sie sich stark über Abhängigkeiten lustig machen, sind Sie es möglicherweise leid, einen Mock nach dem anderen vorzubereiten, um in manchen Fällen herauszufinden, dass der Mock nicht real genug war und die Logik tatsächlich nicht so funktioniert, wie sie sollte. Hoffentlich finden Sie das heraus, bevor Sie mit der Produktion beginnen, und müssen nicht viele Änderungen vornehmen.

Haben Sie manchmal den Eindruck, dass Tests die Möglichkeiten, den Code zu ändern, einschränken?

Ich würde vermuten, dass das auch ein Ja ist. Manchmal passt der vorhandene Code nicht mehr für die neue Funktionalität oder wird zu kompliziert. Sie beschließen, es umzugestalten. Es dauert 10 oder 15 Minuten, da es sich um eine kleine Änderung handelt und BOOOOM, viele Tests lassen sich nicht mehr kompilieren oder schlagen fehl. Das Anpassen und Durchführen der Tests nimmt unverhältnismäßig viel Zeit in Anspruch, viel länger als das Anpassen des Codes. Für einen 10- bis 15-minütigen Wechsel würden Sie am Ende Tage aufwenden. WARUM???!!!! Das Verhalten hat sich nicht geändert.

Wenn die Funktion nicht geändert wird, sollten Tests im Idealfall nicht abstürzen. Können Sie bei einer Anpassung der Tests wieder auf das Sicherheitsnetz aufspringen? Und denken Sie daran, dass der „Nutzenzähler“ und der „Konfidenzzähler“ für die Tests zurückgesetzt werden, wenn Sie sie ändern.

Wir werden später sehen, dass wir diese Situation in vielen Fällen vermeiden und das Hinzufügen von Hacks vermeiden können. Weil Hacks uns zumindest anfangs die Illusion vermitteln, dass wir schnell liefern. Aber das ist eine kurze Zeitinvestition und wird uns zurückschlagen: Der Code wird starr und nach einigen Monaten werden wir viel mehr Zeit damit verbringen, den Code zu verstehen und zu ändern. Selbst nach einigen Tagen werden wir uns nicht mehr daran erinnern, was der Code bewirkt. Und das wird immer schlimmer, ganz zu schweigen von den armen Neueinstellungen, die noch weniger Kontext haben. Wenn Ihre Codebasis jedoch mit Hacks übersät ist, müssen Sie sich nicht allzu lange um sie kümmern, da sie wahrscheinlich nicht lange bestehen bleiben.

Verfügt Ihre Testsuite über viele Integrations- und E2E-Tests (End-to-End)?

Integrationstests überstehen tendenziell mehr Änderungen als Unit-Tests, sind aber viel langsamer.

Wenn Sie viele E2E-Tests entwickelt haben, haben Sie wahrscheinlich eine schmerzhafte Erfahrung gemacht:

Der Schmerz wird noch schlimmer, wenn die e2e-Tests viele Komponenten umfassen, die über das Netzwerk verbunden sind (aber bauen Sie bitte keinen großen Schlammball, um dies zu vermeiden).

Eine schlechte Teststrategie allein kann also Ihre Lieferung ruinieren. Unit-Tests können „uns davon abhalten“, besseren Code zu schreiben. Es spielt keine Rolle, ob Ihre „agilen“ Rituale auf den Punkt kommen. Sie haben das Gefühl, eine Zwangsjacke zu tragen (oder mehr als eine, wenn wir paranoid werden und immer mehr Tests hinzufügen, um 200 % sicher zu sein). In der Zwischenzeit rücken die scharfen Zähne der Konkurrenten, die sich schneller an Veränderungen im Marktmeer anpassen können, näher an uns heran, und die Zwangsjacke lässt Sie nicht einmal von der Stelle. Gegen diese Zähne helfen sie auch nicht.

Daher möchte ich, dass Sie sich nach der Lektüre einige wichtige Fragen stellen:

Schauen wir uns eine Vereinfachung eines Szenarios an, das ich oft sehe. Eine mit Spring implementierte Backend-App. Normalerweise sehe ich eine 1:1-Zuordnung zwischen Produktions- und Testklassen, wie im Bild:

[Klicken Sie auf das Bild, um es in voller Größe anzuzeigen]

Die „Klasse mit der Hauptlogik“ wird oft als „Dienst“ bezeichnet. Manchmal ist der Dienst spezifisch für jede Domänenentität, manchmal stellt der Dienst ein abstrakteres Konzept dar.

Manchmal erstreckt sich die „Hauptlogik“ auch auf Framework-Komponenten wie Controller oder Listener. Nicht nur die Grenze zwischen dem Framework und der Geschäftslogik verschwimmt, sondern auch die Grenze, die unterscheidet, was in Unit-Tests oder Integrationstests besser getestet werden kann. Daher sehe ich manchmal ähnliche Szenarien bei Unit-Tests und Integrationstests. Das ist nutzlos und kostspielig.

Ein Unit-Test pro Klasse ist sinnvoll, wenn die Klassen komplexe Funktionen enthalten. Wenn das passiert, ist es schwierig, Fehler zu identifizieren. Kleine Codeteile helfen daher, Probleme schneller zu lokalisieren. Dies ist tatsächlich eines der Argumente, die Unit-Tests unterstützen. Denken Sie daran, dass ich von „komplexer Funktionalität“ und nicht von „komplexer Logik“ spreche, da es immer möglich ist, einfache Funktionalität auf komplexe Weise zu implementieren.

Stellen Sie sich nun vor, Sie müssten eine Funktion hinzufügen oder die Logik ändern, weil sich die Anforderungen geändert haben. Das passiert selten, oder? ;). Die aktuelle Implementierung passt nicht zur neuen Idee oder zum neuen Kontext. Wie fast immer gibt es zwei Möglichkeiten: Dirty Hack oder Refactoring. Wir entscheiden uns natürlich immer für Refactoring:

[Klicken Sie auf das Bild, um es in voller Größe anzuzeigen]

Stellen Sie sich vor, die Aufteilung wäre sauber (verschieben Sie einfach einige Methoden in die neue Klasse) und die alte Klasse behält einen Verweis auf die neue Klasse. Ist es sinnvoll, die Testklasse aufzuteilen, um die 1:1-Zuordnung beizubehalten? Was gewinnen wir? Wir könnten den Test einfach so belassen, wie er ist (es sind nur geringfügige Änderungen erforderlich).

Für den Fall, dass die Umgestaltung komplexer war, stellen Sie sich vor, dass die Logik (Implementierungsdetails) in 20 Minuten angepasst wurde. Wie bereits erwähnt, ändern sich Tests nicht so schnell.

Bezüglich der Tests sehen wir zwei Dinge:

Wir sehen, dass jeder Typ einige Vorteile hat. Vielleicht können wir also das Beste aus Integration und herkömmlichen Unit-Tests kombinieren. Traditionell ist eine Einheit eine Klasse oder eine Methode. Zumindest habe ich es vor langer Zeit so gelernt. Es mag den Anschein haben, dass die Idee, eine Klasse nicht isoliert zu testen, falsch ist. Aber vielleicht könnte das Konzept der „Einheit“ von einer eigenen „Umgestaltung“ profitieren.

Lange habe ich mich gefragt, warum ich keine Leute gesehen habe, die darüber gesprochen haben. Nach einiger Zeit fand ich einige Artikel und Videos zu diesem Thema und bekam ein klareres Bild von diesem und anderen Konzepten wie den verschiedenen Arten von Testdoppeln, als ich das Buch Unit Testing Principles, Practices, and Patterns von Vladimir Khorikov las.

Wenn es also keine Klasse ist, was ist dann eine Einheit? Wie wäre es mit einer Funktionalität, verteilt auf mehrere Methoden oder Klassen? Sie könnten sagen: „Moment, das klingt nach einem Integrationstest.“ Naja, nicht ganz. Ich werde einige Definitionen aus dem Buch übernehmen:

Ein Unit-Test:

Ein Integrationstest erfüllt nicht mindestens eines der genannten Kriterien.

Ein guter Unit-Test:

Der Begriff „Einheit“ erscheint nun also abstrakter und flexibler. Außerdem können wir bei Integrationstests viele Dinge berücksichtigen, wie z. B. Systemtests, E2E-Tests usw.

Gehen wir also zu einer höheren Granularitätsebene. Lassen Sie uns die anfängliche Logik in einem Modul gruppieren und einige weitere Änderungen vornehmen:

[Klicken Sie auf das Bild, um es in voller Größe anzuzeigen]

Als erstes haben wir die Domänenlogik relativ gruppiertklein Modul. Ich bin mir nicht sicher, ob dies hilfreich ist, aber stellen Sie sich Module als Mikrodienst innerhalb eines Mikrodienstes vor. Wie klein? Wie bei fast jeder Entscheidung gibt es keine einheitliche Regel, die es zu befolgen gilt. Beachten Sie, dass es sich bei dem Beispiel um eine Vereinfachung handelt: Es können mehrere oder keine Entitäten beteiligt sein, und es könnten mehr Klassen vorhanden sein.

Es ist wichtig, die Kompromisse im Auge zu behalten:

Vorteile:

Nachteile:

Bedenken Sie, dass es sinnvoll sein kann, für wirklich komplexe Funktionen einen spezifischen Test durchzuführen.

Als Zweites haben wir die Domäne von den Framework-Komponenten getrennt.

Eine der Funktionen von Frameworks wie Spring besteht darin, verschiedene Elemente einer Anwendung zusammenzufügen. Was wir hier tun wollen, ähnelt der hexagonalen Architektur, auch bekannt als Ports und Adapter: Controller, Listener, Filter, DAOs oder andere Framework-Konstrukte sind Ports, die die Domänenlogik (Anwendungskern) mit der Außenwelt verbinden. Diese Komponenten enthalten im Idealfall kein Domänenwissen. Beispielsweise enthalten Controller, Listener und Filter ausschließlich einen Aufruf an die Domänenlogik (und bei Bedarf einen weiteren Aufruf an die Logik, der die Daten einem für das Domänenmodell benutzerfreundlicheren Format zuordnet).

Vorteile:

Eine Erweiterung der Trennung der Domänen- und Framework-Logik besteht darin, die Domänenlogik für jede Funktionalität nahe beieinander zu halten, um Kohärenz zu gewährleisten. Die gesamte mit dieser Funktionalität verbundene Logik ist in diesem Modul implementiert und nicht auf mehrere Module verteilt.

Ich habe bereits einen Albtraum erlebt, als ich die Codebasis eines Monolithen durchsuchen musste, um alle Stellen zu finden, die geändert werden mussten. Wir haben monatelang intensiv debuggt und die Hauptänderung war in zwei Tagen erledigt.

Wir brauchen lediglich Integrationstests für alles, was nicht in Unit-Tests getestet wird, wie zum Beispiel andere Framework-Funktionalitäten: Endpunktkonfiguration, Serialisierung, Deserialisierung von Daten und Fehlern, Datenzugriff, Remote-Aufrufe, Authentifizierung. Interessant könnte auch ein Rauchtest für den glücklichen Fall sein.

Der letzte Punkt, den ich erwähnen möchte, betrifft die E2E-Tests. e2e sind VIEL teurer als Integrationstests, also verwenden Sie sie mit Vorsicht:

Eine Alternative zu E2E-Tests für diese unkritischen Szenarien könnte die Verwendung vertragsgesteuerter Tests sein.

Ich kann mich an mehrere Fälle erinnern, in denen mir dieser Ansatz geholfen hätte. Das bedeutsamste war die Zeit, in der wir einen Algorithmus für ein Gebotssystem entwickeln mussten.

Die erste Implementierung des Algorithmus sah zunächst gut aus, doch jede Woche nach der Veröffentlichung entdeckten wir knifflige Szenarien. Wir fingen an, sie einzeln zu beheben, aber die Implementierung wurde bald zu komplex und es kam schließlich zu einem Vorfall.

Danach gingen wir es noch einmal durch und fanden einen anderen Ansatz. Am Ende hatten wir 75 % weniger Code und die Implementierung war viel einfacher. Das war das Gute daran.

Das Traurige daran ist, dass die Unit-Tests viele Methoden einzeln überprüft haben und wir eine Menge davon hatten. Hätten wir die Logik als Funktionseinheit getestet, hätten wir uns 12 Tage Arbeit (von 15) und viel Frust erspart, weil wir alle Tests noch einmal durchgegangen wären.

Zusätzlich zu all den genannten Vorteilen kann dieser Testansatz Ihre Zufriedenheit als Entwickler/Team steigern. Andere Strategien, die darauf abzielen, schneller zu liefern, erfordern die Überzeugung von Menschen außerhalb Ihres unmittelbaren Umfelds, und das kann sehr schwierig sein. Dies liegt ganz in Ihren Händen.

In Summe:

Und denken Sie daran:

Ich sage nicht, dass Tests auf diese Weise immer und für jeden gut sind. Sie müssen abschätzen, ob und in welchen Fällen Ihnen dies helfen könnte. Wie bereits erwähnt, kann es besonders in agilen Umgebungen hilfreich sein, in denen viel experimentiert wird, die Domäne in Iterationen erstellt und weiterentwickelt wird und regelmäßig neue Funktionalitäten integriert werden. Viele dieser Maßnahmen würden von Refactorings profitieren.

Einige dieser Vorteile können auch mit TDD (testgetriebene Entwicklung) erreicht werden, wenn wir es bewusst tun. Bedauerlicherweise neigen wir wiederum dazu, uns zu sehr auf das Werkzeug oder die Technik zu konzentrieren, ohne das Wesentliche zu verstehen und zu verstehen, was damit ursprünglich erreicht werden sollte, sodass wir nichts daraus machen und es am Ende aufgeben.

Die Einführung solcher Praktiken erfordert eine Änderung der Gewohnheiten und wir wissen, wie schwierig dies sein kann. Wir denken, dass Willenskraft das ist, was wir brauchen, aber das reicht nicht aus. Ich möchte einen Ansatz teilen, den ich kürzlich entdeckt habe. Es wird in dem Buch „Immunity to Change: How to Overcome It and Unlock the Potential in Yourself and Your Organization“ von Lisa Lahey, Ed.D., beschrieben. und Robert Kegan, Ph.D., Mitglieder der Harvard Graduate School of Education.

Wir versuchen oft, Veränderungen allein durch Willenskraft umzusetzen. Ihre Theorie ist, dass dies möglicherweise nicht funktioniert, weil wir so etwas wie ein „Immunsystem“ haben, das gegen Veränderungen arbeitet und alle unsere Versuche sabotiert. Um also eine Veränderung herbeizuführen, müssen wir zunächst dieses „Immunsystem“ aufdecken und an seinen Wurzeln arbeiten.

Dieses „Immunsystem“ wurde in der Vergangenheit entwickelt. Mit der Zeit versuchen wir, unsere Ziele zu erreichen. Um sie zu erreichen, befolgen wir eine Reihe von Schritten:

Diese Konzepte bilden die Grundlage des von ihnen implementierten Prozesses. Ich beschreibe die Schritte ganz kurz:

Wenn wir feststellen, dass die Annahmen nicht mehr gültig sind, arbeiten wir daran. Das erleichtert die Übernahme der Änderung.

Im Podcast „Dare to Lead“ setzen Lisa Lahey und Brené Brown anhand eines Beispiels aus Brenés eigenem Leben Immunität zur Veränderung in die Praxis um. Es besteht aus zwei Teilen (Teil eins und Teil zwei). Ich höre oft Podcasts, während ich andere Aufgaben erledige, aber das hier hat sich gelohnt, sehr aufmerksam zuzuhören.

Der Podcast beginnt mit einer kraftvollen Frage von Brené: „Warum wollen wir uns alle verändern und niemand möchte sich ändern?". Sie reden weiterhin darüber, dass wir das Scheitern einer Veränderung oft mit mangelndem Willen oder vorgetäuschten Absichten in Verbindung bringen. Sie erwähnen, dass Absichten nicht alles sind, weil Menschen, deren Leben in Gefahr ist und die leben wollen, es manchmal immer noch nicht schaffen, sich zu ändern.

Später arbeiten sie an einem Beispiel, das uns wahrscheinlich bekannt ist: Brené sagt, dass sie mit dem Team disziplinierter vorgehen möchte, was regelmäßige Meetings angeht.

Lisa gibt Brené einige Fragen, die ihr beim Ausfüllen der Spalten helfen sollen. Für Brené ist es ein Schlüssel, ihr Leben leichter zu machen und erfolgreich zu sein. Trotzdem und dass es etwas ist, was sie selbst ändern kann, konnte sie die Änderung nicht umsetzen.

Dann wird Brené überrascht, als sie die unausgesprochenen Verpflichtungen, Annahmen und Sorgen entdeckt, die sie sabotieren und zu der aktuellen Situation geführt haben. Sie sagt, dass sie in der Vergangenheit gelernt hat, dass sich Disziplin und Kreativität gegenseitig ausschließen, und glaubt daher, dass sie durch regelmäßige Treffen Zeit für das verliert, was ihr am meisten Spaß macht: Zeit, kreativ zu sein. Deshalb lässt sie diese Treffen aus, hat aber am Ende viele einmalige Treffen. Weil sie zeigen möchte, dass sie eine zugängliche Führungspersönlichkeit ist, sagt sie. Dies hat ihr geholfen, viele Ziele zu erreichen, aber jetzt verbringt sie zu viel Zeit damit und erkennt, dass regelmäßige Meetings die Situation nicht noch schlimmer machen, sondern ihr viel Zeit sparen könnten.

Letztendlich schlägt Lisa vor, dass sie Wege finden muss, diese neue Überzeugung zu bestätigen, dass Disziplin und Kreativität tatsächlich vereinbar sind. Das Ziel besteht darin, neue Nervenbahnen zu schaffen und die alten, die über Jahre hinweg geschaffen wurden, außer Kraft zu setzen.

Ich denke, wir können von dieser Strategie in zweierlei Hinsicht profitieren: Diese Sabotage unseres „Immunsystems“ zeigt, was wir tun, wenn wir versuchen, agil zu sein und gleichzeitig zu ignorieren, wie unser Code aussieht. Ich glaube, dass dies auf viele Aspekte unseres Lebens angewendet werden kann:

Nehmen wir beispielsweise den Fall der Umstellung auf diese neue Teststrategie, müssten wir herausfinden, was wir mit der Änderung erreichen wollen und warum sie wichtiger ist als andere Dinge. Für mich ist Flexibilität in meinem aktuellen Kontext von entscheidender Bedeutung.

In Bezug darauf, was wir möglicherweise tun, was dem Ziel zuwiderläuft, warum wir es tun und welche Annahmen wir getroffen haben, die diese Aktivitäten anstoßen, könnten wir denken, dass unser Leben einfacher sein könnte, wenn wir es auf die übliche Weise tun, weil wir es einfach müssen durch Trägheit weitermachen. Wir finden auch Gründe, es nicht zu tun: „Das ist die Art und Weise, wie wir immer getestet haben und wie es uns beigebracht wurde. Jeder macht es so, also muss es richtig sein.“

Um dem entgegenzuwirken, müssen wir die negativen Nebenwirkungen zum Ausdruck bringen und diese Überzeugungen umschreiben, dann einen Weg finden, zu beweisen, dass die Annahmen falsch sind, und schließlich die Änderung umsetzen.

Wenn Sie weitere Informationen wünschen, können Sie sich die Ressourcen ansehen, die im oben genannten Dare to Lead-Podcast (Teil eins und Teil zwei), auf der Website oder im Buch verlinkt sind.

Das Schreiben für InfoQ hat viele Türen geöffnet und die Karrierechancen erhöht Für mich. Ich konnte mich intensiv mit Experten und Vordenkern austauschen, um mehr über die von mir behandelten Themen zu erfahren. Und ich kann meine Erkenntnisse auch an die breitere Tech-Community weitergeben und verstehen, wie die Technologien in der realen Welt eingesetzt werden.

Ich habe das Mitwirkendenprogramm von InfoQ Anfang dieses Jahres entdeckt und es seitdem genossen! Das Peer-to-Peer-Review-System von InfoQ bietet mir nicht nur eine Plattform, auf der ich meine Erkenntnisse mit einer globalen Community von Softwareentwicklern teilen kann, sondern hat auch mein Schreiben erheblich verbessert . Wenn Sie nach einem Ort suchen, an dem Sie Ihr Software-Know-how teilen können, beginnen Sie mit der Mitarbeit bei InfoQ.

Ich habe angefangen, Nachrichten für die InfoQ .NET-Warteschlange zu schreiben, um auf dem neuesten Stand der Technik zu bleiben, aber ich habe so viel mehr daraus gemacht. Ich habe sachkundige Leute kennengelernt, weltweite Sichtbarkeit erlangt und meine Schreibfähigkeiten verbessert.

Redakteur für InfoQ zu werden war eine der besten Entscheidungen meiner Karriere . Es hat mich herausgefordert und mir in vielerlei Hinsicht geholfen, zu wachsen . Wir würden uns über mehr Leute freuentrete unserem Team bei.

InfoQ sucht einen Chefredakteur in Vollzeit dem internationalen, stets remote arbeitenden Team von C4Media beizutreten. Entdecken Sie mit uns die innovativsten Technologien unserer Zeit, arbeiten Sie mit den besten Software-Experten der Welt zusammen und helfen Sie mehr als 1,6 Millionen Entwicklerteams bei der Einführung neuer Technologien und Praktiken, die die Grenzen dessen erweitern, was Software und Teams leisten können!

Jeden Dienstag wird eine Zusammenfassung der Inhalte der letzten Woche auf InfoQ verschickt. Treten Sie einer Community von über 250.000 erfahrenen Entwicklern bei. Sehen Sie sich ein Beispiel an

Wir schützen Ihre Privatsphäre.

Sie müssen ein InfoQ-Konto registrieren oder sich anmelden oder anmelden, um Kommentare zu posten. Aber hinter der Registrierung steckt noch viel mehr.

Holen Sie das Beste aus dem InfoQ-Erlebnis heraus.

Zulässiges HTML: a,b,br,blockquote,i,li,pre,u,ul,p

Zulässiges HTML: a,b,br,blockquote,i,li,pre,u,ul,p

Zulässiges HTML: a,b,br,blockquote,i,li,pre,u,ul,p

Treten Sie einer Expertengemeinschaft bei. Überprüfen alle Ihre Unit-Tests Klassen oder Methoden isoliert? Haben Sie manchmal den Eindruck, dass Tests die Möglichkeiten, den Code zu ändern, einschränken? Verfügt Ihre Testsuite über viele Integrations- und E2E-Tests (End-to-End)? klein Warum wollen wir uns alle verändern und niemand will sich verändern? Jorge Fernández Rodriguez hat viele Türen geöffnet und Karrieremöglichkeiten erweitert. Das Peer-to-Peer-Review-System von Vivian Hu InfoQ hat mein Schreiben deutlich verbessert. Oghenevwede Emeni hat globale Sichtbarkeit erlangt und meine Schreibfähigkeiten verbessert. Die besten Entscheidungen meiner Karriere, Edin Kapić, haben mir in so vielen Bereichen geholfen, mich weiterzuentwickeln Möglichkeiten, unserem Team beizutreten Thomas Betts Vollzeit-Chefredakteur The InfoQ Holen Sie das Beste aus der InfoQ-Erfahrung heraus.