CodeRetreat bei SEEK: Clean Code vs Comfort Zone

Es ist Montagmorgen. Dies ist keine typische entwicklerfreundliche Zeit, um sich einen Tag lang direkt aus Ihrer Codierkomfortzone herauszuholen und in eXtreme Learning einzusteigen.

Doch dafür haben sich am 16. April 2018 20 mutige Softwareingenieure bei SEEK und 3 Gastcodierer aus der #DevOpsGirls-Community angemeldet. Sie hatten keine Ahnung, worauf sie sich einlassen. Agile & Growth Mindsets für den Gewinn!

Paarcodierung von Conways Game of Life gemäß den TDD- und XP-Methoden

"Übe und verbessere dein Handwerk."

Ein codeRetreat ist ein wiederholbares, eintägiges Ereignis, bei dem die Grundlagen der Softwareentwicklung unter Verwendung einiger der XP-Methoden (eXtreme Programming) wie Test Driven Development (TDD), Pair Programming und Simple Design geübt werden. Ziel ist es, die Änderungskosten immer weiter zu senken und Code zu schreiben, der Änderungen offen akzeptiert.

Während das Ziel für Entwickler jeden Tag darin besteht, das nächste Ergebnis fertig zu stellen, liegt der Fokus für Entwickler bei einem Code-Retreat darauf, zu üben und zu lernen - nicht fertig zu werden.

Nachdem wir uns an diese Grundlagen für sauberen und anpassbaren Code erinnert hatten, sprangen wir direkt in die Codierungssitzungen.

Das Abenteuer, das auf das Team wartete, bestand darin, Conways Spiel des Lebens in vier Sitzungen zu meistern, jedes Mal von vorne zu beginnen, jedes Mal den Partner zu tauschen, jedes Mal mit unterschiedlichen unterhaltsamen Herausforderungen (auch bekannt als Einschränkungen). Wir wollten doch unsere Ingenieure aus ihrer Codierkomfortzone für eXtreme Learning rausschmeißen!

Lass uns anfangen!

Jede Sitzung dauert 45 Minuten. Nach jeder Sitzung löschen die Teams ihren Code. Oft fängt hier das Fluchen an. Der Zweck des Löschens ihres Codes besteht darin, den Lernfokus zu behalten. Der kurze Zeitrahmen macht es den Teilnehmern nahezu unmöglich, Conways Spiel des Lebens zu beenden. Da jeder seinen Code nach jeder Sitzung löscht, spielt es keine Rolle, ob der Code wirklich schrecklich oder wirklich gut ist. Dies führt zu viel Freiheit beim Experimentieren mit unterschiedlichen Ansätzen für Codierung und TDD.

Sitzung 1: Aufwärmen

Sich mit dem Problem, dem TDD und dem Pairing vertraut machen.

sich warm laufen()
{
   timeRemaining = timer (45, time.minutes)
   while (timeRemaining)
   {
     Partnerarbeit()
     codeSolution ()
   }
   deleteAllCode ()
}

Sitzung 2: Ping Pong Pairing

Abwechselnd fehlerhafte Tests oder Implementierungen.

pingPongPairing ()
{
   timeRemaining = timer (45, time.minutes)
   while (timeRemaining)
   {
     driver.writeFailingTest ()
     swapDriver ()
     driver.makeTestPass ()
     driver.refactor ()
   }
   deleteAllCode ()
}
Eines der Ping-Pong-Paare

Session # 3: Mute Pairing

Keine Unterhaltung während der Sitzung (Ausnahme: Unbekannte in der Sprache / IDE).

mutePairing ()
{
  personA.canTalk = false
  personB.canTalk = false
  pingPongPairing ()
}

Session # 4: Baby Steps

Codierungszeit - 4-minütige Kästchen zum Schreiben und Bestehen von Tests.

kleine Schritte()
{
  timeRemaining = timer (45, time.minutes)
  while (timeRemaining)
  {
    stepTimer = timer (4, time.minutes)
    Versuchen{
      writeFailingTest ()
      makeTestPass ()
      gitCommit ()
    }
    catch (timeOut)
    {
      gitRevert ()
    }
  }
  deleteAllCode ()
}
Die Zeit läuft!

Iteratives Lernen auf 3 Ebenen

Ein codeRetreat zielt darauf ab, das Lernen zu maximieren, indem die Paare einem komplexen Problem ausgesetzt werden, während Einschränkungen als herausfordernde Sitzungsformate gelten.

