Ankündigung

Einklappen
Keine Ankündigung bisher.

Analyse von Legacy Code

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Analyse von Legacy Code

    Hallo zusammen,

    ich hoffe das Thema paßt in dieses Board.

    Ich stehe vor der Herausforderung bei einem großen Projekt mit sehr viel altem und wild gewachsenem Code diesen sinnvoll zu refactoren. Unter anderem gibt es eine große Datei mit >9k Zeilen Code, die von vielen Stellen mit unterschiedlichsten Parametern aufgerufen wird.

    Über diese möchte ich mir im ersten Schritt einen Überblick verschaffen, was auf Grund der Größe aber nicht ganz so trivial ist. Gibt es Tools, die mir einen Programmablaufplan o.ä. erstellen können, damit ich z.B. tote Codeblöcke schneller identifizieren kann? Ich bin auch für andere Ideen, wie man so etwas am sinnvollsten angehen kann, offen.

    Vielen Dank im voraus!


  • #2
    Also Programmablaufplan kriegst du mit Hilfe von XHprof hin. Aber das setzt voraus, dass du jede URL bzw jeden zustand deines Programms erzeugen kannst.

    Tote Codeblöcke kannst du so nicht finden. Es gibt auch schöne funktionen wie call_user_func_array der ein String entgegen nimmt und eine funktion ausführt. Generell bist du da ziemlich aufgeschmissen

    Was bei mir gut funktioniert hat, neue Features implementieren und dabei den Code Stück für Stück zu verändern. Nach über einem Jahr sehe ich fortschritt, mittlerweile ist Composer eingebaut, sowie autoloading aber ich immer noch weit vom guten code.

    apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/witalimik

    Kommentar


    • #3
      Wenn es wirklich _so_ schlimm aussieht wäre es vielleicht ein kompletter Rebuild eine Option. Meist ist es in Legacy-Applikationen so, dass Business-Cases, geschuldet dem Alter und der Verwilderung, schlecht implementiert sind. Da macht es häufig Sinn, die vorhandenen Cases zu identifizieren und neu zu implementieren.

      Du schilderst die Situation der Applikation als sehr verworren. Wenn ich bedenke, dass bei solch alten Systemen oft Sachen übersehen werden, ist es sehr wahrscheinlich, dass durch Refactoring Bugs entstehen, deren Lösung dann wieder neu Zeit kostet.

      Ich würde also überlegen, ob es nicht schlicht und ergreifend schneller ist, alles neu zu machen.

      Kommentar


      • #4
        Zitat von xm22 Beitrag anzeigen
        Wenn es wirklich _so_ schlimm aussieht wäre es vielleicht ein kompletter Rebuild eine Option. Meist ist es in Legacy-Applikationen so, dass Business-Cases, geschuldet dem Alter und der Verwilderung, schlecht implementiert sind. Da macht es häufig Sinn, die vorhandenen Cases zu identifizieren und neu zu implementieren.
        Darauf wird es wahrscheinlich hinauslaufen. Die Logik ist jedoch ziemlich verworren, da bei Änderungen immer nur neu dazuprogrammiert und kopiert wurden, anstatt den alten Krempel mal sinnvoll zu optimieren und entrümpeln.

        Zitat von xm22 Beitrag anzeigen
        Du schilderst die Situation der Applikation als sehr verworren. Wenn ich bedenke, dass bei solch alten Systemen oft Sachen übersehen werden, ist es sehr wahrscheinlich, dass durch Refactoring Bugs entstehen, deren Lösung dann wieder neu Zeit kostet.

        Ich würde also überlegen, ob es nicht schlicht und ergreifend schneller ist, alles neu zu machen.
        Die bestehende Logik nachzuvollziehen und neu zu programmieren ist meiner Meinung nach genauso fehleranfällig, als wenn ich das Refactoring nur Stück für Stück betreiben würde. Aber wahrscheinlich kann ich so trotz dessen immer noch besser den Überblick behalten, wenn Fehler auftreten. Dann finde ich das Problem schneller im neuen Code als wenn ich einen Mix aus alt und neu habe.

        Kommentar


        • #5
          poscht Du könntest versuchen, anhand von Request-Logging einen "Gold Master" zu erstellen (siehe http://blog.codeclimate.com/blog/201...aster-testing/).

          Kurzfassung:
          - Logge dir alle Inputs (z.B. $_POST, $_GET, $_COOKIE) und resultierenden Outputs (ob_start, ob_get_contents) über einen längeren Zeitraum
          - Erstelle einen Gold Master Test anhand dieser In- und Outputs (wenn Eingaben X,Y,Z, erwarte Ausgabe 0815)
          - Setze ein Testsystem auf, wo du den Goldmaster simulieren und laufen lassen kannst (alle Eingaben mit der Prüfung auf die entsprechende Ausgabe)
          - Refaktorisiere den Code und lasse den Gold Master erneut laufen
          - Besteht der Test, war das Refaktorsieren erfolgreich
          - Besteht der Test nicht, findet man den Fehler mit Debugging / Rückgängig machen

          Zu erwarten, dass man mit dem Gold Master ALLE Anwendungsfälle abdeckt ist meist utopisch, aber wenn man genug aktuelle Eingaben und Ausgaben hat und sich beim Erstellen des Gold Masters genug Zeit lässt, funktioniert das recht gut. Ist eben die Frage, wie viel Zeit du hast.
          Ein weiterer Vorteil ist, dass du dann einen recht guten Überblick hast, welche Funktionen tatsächlich oft gebraucht werden und welche nicht.


          Eine andere Alternative wäre das Complete Rewrite oder, je nach Anwendung, dass schrittweise extrahieren von einzelnen Funktionen in eine testbare API (z.B. REST)
          Fynder - http://www.fynder.de - Tutorials zum Thema Technik

          Kommentar


          • #6
            Hallo,

            ja, ansonsten halt die üblichen Tools: PHP Mess Detector, PHP Code Sniffer. Alles was eine Complexity größer als 10 hat solltest du überarbeiten. Dürfte bei dir ziemlich viel sein. Ich hoffe, das Tool explodiert nicht


            MFG

            derwunner

            Kommentar

            Lädt...
            X