Visual Basic for Applications, kurz VBA, ist eine erstaunlich leistungsstarke Skriptsprache, mit der sich Microsoft Office-Anwendungen um scheinbar unbegrenzte Funktionalitäten erweitern lassen. In den vergangenen Jahren habe ich sie in verschiedensten Unternehmen immer wieder angetroffen und durfte Erweiterungen oder Fehlerbehebungen vornehmen.
Es ist faszinierend, in welcher Form VBA-Anwendungen in den Unternehmen eingesetzt werden:
Diese Liste liesse sich noch beliebig verlängern, denn den Möglichkeiten scheinen keine Grenzen gesetzt zu sein. Die Vorteile beim Einsatz von Excel und VBA sind immens: Zum Einen ist VBA eine sehr einfach zu lernende Skriptsprache, deren Schnittstellen (zum Beispiel zu Excel) sehr gut dokumentiert sind. Zum Anderen geniessen Office-Produkte bei den Endanwendern eine hohe Akzeptanz, da vielfach gute Grundkenntnisse in der Bedienung vorhanden sind und Microsoft Office in vielen Unternehmen zur PC-Grundinstallation gehört.
Nahezu alle der oben erwähnten Anwendungen bereiteten den Unternehmen Probleme. Manchmal führte ein Windows-Update zu einem Problem, oder die Anwendung funktionierte nicht, wenn sie auf verschiedenen Zielsystemen mit unterschiedlichen Office-Versionen ausgeführt wurde. Oder die Anwender hatten Probleme mit (für ihre Verständnisse kryptischen) Fehlermeldungen, nachdem sie in einem Excel-Datenblatt eine Spalte verschoben oder in ein Feld einen Buchstaben statt einer Zahl eingefügt hatten.
Wie kam es zu diesen Problemen? Häufig lässt sich beobachten, dass die Anforderungen im Laufe der Zeit gestiegen sind und die Komplexität der Makros entsprechend zugenommen haben. Aus einer anfänglich einfachen Funktionalität wurde ein äusserst umständliches Konstrukt. Wenn es sich zu allem Übel auch noch um spärlich kommentierten Spaghetti-Code handelt, nimmt die Wartbarkeit drastisch ab.
Da stellt sich die Frage: Muss das so sein? Verleitet VBA zu schlechter Code-Qualität und instabilen Anwendungen? Eine Antwort darauf habe ich bisher noch nicht gefunden. Dennoch gibt es Möglichkeiten, die Qualität und Wartbarkeit von VBA zu erhöhen.
Als Erstes lohnt es sich, sich die folgende Frage zu stellen: Braucht es wirklich eine Lösung in VBA, um beispielsweise eine Ferienplanung für Mitarbeitende zu erstellen, oder gibt es andere Möglichkeiten? Wenn VBA die sinnvolle und gewünschte Lösung ist, finden sich mit etwas Recherche ausführliche Dokumentationen. Viele VBA-Themen (z. B. ActiveX-Komponenten) werden mit guten Tutorials und hilfreichen Youtube-Videos erklärt. Durch dieses einfach zugängliche Wissen kann die Anwendung dadurch bestmöglich ausgefeilt und eingesetzt werden.
Hier stellt sich die Frage nach den detaillierten Funktionalitäten: Was soll im Einzelnen geschehen? Sollen in Excel lediglich falsche Eingaben rot hervorgehoben werden? Dazu braucht es keine Makros, solche Funktionalitäten lassen sich sehr gut mit bedingten Formatierungen umsetzen. Sollen Daten grafisch dargestellt werden, eignen sich Pivot-Charts sehr gut. Wer ungewollte Manipulationen verhindern will, kann dies mittels Blattschutz einschränken. Es braucht also nicht für alles VBA, denn vieles lässt sich auch sehr gut mit bereits vorhandenen Excel-Funktionalitäten umsetzen.
Bestimmt haben Sie bereits erlebt, dass nach dem Einfügen neuer Tabellenblätter oder dem Verschieben von Zellen das VBA-Makro nicht mehr ausgeführt werden konnte. Oftmals stösst man dann auf Code gemäss folgendem Beispiel:
Public Sub DoSomething1()
Dim wert As Integer
wert = Worksheets(1).Range("B3").Value
MsgBox ("Eingegebener Wert: " & wert)
End Sub
Werden die Arbeitsblätter umsortiert oder neue Zeilen eingefügt, funktioniert das Makro nicht mehr korrekt. Im schlimmsten Fall fällt der Fehler nicht einmal auf. Das folgende Beispiel ist robuster, da die Neuanordnung der Tabellenblätter oder das Einfügen neuer Zeilen für das Makro keine Rolle mehr spielt:
Public Sub DoSomething2()
Dim wert As Integer
wert = Worksheets("Uebersicht").Range("Range_InfoFeld").Value
MsgBox ("Eingegebener Wert: " & wert)
End Sub
Die Ranges-Bezeichnungen können komfortabel via Namensmanager bearbeitet werden. Aber auch das obengenannte Beispiel lässt sich noch optimieren, indem allfällige Fehler abgefangen und die Bezeichnungen als Konstanten definiert werden:
Private Const SHEET_UEBERSICHT = "Uebersicht"
Private Const RANGE_INFO = "Range_InfoFeld"
Public Sub DoSomething3()
On Error GoTo Fehlerbehandlung
Dim wert As Integer
wert = Worksheets(SHEET_UEBERSICHT).Range(RANGE_INFO).Value
MsgBox ("Eingegebener Wert: " & wert)
Exit Sub
Fehlerbehandlung:
MsgBox ("Fehler abgefangen! Wurde eine gültige Zahl eingetragen?")
End Sub
Spaghetti-Code und eine hohe Code-Redundanz müssen nicht sein. Es lohnt sich deshalb, sich regelmässig die Clean Code-Regeln zu Gemüte zu führen. Besonders das DIE/DRY-Prinzip möchte ich gerne jedem VBA-Entwickler nahelegen («Duplication is evil» / «Don’t repeate yourself»).
Zudem kann man sich durchaus auch mit der Code-Versionierung auseinandersetzen – auch hierzu findet man online Beispiele, wie VBA-Projekte mit einer Versionsverwaltung gepflegt werden können.
Unter dem Strich ist VBA nicht nur grossartig und nicht nur fürchterlich. Wenn man sich für eine VBA-Lösung entscheidet, soll sie mit der erforderlichen Sorgfalt umgesetzt werden, damit die Anwendung wartbar, erweiterbar und stabil wird. Unter dieser Voraussetzung kann VBA zielführend und effizient eingesetzt und erweitert werden. Da VBA-Makros jedoch meist anfänglich für kleine, simple Einsatzbereiche gedacht sind und schlussendlich doch zur eierlegenden Wollmilchsau umfunktioniert werden sollen, sollte von Anfang an eher eine andere Lösung als VBA gewählt werden. Ansonsten endet es meist leider so, wie ich es in den letzten Jahren immer wieder erlebt habe – dass die VBA-Anwendung nach einem unverhältnismässig grossem Arbeitsaufwand letztendlich doch durch eine alternative Technologie abgelöst wird.
Anregungen, Feedback und weitere Inputs hierzu sind äusserst willkommen.
Schreiben Sie einen Kommentar