../qjsn/qjsn.html ../vtk/vtk.html


Copy & Paste vs Objectoriented Development

Unsaubere Softwareentwicklung und ihre Folgen ...

Vergleich von Copy and Paste vs Objektorientierung - als Beispiel ein simples Code Repository mit ähnlichen Dialogen (und irgendwelchen Paketen mit Geschäftslogik - hier nur skizziert) etc.

Verglichen wird eine GUI-Komponente, die in diesen Dialogen identisch verwendet wird und eigentlich als Komponente realisierbar ist.

Zunächst die Copy and Paste-Variante, die als Anti-Beispiel dient und dann die wartbare Lösung mit Objektorientierung ...


Anti-Beispiel Copy and Paste

Hier interessieren wir uns jetzt nur für die drei Dialoge, die eigentlich die identische Komponente enthalten, die aber durch Copy & Paste realisiert wurde...

Das bedeutet nichts anderes, als man implementiert eine Funktionalität in einem Dialog. Später will man die gleiche Funktionalität auch in anderen Dialogen verwenden und kopiert die relevanten Codeabschnitte in den entsprechenden Code des anderen Dialogs ...

In der Abbildung ist die Komponente in den Dialogen als "rotes Sechseck" symbolisch dargestellt (z.B. ein "Berechnungseingabefeld" oder "Auswahlelement" etc.). Der für diese "Komponente" gemeinsame Code in der betreffenden Header- und Quellcode-Datei ist mit den roten Rechtecken angedeutet.


Häufig wird bei der Neuentwicklung initial ein anderer Dialog kopiert und an den entsprechenden Stellen modifiziert (zur besseren Darstellung ist die Modifikation hier nicht gekennzeichnet).

In dem simplen Beispiel wurde also der HlpdDlg.{h,cpp} einfach aus dem kopierten InfoDlg.{h,cpp} initial gebildet - ist also eine Kopie davon (bis auf die notwendigen Namensänderungen, um den Code kompilieren zu können).


Dieser Zustand ist in diesem Beispiel die Ausgangssitutation ...


Der übliche "Entwickleralltag" ...

Jetzt werden Fehler gefunden ...

Der Tester oder Fehlermeldende hat natürlich keine Gesamtübersicht der Dialoge ...

Es wird also nur der Fehler für die ChartApp festgestellt und in diesem Fall an den Entwickler A gemeldet.

Unglücklicherweise hat der Entwickler A keine Kenntnis, dass dieser Fehler identisch noch in N anderen Dialogen (in diesem Fall in dreien) ebenfalls enthalten ist ...

Und es arbeiten unterschiedliche Abteilungen an dem Repository ...

Ein anderer Tester meldet auch noch den Fehler im InfoDlg-Dialog an einen anderen Entwickler ...

Entwickler A hat keine Ahnung, das Entwickler B ebenfalls einen identischen Fehler korrigiert - wie angedeutet, beide Entwickler sind in verschiedenen Teams oder Abteilungen etc. aktiv.


Mit entsprechender Laufzeit und mehr als zwei Entwicklern, entsteht entsprechend unerfreulicher, fehleranfälliger und unwartbarer Code, weil eben auch noch die Fehlerbehebung durch unterschiedliche Personen erfolgt, und dadurch auch die jeweiligen Lösungen noch zusätzlich völlig unterschiedlich sind.

Selbst mit Tools wie WinMerge kann man nun die ursprüngliche Gemeinsamkeit bald nicht mehr identifizieren, was dann auch Refactoring erschwert oder unmöglich macht.


Interessiert einen die Gesamtentwicklung nicht, ist man natürlich mit Copy & Paste schneller als mit einer sauberen, objektorientierten Lösung als Komponente.


Fazit:

  • Unwartbarer Code
  • Identische Fehler werden nicht überall erkannt
  • Identische Fehler, bekommen unter Umständen unterschiedliche Fehlerbehebung
  • Der Code ist zusätzlich insgesamt unnötig groß (wegen mangelnder Objektorientierung und wegen der "N-1 unnötigen Fehlerbehebungen")

  • Das Tool WinMerge ist eigentlich ein ganz hilfreiches Werkzeug, aber Copy & Paste und dem nachfolgende unterschiedliche Fehlerbehebungen (und vielleicht noch mit individuellem Code-Style für jeden Entwickler) machen es schnell unmöglich...

    Dieser Umfang von gelb markierten Code, zeigt eine noch überschaubare Abweichung an.


    Auch sehr interessant ist das Tool Atomiq, aber unter Windows 8 läuft es anscheinend nicht mehr.


    Objektorientierte, wartbare Lösung

    Es gibt hier zwei Möglichkeiten:

  • Ein Basisdialog, der die gesamte "Sechseck"-Funktionalität enthält (1a) oder als Komponente (1b) aufruft, oder
  • die "Sechseck"-Funktionaliät als Komponente als Klasse in einem Pfad für GUI-Basisfunktionalitäten (2)

  • Das ist letztlich eine Architekturdesign-Entscheidung ...




    1a) als Basisdialog mit der Funktionalität


    1b) als Basisdialog mit der Funktionalität als Komponente


    2) Einfach der Dialog mit der Funktionalität als Komponente



    Fallbetrachtung: Ein Fehler wird bei einem der fraglichen Dialoge festgestellt ( und es ist wieder die "SechseckKomponente" ):

    Wie wir sehen werden, reduziert sich der Aufwand für die Fehlerbehebung gegenüber der "Copy & Paste Entwicklung" erheblich ...



    1a) Hier als Basisdialog mit der Funktionalität


    Die vom Tester nicht entdeckten Fehler, werden hier im Gegensatz zur Copy and Paste Lösung automatisch korrigiert...


    1b) Hier als Basisdialog mit der Funktionalität als Komponente


    2) Einfach der Dialog mit der Funktionalität als Komponente


    Fazit und Vorteile der objektorientierten Entwicklung:

  • Oh Wunder: Statt N Entwickler an N Stellen unterschiedliche Fehlerkorrekturen durchführen zu lassen, reduziert sich das Problem auf eine einzige Stelle
  • Reduziert den Arbeitsaufwand und Ressourcen von Entwicklern und Testern erheblich
  • Ein Unit-Test für die Komponente ...
  • Wartbarkeit
  • Anstatt immer wieder die gleichen Fehler zu beheben, steht diese Zeit für sinnvolle Neu- oder Weiterentwicklungen zur Verfügung
  • Leider gibt es Firmen, die das einfach gar nicht kapieren ...


    =end of page=