Google Apps-Skriptentwicklung – Best Practices

Dies ist ein Überblick über die verschiedenen Techniken und Best Practices, die ich im Laufe der Jahre bei der Entwicklung von Google Apps-Skripts entwickelt habe. Natürlich hat Google ein paar eigene Vorschläge gemacht, und es gibt viele allgemeinere JavaScript-Best-Practice-Anleitungen da draußen und sogar ein paar GAS-Anleitungen – diese hier ist hübsch!

Kontaktieren Sie uns jetzt, wenn Sie Hilfe beim Erstellen Ihrer eigenen GAS-Skripte benötigen, oder sehen Sie sich einige andere kostenlose Skripte und Snippets an.

Stil

Ich versuche, mich an den JavaScript-Styleguide von Google zu halten, wobei ich auf die Vorschläge von Doug Crockford hinweise und ihn immer durch JSHint lasse, um mich auf dem Laufenden zu halten! Ich verwende die vereinfachten JSDoc GAS-Unterstützungen, und ich werde nicht auf meine Abstandsrichtlinie eingehen, aber ich stelle sicher, dass es viele davon gibt, und versuche, konsistent zu bleiben.

Eine weitere großartige Ressource ist diese schöne Zusammenfassung der Clean-Code-Prinzipien von „Uncle Bob“, die auf JavaScript angewendet werden.

Protokollierung/Debug-Trace

Ich habe meine eigene Logging-Bibliothek – BBLog – basierend auf der BetterLog-Bibliothek erstellt, die folgende Funktionen bietet:

  • Protokollieren in einer GSheet- oder Firebase-DB
  • Erstellen mehrerer Protokollierungsinstanzen
  • Automatische Protokollierung von Funktionsnamen und Zeilennummern
  • Protokollieren Sie automatisch die E-Mail-Adresse oder ID des Benutzers in einem vollständigen oder verschleierten Format
  • Optimierung des Skripts

Es sind hauptsächlich Dienstaufrufe, die Ihren Code verlangsamen (mehr dazu hier), also werfen Sie zusammen mit dem Debug-Trace, den Sie bereits verwenden, einen Blick in Ansicht> Ausführungsprotokoll im Skripteditor, um alle Dienstaufrufe zu sehen, die sich unnötigerweise in Schleifen usw. befinden .

Fehlerbehandlung

Das übergeordnete Prinzip dabei ist, zwischen Betriebs- und Programmierfehlern im Code zu unterscheiden; Halten Sie Programmierfehler vom Benutzer fern (hoffentlich wurden diese alle während der Entwicklung behandelt) und behandeln Sie die Betriebsfehler sauber und schließen Sie sie aus – Dinge, die von der Außenwelt verursacht werden, wie Benutzereingabefehler, externe Ressourcen, die nicht verfügbar sind usw. Dieser Artikel hat mehr mit der Entwicklung von JavaScript für Node zu tun, aber es ist ein großartiger Artikel zur Fehlerbehandlung im Allgemeinen.

Daher stelle ich sicher, dass alle Aufrufe innerhalb von Event-Handlern (einfache oder installierbare Trigger, Dinge wie das Öffnen einer Datei, das Absenden eines Formulars usw.) in einem try/catch sind, damit alle ausgelösten Fehler ordentlich protokolliert und in der Entwicklung erneut ausgelöst werden können, und entweder gehandhabt oder dem Benutzer in der Produktion gemeldet.

Testen

Ich habe einige der für GAS verfügbaren Testframework-Bibliotheken ausprobiert, aber beschlossen, meine eigene um die underscoreGS-Bibliothek herum zu rollen [link TBD]. Ich fand QUnit für GAS zu umständlich und kam nie dazu, es zu aktualisieren, und GSUnit replizierte viele der Funktionen, die ich bereits in underscoreGS integriert hatte. Also bin ich ein bisschen pragmatischer geworden und erstelle einfache Komponententestfunktionen in jedem Modul, wenn sie sie brauchen und sie als Benutzer nicht einfach zu testen sein werden; Dinge wie Utility-Funktionen auf niedrigerer Ebene. Diese einzelnen Modultestfunktionen werden alle von einer Master-Testfunktion aufgerufen, die ich mit einem Debug-Menü im Blatt oder Dokument verlinke. Der Rest des Tests wird manuell durchgeführt. Meine Skripte sind noch nicht kompliziert genug geworden, um eine vollständig simulierte GAS-Umgebung für vollautomatisierte Tests zu rechtfertigen. Obwohl Sie Ihre eigenständigen Skripte immer lokal in Eclipse entwickeln und emulierte Google-Dienste erstellen oder Stub-out erstellen können, habe ich das noch nicht versucht (ich bin mir sicher, dass ich von jemandem gelesen habe, der dies tut, aber den Link nicht finden konnte ).