Lernen auf vielen Ebenen. Foto von Element5 Digital auf Unsplash
CodeRetreat hat meine Fähigkeiten und meine Karriere mehr verbessert als jede andere Aktivität, die ich jemals durchgeführt habe. Auch als Moderator habe ich so viel gelernt. (Jim Hurne, US-amerikanischer Software Engineer und erfahrener CodeRetreat Facilitator)

Wir haben die Lernerfahrungen der Menschen verankert, indem wir uns Zeit genommen haben, um sie als Gruppe zu reflektieren und zu teilen: Iteratives Lernen = Sitzung + Retro.

Die 3 Lernstufen des Tages betrafen Pairing, TDD und das Wiederholen des gleichen Problems:

  • Im Laufe des Tages mit verschiedenen Personen zusammenzuarbeiten, führt zu vielfältigen Erkenntnissen aus verschiedenen Ansätzen für dasselbe Problem - konzeptionell und programmatisch (Programmiersprachen, Softwaredesign, IDEs, Tools, Forschung, Kommunikationsstil).
  • Durch wiederholtes Codieren des gleichen Problems erkannte das Team, dass es keine Möglichkeit gibt, eine Lösung zu entwerfen, zu codieren und zu testen. Die anfängliche Entscheidung, von außen nach innen (zuerst die Umgebung entwerfen) oder von innen nach außen (zuerst die Spielregeln entwerfen), bestimmte den TDD-Ansatz des Teams und wie viel sie erledigen würden und wie schnell sie lernen und ihr Design validieren würden .
  • Durch den Schwerpunkt Test Driven Development (TDD) der Sitzungen wurden die Teams aufgefordert, wirklich klein zu denken. Es gab viele „Aha“ -Momente über die Schwierigkeiten dieser Disziplin und vor allem über die Vorteile dieses Ansatzes, da TDD dabei hilft, den Entwurf der Lösung zu steuern, ohne die Lösung zu überarbeiten.
    Bei Agile and Lean arbeiten wir mit Teams zusammen, um den Abfall während des gesamten Produktlieferzyklus zu reduzieren. Wir unterteilen Probleme in kleinere Teile und konzentrieren uns darauf, dem Kunden die wertvollsten Gegenstände zu liefern, um die Geschwindigkeit und den Wert des Lernens zu steigern.
    TDD ermöglicht die Reduzierung von Verschwendung in der Softwareentwicklung, indem es sich unablässig darauf konzentriert, nur das Relevante und Wertvolle zu erstellen. Dies führt zu einem saubereren und anpassungsfähigeren Code. Dies ist eine wichtige Lehre für Softwareingenieure in einer Welt, in der Geschwindigkeit, Anpassungsfähigkeit und Kundennutzen den Erfolg von Einzelpersonen, Teams und Unternehmen bestimmen oder zunichte machen.
Das Team trifft sich, um seine Erkenntnisse und Beobachtungen auszutauschen

Was haben unsere Softwareingenieure gesagt?

Ping Pong Pairing: Löcher finden

Es war wertvoll zu sehen, wie jemand anderes Code schrieb, um meine Unit-Tests zu bestehen, da es ohne die in die Lösung eingebrachten Annahmen über und den Kontext Löcher in meinen Tests zeigte, die ich vielleicht nicht bemerkt habe, wenn ich alleine gearbeitet habe. (J. J.)

Silent Pairing: Ausdrucksvoller Code für Future Self

Ab Sitzung 3, in der wir nicht mit unseren Partnern sprechen konnten - Dies ist sehr relativ zu der Notwendigkeit, selbstausdrucksstarken Code zu schreiben, da unser zukünftiges Selbst oder jemand anderes unserem stillen Partner ähneln würde, der nur einen Sinn für die Bedeutung des Codes haben musste . (A.K.)

TDD: Falsch

Die Sitzung hat uns dazu gebracht, die Art und Weise, wie wir TDD machen, zu überdenken. Wir haben an einer Fallstudie zu TDD gearbeitet und alle unsere Testszenarien im Voraus entworfen. Ich habe mich immer gefragt, warum wir auch nach so vielen Arbeitstagen keine konkreten Ausgaben (Code) hatten. Jetzt habe ich die Antwort, wir haben TDD falsch gemacht. Es handelt sich nicht zuerst um Tests. Wir haben es jetzt überarbeitet und begonnen, ein einzelnes Testimplement zu schreiben und dann fortzufahren. (P.S.)
Die Konzentration ist während der kniffligen

Erleichterungslektionen gelernt

Es gab auch Erkenntnisse für uns als Moderatoren.

