Reduzieren Sie Risiken beim Anpassen von CRM-, ERP- und CMS-Systemen

  • Austen Harrington
  • 0
  • 4457
  • 1021

Regelmäßig habe ich das gewisse "Vergnügen", mit einem vermeintlich anpassbaren System wie einem CRM, einem CMS, einem ERP und dergleichen umzugehen. Eine Sache, die ich seit Beginn meiner Arbeit mit diesen Systemen gelernt habe, ist, dass das Anpassen dieser Systeme oftmals ein sicherer Weg in den Wahnsinn sein kann. Allzu oft wird das System durch Ihre Anpassungen "aufrüstungssicher" oder nahezu aufgerüstet. Obwohl dies in den meisten Fällen nicht vollständig vermieden werden kann, können Sie einige Maßnahmen ergreifen, um sicherzustellen, dass Ihre Änderungen nur minimale Schmerzen verursachen, wenn das Basissystem aktualisiert werden muss.

Der größte Schmerzpunkt ist die Vermischung von Code und Systemcode. Dies geschieht auf verschiedene Arten. Schauen wir uns diese also an:

  • Direktes Ändern von Systemdateien und Bearbeiten der integrierten Funktionen. Dies ist das höchstmögliche Verbrechen, das Sie begehen können, zum Beispiel den Diebstahl von Atomgeheimnissen und den Verkauf an eine fremde Macht.
  • Kopieren von Systemdateien und Bearbeiten der integrierten Funktionalität. Dies ist fast so schlimm wie das direkte Bearbeiten der Dateien, da Sie immer noch das gleiche Problem haben: Für Upgrades müssen Sie herausfinden, welche Änderungen Sie vorgenommen haben und welche Änderungen das Upgrade vornimmt, und Ihre Änderungen auf die neuen Dateien portieren. Damit haben Sie nur einen kleinen Teil Ihrer Arbeit vom Code des Systems getrennt.
  • Platzieren Sie Ihre benutzerdefinierten Dateien in der vorhandenen Struktur. Wenn das System Ihnen kein Verzeichnis speziell für Ihre Änderungen zur Verfügung stellt, ist die Wiederverwendung der vorhandenen Verzeichnisstruktur eine gute Möglichkeit, sich zu verderben, wenn der Anbieter es in der nächsten Version reorganisiert.

Stattdessen sollten Sie am besten eigene Klassen erstellen, die entweder die Standardklassen erben oder Teilklassen sind, abhängig von der Sprache und der Art und Weise, wie der ursprüngliche Code geschrieben wurde. Auf diese Weise können Sie die Funktionalität auf einer sehr diskreten, eingeschränkten Basis außer Kraft setzen, und falls sich der zugrunde liegende Code jemals ändert, ist das Schadenspotenzial minimal. Versuchen Sie, Funktionen hinzuzufügen, anstatt sie nach Möglichkeit zu ändern, um zukünftige Konflikte zu vermeiden. Auf diese Weise können Sie auch schnell und einfach Verweise auf Ihren Code finden. Verwenden Sie für benutzerdefinierten Code immer das vom Hersteller angegebene Verzeichnis. Wenn der Hersteller kein Verzeichnis angibt, erstellen Sie ein Verzeichnis, das zu 100% von der vorhandenen Verzeichnisstruktur getrennt ist.

Der zweite große Schmerzpunkt in der Art und Weise, wie Sie Ihre Änderungen vornehmen, ist das Speichern Ihrer Einstellungen. Die meisten dieser Systeme bieten die Möglichkeit, Einstellungen in einer Datenbank zu speichern und eine Grundkonfiguration zum Booten und Herstellen der Datenbankverbindung zu verwenden (z. B. web.config in ASP.NET). Es gibt keine beste Möglichkeit, Ihre eigenen Einstellungen zu speichern, aber wir können uns die Auswahl ansehen.

