Total entsechst

1. Wie hört sich die folgende Erzählung eines gestressten VB6-Entwicklers für Sie an :

“Wir haben da eine Business-Anwendung, die den Firmen, für die wir diese entwickelt haben, seit Jahren treue Dienste leistet. Eine Anwendung, schnell, zuverlässig – naja, mehr oder weniger zuverlässig - die komplett in Visual Basic 6 geschrieben ist. Die einige Komponenten von Drittherstellern verwendet – typischerweise von DevExpress, Component One, Infragistics. Die im Laufe der Zeit auf über 100.000 Zeilen Code angewachsen ist, und aus nicht weniger als 100 Formularen besteht. Die aber dummerweise nur noch unter Windows XP zuverlässig läuft. Jetzt aber ‚machen‘ ja alle Firmen Windows 7. XP ist ihnen ja nicht mehr gut genug. Gut, Windows XP wird von Microsoft nicht mehr supportet, schon seit Ewigkeiten nicht mehr, und Treibersupport gibt es hier auch nur für die 32-Bit-Version in ausreichendem Maße, aber irgendwas ist ja immer.

Wieso so spät migrieren? Weil erst mit der massenhaften Ablösung von Windows XP durch Windows 7 die vielen VB6-Anwendungen wirklich problematisch werden!

Aber Windows 7? Das ist doch blöd: Da kann man einfach nicht mehr direkt ins „Programme“-Verzeichnis schreiben. Oder in die Registry – und alles wegen dieser komischen „Rechte“. Und manchmal kann man noch überall hinschreiben, aber dann packt es Windows 7 ganz woanders hin. Und viel schlimmer: Die Komponenten der Fremdhersteller laufen, wenn überhaupt, nur noch zur Hälfte, und entscheidende Funktionen der Software lassen sich nicht mehr aufrufen. Und die Fremdhersteller bieten überhaupt keinen Support mehr für ihre Produkte an. Außerdem beginnen die Kunden auch noch immer mehr „zu virtualisieren“, oder mit dem Terminal-Server zu arbeiten – das ist superproblematisch. Manche möchten sogar 64-Bit-Unterstützung, um mehr Speicher nutzen zu können, aber das geht in VB6 ja leider nicht. Klar, man könnte ja dieses .NET benutzen, da gab es ja auch mal diesen VB6-Migrations-Assistenten, aber irgendwie kommen da komische Ergebnisse raus. Da gibt es Typen wie Short und Decimal, und es gibt dafür kein Variant und kein Currency mehr. Und man muss sich an so viele Regeln halten, und Klassen verwenden und Methoden „überschreiben“! Und überhaupt: Dieses .NET sieht irgendwie aus wie Visual Basic, aber fühlt sich wiederum komplett anders als Visual Basic an.“

Schon mal gehört? Na dann, willkommen im Club – Sie sind in guter Gesellschaft, denn es gibt noch im Jahre 2012 eine unglaubliche Anzahl von teilweise unternehmenskritischen Anwendungen, die komplett in Visual Basic 6.0 entwickelt sind und deren Migration zu .NET noch nicht einmal begonnen hat. Und das sollte man gar nicht meinen, denn schließlich wurde die letzte Version des „Classic VB“ vor nicht weniger als 13 Jahren veröffentlicht. Und bereits im Jahre 2002 wurde eben dieses Visual Basic 6.0 von .NET abgelöst. Ausreichend Zeit, die schon damals als notwendig absehbare Visual Basic 6-Migration durchzuführen, wäre also gewesen, ach, aber warum? Es lief doch, und auch wenn auf Visual Basic 2002 Visual Basic draufstand – man hatte schnell das Gefühl, es war keines mehr drin. Also hat man es gelassen. Und erst jetzt zu einer Zeit, zu der Visual Basic 6-Anwendungen immer weniger reibungslos funktionieren, wird es wirklich mehr als Zeit - mit einem vor der Tür stehenden Windows 8 baumelt das Damoklesschwert übergroß über den VB6-Teams.

2. Das Erfolgsgeheimnis von Visual Basic 6

Mit Visual Basic 6 lässt sich bis heute Software extrem schnell entwickeln, ohne die typischen Restriktionen einer typsicheren Sprache. VB6 ist durch selbsterklärende Befehls- und Kommandonamen schnell zu erlernen und sehr leicht lesbar. Zwar hat es bestenfalls nur objektorientierte Ansätze, verfügte aber dafür schon zu einer Zeit über einen sehr liberalen Umgang mit Typen, als die Disziplin „Dynamisches Programmieren“ noch weitestgehend unbekannt war.