TDD-Bereitschaft
Eine der größeren Herausforderungen unserer Teams war die anfängliche Einrichtung ihrer TDD-Umgebung. Wir haben die Leute gebeten, sich auf ihren Laptop vorzubereiten, ihn mit einer IDE ihrer Wahl einzurichten, TDD-fähig zu sein und den Git zu installieren. Es war jedoch nicht explizit genug. Einige Teams haben es nicht einmal geschafft, an einer Übung teilzunehmen, da sie die ganze Zeit damit verbracht haben, ihre Umgebung einzurichten.

Das nächste Mal werden wir unseren Teams mehr Unterstützung bieten. Speziell für einen internen CodeRetreat. Für ein externes codeRetreat würden wir genauer erklären, was eine TDD-fähige Umgebung bedeutet und wie sie es testen können, um codeRetreat-fähig zu sein :)

Paarung nach dem Zufallsprinzip
Eine Idee, die nach dem Tag auf uns zukam, war, Spiele zu finden, um die Paarung zufällig zu ordnen. Natürlich neigen Menschen dazu, sich mit Menschen in ihrer Umgebung oder mit Menschen, mit denen sie bereits zusammengearbeitet haben, zu paaren. Es ist daher von Vorteil, unterhaltsame Möglichkeiten zu finden, um dem entgegenzuwirken.

Erleichterung in Aktion - Zeit zum Stoppen und Löschen des Codes

Vielfalt & #DevOpsGirls

Wir hatten eine vielfältige Gruppe von Menschen, die an der Veranstaltung teilnahmen. Von unseren jüngsten Associate Software-Entwicklern bis zu unseren erfahrensten Principal-Entwicklern (in anderen Unternehmen auch als Tech Leads bekannt). Mit 8 von 20 Teilnehmern hatten wir eine große Anzahl von Frauen im technischen Bereich. Dies ist viel höher als das übliche Verhältnis von <10% in jedem Team.

Die CodeRetreat-Moderatoren Victoria Schiffer, Michelle Gleeson mit unseren #DevOpsGirls Software Engineers Edit, Padmavathi und Natalia

Wir haben uns sehr gefreut, die Melbourne #DevOpsGirls-Community zu unterstützen, indem wir unser internes Training für 3 externe Software-Ingenieure geöffnet haben. Wir haben es genossen, dass sie ihre Konstruktions- und Ingenieursfähigkeiten einbringen und dass unsere Paare zusammen mit ihrer Erfahrung und ihrem Feedback lernen.

Es gab eine erstaunliche Stimmung im Raum und einige fantastische Gespräche, als jeder versuchte, das gleiche Problem zu lösen, während er unter den gleichen Bedingungen herausgefordert wurde.

Fazit

Am Ende des Tages waren alle erschöpft, als sie über ihre Herausforderungen und Erfahrungen nachdachten. Wir hoffen auch, dass unser codeRetreat uns dabei geholfen hat, SEEKs Ziele zu erreichen, indem es unseren Software-Ingenieuren geholfen hat, ein erfüllteres und produktiveres Arbeitsleben zu führen und unserer eigenen Organisation zum Erfolg zu verhelfen.

Interessiert an CodeRetreats - hier ist mehr!

www.coderetreat.org
Erfahren Sie mehr über codeRetreats, ihre Geschichte, wie man ein Event hostet oder moderiert und wo man das nächste Event in Ihrer Nähe findet.

Der nächste globale Tag von CodeRetreat #gdcr ist für den 17. November 2018 geplant. Speichern Sie das Datum, prüfen Sie, ob ein #gdcr-Event in Ihrer Nähe stattfindet, und folgen Sie @coderetreat auf Twitter oder treten Sie dem Software-Entwicklerteam bei.

Informationen zu einem anderen internen CodeRetreat, das bei REA ausgeführt wird, finden Sie in diesem Blog-Beitrag: http://rea.tech/tdd-in-bash-aka-our-1st-internal-code-retreat-rea/

Besonderer Dank geht an Michelle Gleeson, die den Tag gemeinsam mit mir veranstaltet hat, und an den Spaß am Zusammenspiel mit dem Pseudocode der Sessions. Auch an Jo Piechota, der das Event intern gemeistert hat. Vielen Dank auch an SEEK - Tim Smart & Craig Penfold für das Sponsoring der Veranstaltung für unsere Softwareingenieure. Und last but not least danke an Theresa Neate, die uns geholfen hat, #DevOpsGirls zu unterstützen, indem sie 3 externe Softwareingenieure von #DevOpsGirls eingeladen hat.