agile software development in java

Refactoring von Legacy Code

Was kannst Du tun, wenn Du Legacy Code ändern sollst, aber den Code nicht richtig verstehst?

Nicht jeder Entwickler hat das Glück, in einem Projekt von Beginn an mitzuarbeiten. Oftmals bekommt der Entwickler die Aufgabe, ein altes Projekt zu pflegen oder weiterzuentwickeln.

Wenn einer der vorherigen Entwickler noch greifbar ist, ist das ein Glücksfall. Oft ist es aber so, dass Projekte von einem Kollegen zu einem anderen Kollegen „vererbt“ werden. Das Wissen der eigentlichen Schöpfer ist nicht mehr vorhanden, der Quellcode veraltet und es fehlt an Dokumentation. Der Entwickler muss mit Legacy Code arbeiten.

Was machst Du aber, wenn Du Legacy Code ändern sollst, jedoch den Code nicht richtig verstehst?

Auch ich musste mir diese Frage schon häufiger stellen. Mit diesem Artikel möchte ich Dir ein paar Tipps geben, wie Du dieses Problem angehen kannst. Am Ende findest Du dann eine kleine Checkliste und einen besonderen Tipp zur Arbeit mit Legacy Code.

Woher bekommst Du die nötige Sicherheit, um den Quellcode zu ändern?

Das Wichtigste für Änderungen an unbekanntem Code ist eine gute Absicherung. Diese Absicherung kannst Du mit Hilfe von Unit-Test erhalten. Dabei baust Du aber im ersten Schritt keine Klassentests, die die Methoden einer einzelnen Klasse prüfen, sondern Tests, die das grundlegende Verhalten der Anwendung sicherstellen sollen.

Änderst Du später Stellen im Code, siehst Du durch diese Test, ob sich das grundlegende Verhalten der Anwendung verändert hat. So erkennst Du auch Nebeneffekte, die Dir vorher völlig unbewusst waren. Du lernst den Code besser kennen.

Ein weiterer Schritt für mehr Sicherheit ist die Verwendung einer Versionsverwaltung. Dies sollte heutzutage eine Voraussetzung für jedes Entwicklungsprojekt sein. Ich erwähne es dennoch, da es für Dich als Entwickler auch psychisch sehr wichtig ist. Wenn Du ein fremdes Projekt weiterentwickelst, gehst Du immer Risiken ein. Also brauchst Du die Gewissheit, jeder Zeit einen alten, gesicherten und funktionierenden Stand wieder herstellen zu können.

Der nächste Schritt ist die Nutzung eines Continuous Integration Servers. Jedes Mal, wenn Du veränderten Code in Deine Versionsverwaltung spielst, sollte der Continuous Integration Server automatisch eine neue Version bauen und alle Tests durchlaufen lassen. So bekommst Du immer mit, wenn ein Test fehlschlägt.



Wie kannst Du den Code gut genug verstehen, um ihn zu ändern?

Da Du Dir nun ein Sicherheitsnetz für Deine Arbeiten am Quellcode aufgebaut hast, hast Du Dir auch ein Grundverständnis der Codebasis angeeignet. Oft reicht dieses grundlegende Wissen aber noch nicht aus, um konkrete Aufgaben und Änderungen am Code durchzuführen.

Ich mache mir an solchen Punkten immer Notizen. Dazu verwende ich ganz klassisch Papier und Bleistift. Besonders effektiv ist dies Technik bei großen Klassen. Mit Hilfe meines eigenen Pseudo-UMLs versuche ich die Abhängigkeiten der verschiedenen Methoden zu verstehen. Ebenso visualisiere ich mir auf diese Art die Abhängigkeiten zu anderen Klassen.

Notes for legacy code

Legacy Code mit Notizen verstehen

Mit Hilfe solcher Skizzen kannst Du dann erste Refactorings durchführen und den Lagacy Code Schritt für Schritt entziffern. Dabei überlege ich mir immer zuerst, ob die Methodennamen auch wirklich das ausdrücken, was die Methoden tun und passe den Namen eventuell an.

Danach schaue ich, ob die Klasse oder eine Methode vielleicht mehrere Aufgaben erledigen muss. Ich überlege, ob ich eventuell alle Methoden, die zu einer Aufgabe gehören in eine eigene Klasse auslagern kann. Ich versuche also, den Code besser zu strukturieren.