Einer der größten Vorteile ist aber, dass Visual Basic 6.0 über unglaublich schnelle Turnaround-Zeiten verfügt: Der Zyklus Editieren des Quellcodes, Kompilieren, Starten des Programms, Unterbrechen, Korrigieren, Neustarten war dank des Background-Compilers selbst bei mehreren 10.000 Zeilen großen Code eine Sache von Sekunden und weniger. Dank dieser „Vorzüge“ konnten selbst Programmiereinsteiger sehr schnelle Erfolge vorweisen. Visual Basic 6 erlaubte es einfach, Aufgabenstellungen schnell zu erledigen und sich dabei nur aufs Wesentliche, auf das eigentliche Thema der Aufgabenstellung zu konzentrieren. Und das genau ist der Grund, weswegen oft riesige Anwendungsmonster in einer Art von Fließbandproduktion entstanden, denn die Visual Basic-typischen Vorzüge hatten Auswirkungen auf die Zielgruppe von Visual Basic selbst: Sie ermöglichten nämlich eine Art Verschiebung der Anforderungen an die Entwickler, weg von eigentlichen Softwareentwicklungstechniken hin zum Fachbereich der Software. Klassisches und konsequentes Software-Design, wie es in der C++-Anwendungsentwicklung natürlich üblich, da nötig war, trifft man vermutlich auch aus diesem Grund selbst bei umfangreichen VB-Softwareprojekten eher selten an, doch dafür beeindrucken VB-Anwendungen immer wieder und bis heute durch das qualitativ hochwertige, branchenspezifische Wissen, das sie transportieren. Und die Geschwindigkeit, in der sie entstanden sind.

3. Die Zukunft von VB6 Programmen.

Eine Sache ist allen Visual Basic 6-Anwendungen leider gemein, fast buchstäblich: Sie führen unter modernen Betriebssystemen wie Vista, Windows 7 oder Windows 8 zu immer mehr Problemen, und das liegt in der Regel nicht an der eigentlichen VB-Laufzeitumgebung , die seit Windows Vista mit der msvb6vm.dll sowieso Bestandteil jeder Windows-Neuinstallation ist, sondern an vielen, alten COM-und OCX-Komponenten, die mit den strengeren Sicherheitseinstellungen der letzten Betriebssysteme einfach nicht mehr klarkommen. Hätte sich Microsoft nicht bereit erklärt, unter Windows Vista und im letzten Moment auch noch unter Windows 7 die Laufzeitumgebung neben den wichtigsten OCX-Steuerelementen angepasst für die jeweiligen Betriebssysteme zur Verfügung zu stellen, wäre mit Visual Basic 6-Anwendungen schon bei Windows XP Schluss gewesen. Bei Windows 7 stand die Entscheidung, diese Visual Basic 6 Virtual Machine auszuliefern, lange auf der Kippe, und es wurde erst kurz nach der Beta 2 für Windows 7 bekannt, dass es doch noch eine angepasste VB6-Runtime geben würde. Die gute Nachricht: Prinzipiell werden, so wie es aussieht (Stand: 30.11.2011), auch Windows 8 und Windows Server 8 mit einer eigenen VB6-Runtime ausgeliefert werden, sodass eine Ausführung von VB6-Programmen dort zumindest nicht per se verhindert wird. Doch das macht den Migrationsbedarf nicht weniger erforderlich.

Zuweilen rächt sich, was die Lauffähigkeit von VB6-Systemen auf modernen Betriebssystemen anbelangt, auch fehlendes Entwicklergrundwissen der VB6-Entwickler, etwa über die genauen Vorgehensweisen beim Ermitteln von oder dem Zugriff auf Spezialverzeichnisse von Windows – und das ist nicht VB6 geschuldet. So ist es nicht selten, dass Pfade zu Systemverzeichnissen (Windows, System32, Eigene Dateien, Programme) hart codiert und damit kultur- und betriebssystemversionsabhängig sind, oder – um ein anderes, häufig gesehenes Beispiel zu bemühen – der Zugriff auf die Registry in einer Weise erfolgt, dass das Betriebssystem schützend die Hand davor halten muss, und in beiden Fällen die Anwendung nicht mehr richtig funktionieren kann. Sind VB6-Entwickler also wirklich die schlechten Programmierer? Klare Antwort: Nein – Sie sind nicht schlecht, ihre Stärken liegen nur auf einem Gebiet, das dem typischen Entwickler oft fehlt, nämlich seiner Anwender-Kernkompetenz. Ein VB6-Programmierer programmiert nicht nur Berechnungen für Hochöfen, er ist Ingenieur und baut diese anschließend auch. Er ist nicht nur Verpackungsweltmeister, sondern schreibt auch noch die Software zur weiteren Optimierung. Er kennt sich in Zeitwirtschaft perfekt aus, und entwickelt Software, die eine enorme Kompetenz für andere Anwender vermittelt. VB6-Programme sind oft nicht sauber programmiert, und oft auch nicht schön (eher im Gegenteil). Aber sie transportieren fast immer ein ganz enormes Wissen.