Ich finde, dass ein spezielles Debug-Menü im Blatt oder Dokument nützlich sein kann, um zu vermeiden, dass Sie während der Entwicklung ständig in den Skript-Editor gehen müssen, um Funktionen auszuführen.

Designmuster

Ich verschachtele private Funktionen, um zu viel globales Durcheinander zu vermeiden:

function aFunction() {
  var aVariable = localFunction()
  function localFunction() {
    // Do something that isn't accessible outside this function
  }
}

und verpacken Sie die gesamte Funktionalität in jeder Skriptdatei in ihrem eigenen Namensraum, indem Sie sie einfach in ein Objekt verpacken:

var NamespaceObject = {
  publicMethod: function() {
    Logger.log('public method called');
  }, 
  publicProperty: 'some value', 
};

NamespaceObject.publicMethod(); // public method called
Logger.log(NamespaceObject.publicProperty); // some value

oder verwenden Sie das Modulmuster, wenn ich private Funktionen für dieses Objekt haben möchte:

  var NamespaceObject = (function() {
    var namespaceObject = {};
    namespaceObject.name="NamespaceObject";
    namespaceObject.showName = function() {
      Logger.log('name: ' + namespaceObject.name)
    };
    return namespaceObject;
    function privateFunction() {
      Logger.log('Some private stuff');
    }    
  })()

  NamespaceObject.showName(); // name: NamespaceObject
  Logger.log(NamespaceObject.privateFunction()); // TypeError

Bibliotheken

Es gibt eine ganze Reihe verschiedener GAS-Bibliotheken für verschiedene Zwecke, ich liste die wichtigsten auf, die ich an anderer Stelle verwende, und hier ist eine ziemlich umfassende Liste verfügbar.

Exponentielle Sicherung

Die Google-Dienste können gelegentlich ohne ersichtlichen Grund fehlschlagen, daher ist ein interessanter erwähnenswerter Ausschnitt die Verwendung von exponentiellem Backup, um Serviceaufrufe zu tätigen, dh einen erneuten Versuch eines Anrufs in verschiedenen Intervallen, wenn er anfänglich fehlschlägt.

Google-APIs

Es gibt Einschränkungen für die Google-App-Funktionalität, die über die integrierten GAS-Dienste verfügbar gemacht wird, jedoch kann über die Google-APIs, die sie für alle Arten von Web-Apps zur Verfügung stellen, auf mehr zugegriffen werden. Hier ist zum Beispiel die Drive-API. Diese sind etwas schwieriger zu verwenden, da Sie in JSON-Antworten herumstöbern und eine Autorisierung durchführen müssen, aber die zusätzliche Leistung kann sich manchmal lohnen – und sie arbeiten normalerweise schneller.

Bruce McPherson hat eine nützliche Bibliothek zur Verwendung des Drive SDK erstellt.

Versionskontrolle/Konfigurationsverwaltung

In der Vergangenheit bedeutete die Versionskontrolle mit Apps Script, entweder viele Kopien Ihrer Skriptprojekte zu erstellen oder das fantastische, aber komplizierte GasGit einzurichten. Was die Leichtigkeit, mit der Sie eine „richtige“ Versionskontrolle durchführen können, wirklich revolutioniert hat, ist der „Google Apps Script GitHub Assistant“. Dies ist eine Chrome-Erweiterung, mit der Sie auf bestimmte Zweige in einem GitHub- oder BitBucket-Repo „pushen“ und „ziehen“ und so Entwicklungsabläufe erstellen können.

Sie können Versionen Ihres Skripts mit Datei>Versionen verwalten… im Skripteditor speichern, es kann jedoch schwierig sein, auf diese alten Versionen zuzugreifen.

Sie können einfach lokal entwickeln und dieses Node-Dienstprogramm oder Clasp verwenden, um Ihre Dateien mit Github zu synchronisieren und zum Ausführen in den Online-Skripteditor zu laden, aber die Dinge werden chaotisch, wenn Sie auch anfangen, Änderungen im Skripteditor vorzunehmen!

Hier ist ein GDoc, das einen Entwicklungsworkflow mit GitHub beschreibt.

GAS-Framework

Um mich zum Laufen zu bringen und einige der oben genannten Standardfunktionen zu beobachten, starte ich die meisten meiner Skripte mit GASFramework. Dies erzwingt einen einzigen Einstiegspunkt für öffentliche Methoden und eine konsistente Protokollierung und Fehlerbehandlung.

Oder werfen Sie einen Blick auf Amit Agarwals App Script Starter – eine „moderne Softwareentwicklungsumgebung zum Erstellen von Google-Add-Ons und Webanwendungen mit Google Apps Script und JavaScript der nächsten Generation“.

Weiterführende Lektüre

Ein Artikel von Lucid – „Die 6 Todsünden der Entwicklung von Google Apps Script-Add-ons“

Rudy’s Dev flow for Google Apps ScriptBeginnen Sie hier mit dem Schreiben…

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *