Einige Tipps zur Vermeidung von Fallstricken
Refactoring von Designs

Das Wort ‚Refactoring‘ ist unter Softwareentwicklern bestens bekannt. Dieser vielleicht am treffendsten mit ‚Strukturverbesserung‘ zu übersetzende Begriff verursacht bei Designern, die in der Praxis damit zu tun hatten, durchaus ein leichtes Schaudern. Eine Vielzahl der Probleme und Unklarheiten, die sich beim Refactoring eines Designs einstellen, lassen sich jedoch mit sinnvollen Datenmanagement-Konventionen abmildern und mit einer rigorosen Datenmanagement-Methodik sogar ganz eliminieren.
Ein wichtiges Konzept ist das Refactoring jedoch in jedem Fall: man versteht darunter im Wesentlichen die Umformulierung des Codes in einem Programmmodul oder zumindest einiger Funktionen, um die Leistungsfähigkeit zu verbessern, ohne dass die Funktionalität oder wichtige Spezifikationen beeinträchtigt werden. Häufig wird diese Strukturverbesserung von den ursprünglichen Autoren des Codes durchgeführt, wenn diese nach erfolgter Freigabe Gelegenheit haben, sich den Code noch einmal vorzunehmen und jene Stellen, von denen sie wissen, dass sie etwas zu übereilt entwickelt wurden, zu verbessern. Unter Umständen kann es auch aus Gründen der Erweiterbarkeit erforderlich sein, die Abhängigkeiten zu ändern. Wenn man berücksichtigt, welche Bedeutung das Wort Refactoring im allgemeinsten Sinne hat, kann man diese Tätigkeit mit allen Designdisziplinen in Verbindung bringen. In der Mechanik etwa könnte ein Ingenieur das Innere eines Getriebes völlig neu konstruieren, um beispielsweise die Geräuschentwicklung oder den Verschleiß zu vermindern, ohne allerdings das Gehäuse, die Übersetzungsverhältnisse, die Anschlüsse und die Grundbelastung zu verändern. Das ist also mit diesem Begriff gemeint. Dieser Tätigkeit widmen sich auch häufig die für Elektronik zuständigen Abteilungen vieler Organisationen. Ich bin versucht zu sagen ‚aller Organisationen‘, aber das kann ich nicht belegen. Es handelt sich hierbei um die elementarste Form der Wiederverwendung von Design-Elementen: man nimmt ein Design oder einen Teil davon, fertigt eine Kopie davon an, benennt diese um und geht anschließend daran, nicht gewünschte Teile zu entfernen oder Neues hinzuzufügen. Auch wenn Sie persönlich dabei vielleicht etwas disziplinierter vorgehen, ist diese Vorgehensweise doch in der Industrie an der Tagesordnung. Allerdings hat diese Sache einen Haken. Geht man nämlich beim Anfertigen von Kopien der Designdaten für das Refactoring oder zum Erstellen einer neuen Version eines Produkts nicht sehr sorgfältig und strikt vor, so setzt man sich dem Risiko aus, auf einmal nicht mehr genau zu wissen, an welcher Kopie eines Dokuments man tatsächlich arbeitet. Man arbeitet vor sich hin und wird erst bei einem bestimmten Detail auf einer Seite argwöhnisch und bemerkt, dass man sich nicht in der Datei befindet, die man eigentlich bearbeiten wollte. Ein anderes Problem entsteht bei der Arbeit an Designdokumenten, die von einem fremden Autor stammen. Hier fehlt es möglicherweise an einer Aufzeichnung der Modifikationen, die von den Autoren oder auch von Dritten vorgenommen wurden, bevor diese Dokumente zu Ihnen gelangten. Was passiert beispielsweise, wenn Sie versuchen, eine Modifikation für Revision 3 vorzunehmen, wenn die Ihnen vorliegenden Quelldateien erst auf dem Revisionsstand 2 sind? Sie können dies nur dann bemerken, wenn die Dokumente irgendwo die richtige Revisionsbezeichnung oder nummer enthalten, und selbst dann muss man die richtige Version noch selbst ausfindig machen.

Beschränkung auf eine einzige Entwicklungslinie

Eine Vielzahl der Probleme und Unklarheiten, die sich beim Refactoring eines Designs einstellen, lassen sich mit sinnvollen Datenmanagement-Konventionen abmildern und mit einer rigorosen Datenmanagement-Methodik sogar ganz eliminieren. Der wichtigste Ansatzpunkt, um mit einem rigorosen Datenmanagement zu beginnen, besteht darin, sich bei jedem Projekt auf eine einzige Entwicklungslinie zu beschränken. Anstatt Kopien von Dateien an verschiedene Orte zu schicken, damit neue Versionen des jeweiligen Designs erstellt werden, sollte alles als ein Projekt behandelt und an einem Ort gehalten werden, damit nur dieses eine Projekt editiert wird. Die Designlösung Altium Designer mit ihren eingebauten Refactoring-Tools wurde gemäß dieser grundlegenden Erkenntnis entwickelt. Indem man keine Kopien eines Designs anfertigt, sondern stattdessen das existierende Design überarbeitet, erzielt man beispielsweise auch die uneingeschränkte Rückverfolgbarkeit. Mit jedem Speichern wird die Historie der betreffenden Datei aktualisiert, und man hat bei Bedarf jederzeit die Möglichkeit, zur vorigen Version zurückzukehren. Ebenso besteht die Möglichkeit, verschiedene Versionen in der Entwicklungs-Historie miteinander zu vergleichen, um im Detail zu sehen, was sich geändert hat. Noch besser ist es bei der Verwendung eines Versionskontrollsystems: hier steht eine lückenlose Aufzeichnung mit Benutzernamen und Kommentaren zu den eingefügten Änderungen (Bild 1).

Uneingeschränkte Rückverfolgbarkeit

Wird für ein Projekt an einem zentralen Ort genau ein Datei-Satz vorgehalten, gleich wo Sie sich befinden oder welcher Tag es ist, haben Sie immer die Gewissheit, dass Sie mit den einzigen Dateien arbeiten, die für dieses Projekt existieren. Es gibt keine weiteren halbfertigen Kopien, die in anderen Ordnern oder auf dem Computer bei Ihnen zu Hause herumliegen. Wenn Sie an verschiedenen Orten arbeiten oder mit anderen Usern ein Design in der Cloud bearbeiten müssen, gibt das Versionskontrollsystem jedem Benutzer die Möglichkeit, sich eine lokale Arbeitskopie anzufertigen. Diese Kopien werden jedoch alle wieder zusammengeführt und unter Wahrung der Rückverfolgbarkeit in den zentralen Haupt-Datenbestand zurückgeführt. Sie behalten somit stets die Übersicht, wann und warum ein User eine Änderung vorgenommen hat. Die Verwendung von Refactoring-Tools mit integrierter Versionskontrolle ist eine hervorragende Möglichkeit, die Innovation und Weiterentwicklung von Produkten ohne Probleme und Unsicherheiten voranzutreiben. Auch wenn kein Versionskontrollsystem vorhanden ist, lassen sich die üblichen Verwirrungen weitestgehend vermeiden, wenn man sich auf eine Entwicklungslinie für jedes Projekt beschränkt und sich die Historie im Storage Manager (Bild 1) zunutze macht.