Migrationsstrategien zur Abwertung der internen Skriptsprache

8

Wir haben eine Skriptsprache, die wir intern für viele Dinge verwenden. Es begann als einfache Bewertungsaussage für dynamische Labels, um eine vollständige Turing-Sprache zu werden, die in unserem System allgegenwärtig ist.

Das Problem ist, dass es nie dafür entworfen wurde und es zeigt. Die Entwicklungsumgebung ist anämisch, die erstellten Skripte sind nicht testbar und bis heute gibt es keine formale Definition der Sprache.

Eine wachsende Stimmung unter den Benutzern der Sprache hat das Gefühl, dass sie ihre Arbeit erledigt hat und es Zeit ist, loszulassen, aber wir stehen vor der schwierigen Herausforderung, die vorhandene Codebasis auf eine neue Lösung zu migrieren. Dieses Argument wird gegen die Idee der Migration verwendet.

Haben Sie jemals eine ähnliche Situation erlebt? und wenn ja, welche Strategien haben Sie angewendet, um die Nutzung des Alten zu stoppen und das Neue zu fördern?

Eine letzte Sache (danke Morons ) ist, dass viele dieser Skripte nicht dokumentiert sind und ihr ursprünglicher Zweck verloren geht, obwohl sie noch aktiv verwendet werden. Die Skripte werden auch bei Kunden vor Ort verwendet, um das System anzupassen, sodass wir buchstäblich Tausende dieser Skripte haben, von denen ein großer Teil weder der Quellcodeverwaltung noch einem Versionsmechanismus unterliegt.

Akzeptierte Antwort.

Dies ist eine schwierige Wahl. Alle Antworten waren gute und fundierte Ratschläge, obwohl ich denke, dass das Beste eine Mischung aus Moron und Oliver ist.

Am Ende habe ich Olivers akzeptiert, weil es die Antwort ist, die die beste Chance hat, höher akzeptiert zu werden (ha! Politik!). Das Packen der alten Skriptumgebung in eine aufrufbare Anweisung, die in die neue Umgebung integriert werden kann, bietet einen schnellen und einfachen Upgrade-Pfad.

Sobald dies erledigt ist, können wir die bessere Erstellung neuer Skripte steuern, indem wir Warnungen anzeigen oder verhindern, dass alle alten Skripte bearbeitet oder erstellt werden, um die neue Sprache zu verwenden.

Vielen Dank für Ihre Eingabe!

— Newtopian
quelle

4

Als ich das "eine letzte Sache (danke Morons)" las, dachte ich, Sie kommentieren die Intelligenz des ursprünglichen Designers.

— Kyle Hodgson

2

:-D nein, obwohl ich mich komisch fühlte, als ich es schrieb und eine Weile zögerte. Andererseits hat er den Namen gewählt, also denke ich, dass es in Ordnung ist!

— Newtopian

1

Es ist in Ordnung!! ......

— Idioten

5

Ein anderer Ansatz wäre, Ihre Skriptlaufzeit auf die neue Skriptsprache Ihrer Wahl zu portieren und Möglichkeiten zum Ausführen älterer Skripts in der neuen Sprache bereitzustellen.

LegacyRuntime.execute (String-Skript);

Die Möglichkeit, alten und neuen Code zu mischen, sollte den Übergang erleichtern.

— OliverS
quelle

11

Die Tatsache, dass Sie mit einer benutzerdefinierten Skriptsprache arbeiten, spielt keine Rolle. Sie migrieren eine Reihe von Skripten von einer Sprache in eine andere.

Es gibt 2 grundlegende Strategien:

1) Nehmen Sie sich große Mühe, um alle Skripte im Voraus zu konvertieren (als Projekt).

2) Wenn Sie Änderungen an bestimmten Skripten vornehmen müssen, schreiben Sie diese in der neuen Sprache um. Nach einiger Zeit, wenn nur noch wenige Skripte in der Originalsprache verfügbar sind, nehmen Sie ein Projekt auf, um diese abzuschließen. * *

In beiden Fällen müssen Sie eine feste Regel festlegen: Es wird kein neuer Code in der Legacy-Sprache geschrieben.

* Sie können auch eine Regel festlegen, wie viel Sie bearbeiten dürfen, bevor Sie das Ganze neu schreiben müssen. Dies wird jedoch wahrscheinlich als Schlupfloch missbraucht.

— Idioten
quelle

Ich glaube, ich habe vergessen zu erwähnen, dass viele der Skripte dort einen Zweck haben, aber dass das Wissen mit dem Schöpfer verschwunden ist, als sie das Unternehmen verlassen haben.

— Newtopian

1

Dies ändert nichts ... Sie müssen den Code irgendwann verstehen. Und irgendwann müssen Sie auch den Code ändern. (Es sei denn natürlich, niemand im Team hat vor, dafür da zu sein :-)

— Morons

1

Mit einer sehr einfachen Strategie wird es weniger wahrscheinlich sein, dass es Lücken gibt, die missbraucht werden. Als Ergänzung zur Strategie von Morons würde ich versuchen, sie alle in die Versionskontrolle zu bringen, bevor ich etwas unternehme.

— Refro

@refro Ich stimme dir zu, aber leider wäre es nahezu unmöglich. Es gibt wahrscheinlich ein Dutzend verschiedene Speicherformate für diese Skripte und keines ist sehr SCM-freundlich. Das Skript wird häufig als Basis-64-Blob dargestellt, der in den kompatiblen Editor geladen werden muss. Meistens liegt dies jedoch daran, dass die Skripte von Kunden direkt bearbeitet werden können und lokal in ihrer Datenbank gespeichert werden. Es gibt eine (vermutete) große Anzahl von Skripten, von denen wir nicht einmal wissen, dass sie existieren. Trotzdem bezweifle ich, dass viele Kunden viel in die Sprache investiert haben.

— Newtopian

5

Ich hatte so eine Erfahrung.

Mein Ansatz war es, die Sprachimplementierung rückzuentwickeln und eine mehr oder weniger formale Spezifikation für ihre Syntax und Semantik abzuleiten (stellen Sie sich vor, Sie dekonstruieren eine BNF aus einem handgeschriebenen Parser in Fortran77 mit mehreren Tausend Schlüsselwörtern). Dann habe ich einen Compiler für diese Sprache implementiert und ihn in einen idiomatischen Lua-Code übersetzt (wobei sogar die meisten Kommentare erhalten bleiben).

Sie können eine beliebige geeignete Skriptsprache auswählen oder Ihr eigenes, besser gestaltetes DSL implementieren. Der Compiler kann als transparente Übersetzungsschicht (wobei die alten Skripte intakt bleiben) oder zum Umschreiben der Skripte für eine bessere weitere Wartung verwendet werden.

— SK-Logik
quelle