4. Wieso ist es also so schwer von VB6 zu Visual Basic .NET zu wechseln?

Wieso ist es also so, dass viele der Anwendungen immer noch unter Visual Basic 6 im Einsatz sind, und es nicht längst eine Migration von VB6 zu VB.NET gegeben hat – schließlich gibt es doch ein neues Basic, das genau für diese Zielgruppe gedacht war? Dazu muss man wissen:

Die Namensgebung von Visual Basic .NET ist Grunde genommen eine Mogelpackung, und hätte lieber B# heißen sollen, um von vorneherein deutlich zu machen, dass es sich sehr vom Vorläufer unterscheidet. Zwar verwendet VB.NET im Gegensatz zu VB6 viele der Schlüsselwörter und Strukturen des Visual Basic-Vorgängers – es ist aber C# viel ähnlicher als C++ zu C#. Sehr viel ähnlicher. C#-Entwickler sind über diese Tatsache oft sehr verwundert – für Visual Basic 6-Entwickler ist das beim Erstkontakt ein regelrechter Schock, und auch die Erklärung: VB6-Code läuft schlicht nicht unter oder als VB.NET. So seltsam es auch klingt, vielleicht auch weil das Wort „Migration“ ein wenig negativ behaftet ist: einer Migration der eigentlichen Software muss im Falle von Visual Basic deswegen auch immer erst eine Migration des Entwicklungs-Teams voran gehen. Für Visual Basic 6-Entwickler entsteht dabei oft eine lange, teils schmerzhafte Phase des Abschiednehmens von alten Gewohnheiten und dem Neuerlernen von modernen Vorgehensweisen, deswegen sollte – ganz wichtig – die Teamleitung ausreichend Zeit für die Einarbeitung lassen und vor allen Dingen nach Möglichkeit ganze Tage einrichten, an denen die Entwickler wirklich Luft und einen freien Kopf zum Experimentieren und Lernen haben. Denn zu Lernen gibt es eine ganze Menge:

Be sharp, learn VB. Again.

Nicht nur gibt es viele Datentypen in .NET nicht mehr (Variant) oder unter neuem Namen (Currency wird zu Decimal) – bei Datentypen ändern sich Eigenschaften von einer Version zur anderen auch komplett: Integer unter VB6 ist 16 Bit breit, unter .NET sind es 32 Bit. Long unter VB6 ist 32bittig, unter .NET selbstverständlich wie in C# 64-bittig. Dazu verhält sich Code beim Umgang mit den Datentypen auch völlig anders: Dividiert man in VB6 einen Wert vom Typ Double durch 0, löst das einen Fehler aus. In .NET gibt das ein gültiges Ergebnis ohne Ausnahme, nämlich, je nach positivem oder negativem Dividend, Double.PositiveInfinity oder Double.NegativeInfinity. Arrays können in Visual Basic 6 beliebige obere und untere Grenzen haben, in .NET sind sie immer 0-basierend. Der Zugriff auf Objekte erfolgt in VB6 über ein spezielles Schlüsselwort, Set, da die Sprache in der Version 6 ganz einfach mehr mit Objekten umging, als sie tatsächlich selbst zu definieren. Auch aus diesem Grund kannte VB6 die sogenannten Standardeigenschaften; in VB.NET haben diese eine völlig neue Bedeutung. In VB6 würde so die Anweisung TextBoxVar = obj dazu führen, dass die Standardeigenschaft Text der TextBox-Instanz neu definiert würde. Für das Setzen einer neuen TextBox-Instanz wäre hingegen die Anweisung Set TextBoxVar = obj vonnöten. In VB.NET macht aber TextBoxVar = obj genau dieses, das Set-Schlüsselwort zum Setzen einer neuen Referenz in einer Objektvariablen gibt es hier nicht mehr, und um eine Eigenschaft neu zu definieren, muss der Eigenschaftenname auch wirklich genannt werden: TextBoxVar.Text = obj.