Sie können auch web.config (oder die Entsprechung in Ihrem System) für die Einstellungen verwenden. Der Nachteil der Einfachheit und der integrierten Tools besteht jedoch darin, dass Ihre Einstellungen außerhalb des Verwaltungssystems des Systems verwaltet werden. Dies verursacht auch zusätzliche Schmerzen bei der Bereitstellung auf einem anderen System (oder beim Übergang von der Entwicklung zur Bereitstellung in die Produktion), da Sie die Einstellungen mit der vorhandenen Einstellungsdatei zusammenführen müssen. Alternativ können Sie herausfinden, wie Sie mit der Datenbank des Systems arbeiten. Beachten Sie jedoch, dass dies nicht auf jedem System sauber verfügbar gemacht wird. Wenn möglich, sehen Sie sich die Codebasis des Systems an und sehen Sie, wie es auf die Einstellungen zugreift. Wenn es dafür eine Klasse oder Bibliothek verwendet, versuchen Sie, diese selbst zu verwenden. Das große Fragezeichen bei diesem Ansatz ist, dass Sie möglicherweise keine saubere Möglichkeit haben, Ihre Einstellungen in das System einzufügen oder der Administrationskonsole hinzuzufügen. Wenn Sie beide Bedenken mit einer vernünftigen Lösung beantworten können, ist dies meiner Meinung nach normalerweise der bessere Ansatz. Aber Sie müssen es nach Gehör spielen.

Der letzte große Problembereich betrifft das Änderungsmanagement. Es wird fast immer Zeiten geben, in denen Sie trotz aller Bemühungen eine dieser Regeln brechen müssen. Ich habe zum Beispiel mit Drupal gearbeitet und festgestellt, dass die E-Mail-Versandroutinen auf Windows-Servern aufgrund der Zeilenumbruch-Zeichenunterschiede und eines sehr strengen Mail-Servers fehlerhaft waren. Ich hatte drei Möglichkeiten:

  1. Ich könnte eine benutzerdefinierte Mail-Routine schreiben und jeden Verweis im System auf den neuen ändern.
  2. Ich könnte die Exit-Routine bearbeiten, um die Änderung einzuschließen.
  3. Ich könnte meine eigene Routine schreiben und die existierende bearbeiten, um einfach meine Version aufzurufen.

Die erste Wahl wäre die schlechteste. Obwohl ich die Kernfunktionalität in Ruhe lassen würde, müsste ich a Menge von anderen Teilen des Codes. In diesem Fall habe ich mich für die zweite Option entschieden, einfach weil meine Änderung so gering war. Ich habe den Code deutlich mit Kommentaren markiert und in meiner Projektdokumentation einen sehr wichtigen Hinweis darauf gefunden, dass der Patch portiert werden soll, wenn der Fehler in zukünftigen Versionen von Drupal vorliegt.

Egal was, du brauchen einen Weg finden, um sicherzustellen, dass solche Dinge dokumentiert sind. Es ist hilfreich, wenn Sie eine Möglichkeit finden, sich (oder jeden, der nach Ihnen kommt) zum Lesen der Dokumentation zu zwingen, z. B. eine schreibgeschützte Datei mit einem offensichtlichen Dateinamen in einem Bereich abzulegen, der bei jedem Upgrade überschrieben oder gelöscht wird. Stellen Sie sicher, dass alle Änderungen, die Sie am Code vornehmen, deutlich mit den folgenden Informationen gekennzeichnet sind:

  • Wann wurde die Änderung vorgenommen
  • In welcher Version war die Anwendung, als die Änderung vorgenommen wurde?
  • Warum haben Sie die Änderung vorgenommen?
  • Ein kurzer Überblick über die Auswirkungen der Änderung auf das System

Diese Informationen können im Code selbst als Kommentar oder in den Check-in-Hinweisen enthalten sein. Wenn Sie dies in den Check-in-Hinweisen tun, ist es wichtig, dass jeder Check-in nur eine Änderung darstellt.

Während die Arbeit mit solchen Systemen oft ein Hornissennest ist, können Sie mit diesen Vorschlägen hoffentlich so viel Risiko wie möglich minimieren.

J.Ja

Offenlegung von Justin Branchenzugehörigkeiten: Justin James hat einen Vertrag mit Spiceworks, um Produktkaufanleitungen zu schreiben. Er hat einen Vertrag mit OpenAmplify, dessen Eigentümer Hapax ist, über das Schreiben einer Reihe von Blogs, Tutorials und Artikeln. und er hat einen Vertrag mit OutSystems, um Artikel, Beispielcode usw. zu schreiben.



Bisher hat noch niemand einen Kommentar zu diesem Artikel abgegeben.

Tipps, nützliche Informationen und Neuigkeiten aus der Welt der Technik!
Nützliche Informationen und die neuesten technologischen Nachrichten aus der ganzen Welt. Videoüberprüfungen von Handys, Tablets und Computern.