Auch bei dieser Aufgabe helfen mir meine Skizzen. Nebenbei drucke ich mir den Quellcode auch oft aus, markiere ihn mit verschiedenen Farben und mache mir Notizen in den Ausdruck.

Bei der Umstrukturierung des Codes versuche ich parallel Klassentests aufzubauen. So erhöhe ich meine Testabdeckung, um mehr Sicherheit zu erlangen, und gleichzeitig verstehe ich den Code wieder ein wenig besser.

Schließlich bereinige ich meine Klassen noch von totem Code. Dazu nutze ich die Möglichkeiten der Entwicklungsumgebung, beispielsweise von Eclipse.

Erst nach diesen Schritten wage ich mich daran, neue Funktionalitäten in den Code einzubauen.





Zusammenfassung

Ich habe Dir hier die wichtigsten Punkte zur Arbeit mit Legacy Code in einer Liste zusammengefasst. Diese Liste kannst Du auch als Checkliste verwenden.

Möchtest Du mehr über Refactoring von Legacy Projekten lernen, empfehle ich Dir das Buch Effektives Arbeiten mit Legacy Code. Refactoring und Testen bestehender Software
von Michael C. Feathers. Michael taucht richtig tief in das Thema ein und Du kannst sehr viel lernen. Eine echte Top-Empfehlung!

Woher bekommst Du die nötige Sicherheit, um den Quellcode zu ändern?

  • Grundlegende Verhaltenstests
  • Versionskontrollsystem
  • Continuous Integration