Dazu kommt: Visual Basic 6 ist nicht typsicher. Der Compiler macht nicht nur unproblematische, erweiternde (Integer zu Long) sondern auch gefährliche, schmälende Typ-Castings (Long zu Integer) bzw. ganze Typumwandlungen (String zu Date oder Integer) mit, ohne entsprechende Warnungen oder Fehler auszugeben. Er produziert sogar den Code, damit eine Umwandlung von einer Zeichenkette in einen anderen primitiven Datentyp funktionieren kann. In C# ist das undenkbar, in Visual Basic .NET zum Glück abschaltbar. Genau dieses liberale Verhalten des VB6-Compilers sollte aber bei einer VB6-Migration zu .NET abgestellt werden, da es der Grund für viele, schwer zu findende Bugs ist – als Zeichenkette wird bei absteigender Sortierung der „21.02.2010“ nach dem „22.05.2005“ einsortiert, erst als wirklicher Datumswert genau umgekehrt und korrekt.

Schon diese paar Punkte, die bestenfalls einen Eiswürfel auf der Spitze des Eisbergs darstellen, machen deutlich, dass alle Algorithmen angepackt, umgeschrieben und gründlich neu getestet werden müssen und nur in den seltensten Fällen können Migrationstools dabei helfen – eine aufwändige Nacharbeit und intensives Testing bleibt in jedem Fall erforderlich.

Dabei stellen die unterschiedlichen Verhaltensweisen der VB-Anwendungen bei gleicher Syntax nur eine Hürde dar, die mit Fleißarbeit und gutem Tooling noch zu nehmen ist. Ungleich schwieriger sind die unterschiedlichen Paradigmen, mit denen in Visual Basic 6 und Visual Basic .NET idealerweise programmiert wird – bzw. leider programmiert wurde: In Visual Basic 6 nämlich prozedural und in Visual Basic .NET wirklich und vollständig objektorientiert.

Ein Beispiel: In Visual Basic 6 landen Zeichenketten direkt in Container-Steuerelementen wie beispielsweise ListBoxen, in .NET komplette Klasseninstanzen, die dann – im OOP-Sinne – für ihre Text-Repräsentation selbst sorgen. Für C#-, C++, Java und Delphi-Programmierer ist das ein nicht erwähnenswerter Normalzustand, 95% aller VB6-Programmierer stehen hier erst einmal wie der Ochs vorm Berge. Ihre Sprache kennt nämlich keine klassische Vererbung, und damit auch kein polymorphes Aufrufen von Methoden über Variablen von gemeinsamen Basistypen einer Objekthierarchie, wie es die ListBox beispielsweise auf einfachste Weise mit ToString macht, um ein Objekt in seine Zeichenkettenrepräsentation umzuwandeln. Genau das ist die große Gefahr, wenn komplexe Projekte mit Migrations-Tools abgewickelt werden sollen: In der Regel werden alle Altlasten mitmigriert, und das Team muss sich weiterhin mit ihnen herumschlagen. Und bei schlüsselfertigen Migrationen, wie sie einige Firmen anbieten, kommt dazu erschwerend hinzu: Das Team bleibt außen vor, es ist später nicht in der Lage, den migrierten Programmstand zu pflegen.

5. Die Strategie: Erst das VB6-Team migrieren, dann die VB6-Software migrieren!

Egal, welche Strategie daher für die eigentliche Migration später zum Einsatz kommt, als Allererstes müssen die Entwickler eines Teams selbst von VB6 auf .NET migriert werden. Das funktioniert nur mit einer Mischung aus Schulung und Trainingsprojekt. Schon in dieser frühen Phase kann sich ein grober Fehler von Team- oder Geschäftsleitung schnell zum Show-Stopper für das gesamte Migrationsprojekt entwickeln: Eine Schulung muss immer themengebunden und mit garantierter direkt anschließender Praxisumsetzung durchgeführt werden. Der Dozent sollte sich einerseits die typischen Vorgehensweisen beim Entwickeln der VB6-Anwendung zeigen lassen und eine Art Ist-Analyse zur didaktischen Vorgehensweise seiner Schulung erstellen – in der Regel ist das innerhalb eines halben bis eines ganzen Tages getan.

Er kann dann daraus ableiten, welche Themen für eine Schulung – einerseits VB.NET-Programmiertechniken (Ereignisse, Delegaten, Vererbung, Lambdas, LINQ), andererseits Best Practice im Umgang mit den für das Projekt zunächst wichtigsten .NET-Bibliotheken – am besten geeignet sind. Das Allerwichtigste ist: Er muss dafür sorgen, dass diese Dinge direkt nach einer Schulung auch zum Einsatz kommen, und damit Team- bzw. Geschäftsleitung zwei Dinge abringen: a) Zeit zum Lernen und Umsetzen und b) ein Projekt, das den zu lernenden Stoff auch mit konkretem Sinn füllt. Ist das nicht zeitnah (maximal zwei Wochen) gewährleistet, wird eine Schulung erfahrungsgemäß komplett wirkungslos verpuffen, da die Vorgehensweisen bei der Programmierung von VB6 und VB.NET einfach zu verschieden sind.

