Разработка скриптов для Google Apps: лучшие практики

Это обзор различных методов и лучших практик, которые я выработал за годы разработки скриптов Google Apps. Конечно, у Google есть несколько собственных предложений, и есть множество более общих руководств по лучшим практикам JavaScript, и даже несколько GAS — это красиво!

Свяжитесь с нами сейчас, если вам нужна помощь в создании собственных сценариев GAS или просмотрите некоторые другие бесплатные сценарии и фрагменты.

Стиль

Я стараюсь придерживаться руководства по стилю JavaScript от Google с намеком на предложения Дуга Крокфорда и всегда запускаю его через JSHint, чтобы держать себя в курсе! Я использую упрощенную поддержку JSDoc GAS, и я не буду вдаваться в свою политику интервалов, но я удостоверюсь, что их много, и стараюсь оставаться последовательным.

Еще одним замечательным ресурсом является это прекрасное изложение принципов чистого кода дяди Боба, примененных к JavaScript.

Ведение журнала/отладка трассировки

Я создал свою собственную библиотеку ведения журналов — BBLog — на основе библиотеки BetterLog, которая предоставляет такие функции, как:

• Ведение журнала в GSheet или Firebase DB
• Создание нескольких экземпляров журналов
• Автоматическая регистрация имен функций и номеров строк
• Автоматически регистрировать адрес электронной почты или идентификатор пользователя в полном или замаскированном формате.
• Оптимизация скрипта

В основном это служебные вызовы, которые замедляют ваш код (подробнее об этом здесь), поэтому наряду с трассировкой отладки, которую вы уже используете, загляните в View> Execution расшифровку в редакторе скриптов, чтобы увидеть любые служебные вызовы, которые излишне внутри циклов и т. д. .

Обработка ошибок

Основной принцип здесь — проводить различие между операционными и программистскими ошибками в коде; держите специфику ошибок программиста подальше от пользователя (надеюсь, все они будут устранены во время разработки) и четко обрабатывайте и устраняйте операционные ошибки — вещи, вызванные внешним миром, такие как ошибки ввода пользователя, недоступность внешних ресурсов и т. д. Эта статья больше посвящена разработке JavaScript для Node, но в целом это отличная статья об обработке ошибок.

Поэтому я удостоверяюсь, что любые вызовы из обработчиков событий (простые или устанавливаемые триггеры, такие вещи, как открытие файла, отправка формы и т. д.) находятся внутри try/catch, поэтому все возникающие ошибки могут быть аккуратно зарегистрированы и повторно вызваны в разработке, и либо обрабатывается, либо сообщается пользователю в производственной среде.

Тестирование

Я опробовал несколько библиотек тестовых фреймворков, доступных для GAS, но решил использовать собственную библиотеку underscoreGS. [link TBD]. Я нашел QUnit для GAS слишком громоздким, и я никогда не удосужился обновить его, а GSUnit воспроизводил многие функции, которые я уже включил в underscoreGS. Так что я стал немного более прагматичным и создаю простые функции модульных тестов в каждом модуле, если они им нужны, и их будет нелегко протестировать пользователю; такие вещи, как служебные функции более низкого уровня. Все эти отдельные функции тестирования модулей вызываются из главной функции тестирования, которую я свяжу с меню отладки на листе или в документе. Остальные тесты выполняются вручную. Мои сценарии еще недостаточно сложны, чтобы оправдать полностью смоделированную среду GAS для полностью автоматизированного тестирования. Хотя вы всегда можете разрабатывать свои автономные скрипты локально в eclipse, а также заглушать или создавать эмулированные сервисы Google, но я еще не пробовал (я уверен, что читал о том, что кто-то делает это, но не смог найти ссылку ).

Я считаю, что специальное меню отладки в листе или документе может быть полезно, чтобы избежать необходимости постоянно заходить в редактор скриптов для запуска функций во время разработки.

Шаблоны проектирования

Я вложил частные функции, чтобы избежать слишком большого беспорядка:

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

и оберните все функции в каждом файле скрипта в его собственном пространстве имен, просто обернув его в объект:

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

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

или используйте шаблон модуля, если я хочу иметь функции, закрытые для этого объекта:

  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

Библиотеки

Существует целый набор различных библиотек GAS, доступных для разных целей, я перечисляю основные из них, которые я использую в других местах, и здесь доступен довольно полный список.

Экспоненциальное резервное копирование

Службы Google могут время от времени выходить из строя без видимой причины, поэтому стоит упомянуть один интересный фрагмент, связанный с использованием экспоненциального резервного копирования для выполнения вызовов службы, т. е. повторных попыток вызова через разные интервалы времени, если он изначально терпит неудачу.

API Google

Существуют ограничения на функциональные возможности приложений Google, предоставляемые через встроенные службы GAS, однако доступ к большему количеству функций можно получить через API Google, которые они предоставляют для использования всеми типами веб-приложений. Вот, например, Drive API. Их немного сложнее использовать, поскольку вы копаетесь в ответах JSON и должны выполнять авторизацию, но иногда дополнительная мощность может стоить того — и они обычно работают быстрее.

Брюс Макферсон создал полезную библиотеку для использования Drive SDK.

Контроль версий/управление конфигурацией

В прошлом управление версиями с помощью Apps Script означало либо создание большого количества копий ваших проектов сценариев, либо настройку фантастического, но сложного GasGit. Что действительно произвело революцию в простоте, с которой вы можете осуществлять «правильный» контроль версий, так это «Google Apps Script GitHub Assistant». Это расширение Chrome, которое позволяет вам «отправлять» и «извлекать» определенные ветки в репозитории GitHub или BitBucket и создавать подобные потоки разработки.

Вы можете сохранить версии своего сценария, выбрав «Файл»> «Управление версиями…» в редакторе сценариев, однако доступ к этим старым версиям может быть неудобным.

Вы можете просто разрабатывать локально и использовать эту утилиту Node или Clasp для синхронизации ваших файлов с Github и загрузки в онлайн-редактор скриптов для запуска, но все станет грязным, если вы начнете вносить изменения и в редакторе скриптов!

Вот GDoc, описывающий рабочий процесс разработки с использованием GitHub.

Структура ГАЗ

Чтобы заставить себя работать и наблюдать за некоторыми из вышеперечисленных действий в готовом виде, я запускаю большинство своих сценариев с GASFramework. Это обеспечивает единую точку входа для общедоступных методов, а также последовательное ведение журнала и обработку ошибок.

Или взгляните на App Script Starter от Амита Агарвала — «современную среду разработки программного обеспечения для создания дополнений и веб-приложений Google с помощью скрипта Google Apps и JavaScript следующего поколения».

Дальнейшее чтение

Статья от Lucid — «6 смертных грехов разработки дополнений скриптов Google Apps»

Поток разработки Rudy для Google Apps ScriptНачните писать здесь…