Wie kannst Du den Code gut genug verstehen, um ihn zu ändern?

  • Notizen zum Code
  • Toten Code löschen
  • Quellcode ausdrucken



  • Share


    Geschichten vom Scrum

    Auch Softwareentwickler lieben Märchen

    “Alle Menschen mögen Märchen, auch Softwareentwickler.” So ungefähr beginnt der Klapptext des Buches Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten
    . Und es stimmt! Warum also nicht einmal ein Märchenbuch über ein Fachthema lesen? Zumal sich Holger Koschek eine wirklich schöne Geschichte über Scrum, agile Softwareentwicklung und Projektarbeit ausgedacht hat.

    Holger Koschek selber ist Berater und Coache im Bereich agiler Softwareentwicklung und kennt sich mit Scrum und agiler Projektarbeit bestens aus. Und so wundert es nicht, dass dem Leser, soweit er ebenfalls in der agilen Softwareentwicklung heimisch ist, einige der Charaktere bekannt vorkommen.

    Das agile Team aus dem Märchenland

    Da haben wir zum Beispiel König Schærmæn, der ein agiles Projekt zum Bau der besten Drachenfalle starten will. Dazu setzt er seinen Sohn, Prinz Rollo, als Scrum Master ein. Zusätzlich holt er einen externen Berater an Bord: das Einhorn Bumaraia aus dem sagenumwobenen Land “Scrum”.

    Das Entwicklungsteam, die Musketiere, ist ein bunt gemischter Haufen mit einem alten, erfahrenen Ritter, einer Hexe, einem Großväterchen und einem Aschenputtel. Zwischenmenschliche Spannungen sind vorprogrammiert.

    Im laufe ihrer Arbeit passiert den Musketieren alles, was auch in wirklichen Projekten passiert. Erst müssen sie zueinander finden, dann mit sozialen Problemen kämpfen. Dann ändern sich wieder die Projektanforderungen, dann gibt es Probleme mit dem Budget, und so weiter und so fort. Doch zum Ende schliessen sie ihr Projekt erfolgreich ab, sind alle glücklich und wenn sie nicht gestorben sind, dann… .

    Was bringt Dir das Märchen?

    Das Buch dient sicherlich nicht zum Einstieg in das Thema Scrum und agile Softwareentwicklung. Dazu ist es wahrscheinlich auch nicht gedacht. Es geht auch zu wenig ins Detail, um es als ausserordentliches Fachbuch zu bezeichnen. Es ist aber eine wunderbare und kurzweilige Wiederholung und Vertiefung. Und nicht zuletzt ändert der Leser durch die Märchenform seinen Blickwinkel und regt dadurch seinen eigenen Geist an. So war es zumindest bei mir.

    Fazit: das Buch ist sehr lesenswert und ich kann es nur empfehlen. Es sollte aber nicht als Einstieg in das Thema Scrum und agile Softwareentwicklung genutzt werden.

    Hier geht’s zum Buch:

    Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten


    Scrum und das agile Manifest

    Scrum ist eine Entwicklungsmethodik, um Projekte in sozial komplexen Umgebungen zu organisieren. Solche Umgebungen zeichnen sich durch eine hohe Dynamik, viele Abhängigkeiten und häufige Veränderungen aus.

    Besonders beliebt ist Scrum in der agilen Softwareentwicklung. Doch was bedeutet eigentlich agile Softwareentwicklung und wieso ist Scrum eine agile Methodik? Dieser Artikel versucht eine Anwort zu geben.

    Im Februar 2001 trafen sich Kent Beck, Ken Schwaber und andere führende Köpfe der Softwareentwicklung in Utah. Kent Beck nimmt bis heute eine Führungsrolle im Bereich des Extreme Programming ein und Ken Schwaber gilt als einer der Mitbegründer von Scrum.

    Bei ihrem Treffen formulierten sie das Agile Manifest und das, was wir heute als agile Softwareentwicklung bezeichnen, bekam seinen Namen.

    Vier Werte und meine Interpretation für Scrum

    Das Manifest besteht aus vier Werten, denen sich die Beteiligten verpflichtet fühlen. Hier die deutsche Übersetzung

    1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
    2. Funktionierende Programme sind wichtiger als ausführliche Dokumentationen.
    3. Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprünglichen Leistungsbeschreibungen in Verträgen.
    4. Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans.

    Ausgehend von dem agilen Manifest haben die oben genannten Punkte bei Scrum folgende Bedeutung:

    1. Das Entwicklungsteam übernimmt größere Verantwortung und der Product Owner arbeitet eng mit dem Team zusammen.
    2. Zum Ende eines jeden Entwicklungszyklus steht ein auslieferbares Produktartefakt.
    3. Scrum nutzt kurze Entwicklungszyklen, um den Herausforderungen von sozial komplexen Umgebungen zu begegnen und legt Wert auf Kommunikation.
    4. Die Gültigkeit einer Schätzung dauert nur bis zum nächsten Sprint.

    12 Prinzipien, die noch heute gelten

    Hinter den vier Werten stehen weitere 12 Prinzipien, die an ihrer Aktualität nichts eingebüßt haben. An ihnen sollte sich ein agiler Softwareentwickler orientieren:

    Unsere höchste Priorität ist es,
    den Kunden durch frühe und kontinuierliche Auslieferung
    wertvoller Software zufrieden zu stellen.

    Heisse Anforderungsänderungen selbst spät
    in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen
    zum Wettbewerbsvorteil des Kunden.

    Liefere funktionierende Software
    regelmäßig innerhalb weniger Wochen oder Monate und
    bevorzuge dabei die kürzere Zeitspanne.

    Fachexperten und Entwickler
    müssen während des Projektes
    täglich zusammenarbeiten.

    Errichte Projekte rund um motivierte Individuen.
    Gib ihnen das Umfeld und die Unterstützung, die sie benötigen
    und vertraue darauf, dass sie die Aufgabe erledigen.

    Die effizienteste und effektivste Methode, Informationen
    an und innerhalb eines Entwicklungsteam zu übermitteln,
    ist im Gespräch von Angesicht zu Angesicht.

    Funktionierende Software ist das
    wichtigste Fortschrittsmaß.

    Agile Prozesse fördern nachhaltige Entwicklung.
    Die Auftraggeber, Entwickler und Benutzer sollten ein
    gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

    Ständiges Augenmerk auf technische Exzellenz und
    gutes Design fördert Agilität.

    Einfachheit — die Kunst, die Menge nicht
    getaner Arbeit zu maximieren — ist essenziell.

    Die besten Architekturen, Anforderungen und Entwürfe
    entstehen durch selbstorganisierte Teams.

    In regelmäßigen Abständen reflektiert das Team,
    wie es effektiver werden kann und passt sein
    Verhalten entsprechend an.



    Quelle: http://agilemanifesto.org/


    Das Product Backlog

    In diesem Beitrag geht es um das Product Backlog. Zuerst erkläre ich, was das Product Backlog ist. Danach beschreibe ich, auf welchen Grundlagen die ersten User Stories basieren. Denn bevor der erste Sprint startet, muss das Product Backlog mit User Stories gefüllt sein.

    Was ist das Product Backlog?

    Vereinfacht gesagt ist das Product Backlog eine Liste aller Anforderungen des Kunden. Diese werden als so genannte User Stories formuliert und sind nach ihrer Priorität sortiert. Verantwortlich für das Product Backlog ist der Product Owner.

    Mehr zu den Verantwortlichkeiten der einzelnen Rollen in Scrum findest Du in meinem Beitrag Das Wesen von Scrum.

    Wie werden die Anforderungen umgesetzt?

    Für einen Sprint entnimmt das Scrum Team User Stories aus dem Product Backlog und fügt sie in das Sprint Backlog ein. Das Sprint Backlog ist der Ausschnitt des Product Backlog, der in einem bestimmten Sprint umgesetzt wird.

    Bei der Auswahl der User Stories orientiert sich das Team an den Prioritäten des Product Owners.

    Da die User Stories zum Zeitpunkt der Auswahl bereits geschätzt sind, kann das Team abschätzen, welche User Stories in den Sprint passen und welche den zeitlichen Rahmen sprengen würden. Mehr zu Schätzungen von User Stories schreibe ich demnächst in einem anderen Blog.

    Nach der Auswahl der Stories leitet das Team konkrete Entwicklungsaufgaben aus ihnen ab.

    Eine User Story könnte beispielsweise lauten: “Als Nutzer möchte ich mich passwortgeschützt bei der Applikation anmelden können.”. Nun entscheidet das Team, welche Aufgaben zur Erfüllung der Story nötig sind. Dies könnten beispielsweise sein:

    • den Controller schreiben
    • die View schreiben
    • die Schnittstelle zum Server schreiben


    Wie wird das Product Backlog gepflegt?

    Das Product Backlog wird unabhängig vom Sprint gepflegt. Der Product Owner trägt ständig neue User Stories ein, verändert bestehende oder löscht hinfällige Stories.

    Hierzu steht er in ständiger Kommunikation mit dem Scrum Master, dem Entwicklungsteam und den Kunden. Erst wenn eine User Story vollständig formuliert, priorisiert und vom Team abgeschätzt ist, kann sie in ein Sprint Backlog übernommen werden.

    Wie füllt man das Product Backlog initial?

    Bevor der erste Sprint beginnt, sollte das Product Backlog bereits einige Einträge beinhalten. Diese leiten sich von der Product Vision und von zentralen Anforderungen der Kunden ab.

    Zum Thema Product Vision gibt es ein paar sehr gute Posts im Blog von Roman Pichler, den ich wärmstens empfehle.

    Gute Möglichkeiten, die zentralen Anforderungen zu finden, bietet das Vision Board (nähere Informationen hierzu gibt es wieder bei Roman Pichler) oder Anforderungsworkshops.

    In solchen Workshops treffen sich mehrere beteiligte Parteien: der Product Owner, der Scrum Master, Stakeholder und auch Team Mitglieder. Anhand aktueller Entwicklungen auf dem Markt oder im Vertrieb und anhand des Produktkonzeptes werden hier User Stories erstellt und priorisiert.


    Scrum – ein kurzer Überblick

    Das Wesen von Scrum

    Scrum ist eine Entwicklungsmethodik aus dem Bereich der agilen Softwareentwicklung. Manch einer beschreibt Scrum auch als agiles Managementframework.

    Dabei ist die Entwicklung in kleine, wiederkehrende Zyklen, so genannte Sprints, aufgeteilt. Entwicklungsziele und Ergebnisse werden nach jedem Sprint überprüft, angepasst, verworfen oder neu definiert.

    Allerdings ist Scrum kein Allheilmittel gegen die vielen bekannten Probleme der Softwareentwicklung. Sind beispielsweise die Programmierer schlecht ausgebildet, ändert Scrum an ihrem mangelnden Fachwissen auch nichts. Scrum zeigt lediglich einen neuen Weg für die Strukturierung der Softwareentwicklung. Gehen müssen den Weg die Beteiligten selbst.

    Zudem bedarf Scrum einer nicht zu unterschätzenden Lernphase. Es kann nicht von heute auf morgen beherrscht werden.


    Scrum Rollen

    Scrum hat flache Hierarchien und fordert von den Entwicklern, oder besser ausgedrückt von allen Teilnehmern, dass sie Verantwortung übernehmen.

    Die drei Hauptrollen bei Scrum sind der Product Owner, das Team und der Scrum Master.

    Product Owner

    Der Product Owner vertritt die Kundensicht und ist für das entstehende Produkt verantwortlich. Diese Verantwortung drückt sich beispielsweise durch folgende Aufgaben aus:

    • Erstellen einer Produktvision
    • Erstellen und Sammeln von Anforderungen
    • Entwicklung einer Roadmap
    • Definition der zu entwicklenden Module und Ziele
    • Kommunikation des Entwicklungsfortschrittes nach außen

    Die Anforderungen, aus denen sich später die einzelnen Aufgaben für das Team entwickeln, sammelt der Product Owner im Product Backlog. Dort werden die Anforderungen in so genannten User Stories formuliert. Eine User Story ist eine kurze textuelle Beschreibung des zu entwickelnden Features.

    Das Team

    Das Team entwickelt und setzt die Vision des Product Owners um. Die Entwickler implementieren die Anforderungen aus dem Product Backlog. Dabei bekommen sie Aufgaben nicht klassisch delegiert, sondern erarbeiten sich Tasks nach Diskussionen mit dem Product Owner und anhand der Produktvision selber.

    Zum Entwicklerteam können Architekten, Entwickler, Tester und andere Spezialisten gehören. Wichtig ist aber, dass sie sich alle als Team und nicht als Individualisten verstehen.

    Scrum Master

    Der Scrum Master ist mit einem Coach oder Consultant vergleichbar. Er leitet das Team an und hilft bei dessen Weiterentwicklung.

    Der Sprint

    Ein Sprint hat eine vorher festgelegte Länge von einer bis vier Wochen. Zu Beginn werden in einer Planungssitzung die zu erreichenden Entwicklungsziele definiert. Dabei handeln das Team und der Product Owner den Umfang jedes einzelnen Zieles aus. Die Ziele selbst leiten sich aus den User Stories im Product Backlog ab.

    Während eines Sprints wird ein tägliches Statusmeeting, der Daily Scrum, abgehalten. Hier berichten die Entwickler über entstandene Schwierigkeiten und legen sich eigene Entwicklungsziele fest, die bis zum nächsten Daily Scrum umgesetzt werden.

    Zum Ende des Sprints findet ein Review statt. Hier werden die umgesetzten Ergebnisse an den Product Owner übergeben und diskutiert.

    Nach dem Review findet ein weiteres Meeting, die Retrospektive, statt. Hier analysiert das Team mit Hilfe des Scrum Masters den abgelaufenen Sprint. Die eigene Arbeit und Arbeitsweise sowie das Umfeld wird kritisch betrachtet und nach Verbesserungen gesucht. Die Ergebnisse dieses Meetings fließen dann in den neuen Sprint mit ein.

    scrum-sprint

    Buchtipp

    Als besten Einstieg zum Thema Scrum empfehle ich das Buch von Roman Pichler:

    Scrum – Agiles Projektmanagement erfolgreich einsetzen


    Was ist hier los?



    Hier entsteht die nächste Generation meines Blogs mueller-kunad.de. Ich habe den Provider gewechselt und bei dieser Gelegenheit meine Seiten neu aufgesetzt.

    Die alten Artikel werde ich in den nächsten Wochen überarbeiten und Stück für Stück wieder veröffentlichen. Gleichzeitig wird es neue Artikel über die Themen agile Softwareentwicklung, agile Methoden und Java Programmierung geben. Artikel über viele Dinge, welche mir bei meiner Arbeit als “Agile Craftsman” über den Weg laufen und die es wert sind, darüber zu schreiben.


    « Ältere Einträge

    Powered by WordPress | Designed by Elegant Themes