Doch Trainingsprojekte sind in aller Regel schnell gefunden, und auch solche, die einerseits nicht unternehmenskritisch sind, aber dennoch einen manchmal gar nicht so kleinen Mehrwert für das Unternehmen oder die Kunden bringen: > Ein Softwareprodukt besteht in den meisten Fällen ohnehin nicht aus einer einzigen ausführbaren Anwendung, sondern aus den unterschiedlichsten Komponenten. Und in vielen Unternehmen gab es häufig immer schon das Bestreben, endlich einen Konfigurator für dieses oder jenes komplex einzurichtende Modul, einen Datenbank-Bereiniger und/oder Schema-Upgrader, eine Datenbank-Reorganisation oder bestimmte Statistiktools zu entwerfen.

In jedem Fall sehen diese ersten Schritte eines Migrationsplans, egal wie es anschließend weiter geht, gleich aus. Erfahrungsgemäß sollte, je nach Involvierung des Teams in laufenden Support und Kundenanpassungsprojekte, eine Einarbeitungsphase von 1-2 Monaten veranschlagt werden, bevor alle Team-Mitglieder produktiv in Visual Basic 2010 arbeiten können. Und ganz wichtig: Wenngleich sich Anforderungen an die Lernbereitschaft des Teams und das zu erwartende Arbeitsaufkommen anfangs als kritische Herausforderung anfühlen – eine Sache muss immer unterstützend berücksichtigt werden: Nach 10 oder mehr Jahren mit ein- und demselben Entwicklungswerkzeug endlich völlig neue Möglichkeiten und Optionen zur Verfügung gestellt zu bekommen, hebt den Motivationslevel eines Teams ganz enorm, und so funktioniert die „Team-Migration“ was deren einzelne Mitglieder anbelangt, mal schneller und mal weniger schnell, aber bis auf ganz wenige Ausnahmen immer.

6. Lassen Sie Ihr Team wieder das machen, was es als bestes kann!

Als Coaches spezialisiert auf .NET-Projektentwicklung bietet Ihnen ActiveDevelop eine Partnerschaft, die langfristig profitabel und risikovermeidend ist. Beratungsgespräche zu Projektbeginn klären, in welchen Bereichen der Schulungsbedarf Ihres Teams liegt, um es so schnell wie möglich auf Stand der Technik zu bringen. Eine Ist-Analyse Ihrer Infrastruktur führt zum Einsatz der geeignetsten Entwicklungswerkzeuge: Welche Visual Studio-Versionen, welche Form der Source Code-Verwaltung, welche Tools für die Kollaboration (wie Microsoft Team Foundation Server) sind erforderlich, um ideale Arbeitsvoraussetzungen zu erfüllen.

Darüber hinaus bringt ActiveDevelop eine ganze Reihe von Migrations-unterstützenden Werkzeugen und Strategien mit in die Projekte ein, die Ihnen helfen, das Rad nicht ständig wieder neu erfinden zu müssen. Sie möchten Antworten und Lösungen für die folgenden Probleme, unsere Aufgabe ist, sie Ihnen zu geben:

• Entscheidungshilfen zur Plattform-Findung: VB oder C#, Web- oder Forms-basierend, Silverlight, WPF oder Windows Forms. Ist Cloud-Compliance notwendig, in welchem Ökosystem soll Ihre Anwendung laufen?
• Wie sehen Deployment und Update-Szenarien aus? Sind Datenbank-Anpassungen beim Versions-Wechsel erforderlich? Soll sich Software automatisch aktualisieren, um den Ausroll-Aufwand zu rationalisieren?
• Schnelle Umsetzung und Migration von Formular-basierten Anwendungen trotz Neu-Entwicklung und objektorientierten Ansätzen. Umfangreiche Steuerelementsammlungen für Formular-reiche Migrationsprojekte, die auf die speziellen Bedürfnisse angepasst sind, helfen bei großen Projekten, bis zu mehrere Mannmonate Arbeitsaufwand einzusparen.
• Und ganz wichtig: Anwendungsframeworks auf Ihre persönlichen Bedürfnisse zugeschnitten. Ihr Team bekommt damit die Möglichkeit, sich wieder auf das zu konzentrieren, was es am besten kann: Die Umsetzung seiner domänenspezifischen Kernkompetenz in die Software.