この記事は17909 回閲覧されました。

Google Apps Scriptを使って業務改善や様々なツールを作成していくと、同じような関数や同じようなルーチンを何度も何度もコピペして作るのが常態化していきます。しかし、Googleの提供してるクラスやメソッドは終了してしまったり、また、制度の改正に伴って書き直しなんてのも発生してきます。そうなると、自分が書いた数多のプログラムの改修作業なんてのをしなければならなくなったりします。

また、前回紹介したユーザ定義関数などは、まさにライブラリ化すべき対象であり、巨大なルーチンでも独立して使うようなものに関しては、まるごとライブラリ化して、呼び出してしまうのはコードを書く量を減らしメンテナンス性を向上させるので、是非、暇な時に整備しておくと良いでしょう。

目次

今回自分が作ったライブラリ

ライブラリ化

ライブラリとして整備する手順

ライブラリ化するのは大して難しいことではありません。ライブラリ化を意識して関数を作るのには気を使いますが、手順はそれほど多くありません。注意事項だけ抑えておけば、他人もこのライブラリを流用することが出来ます。

  1. たくさん関数やメソッドだけを集めたファイルを用意する。ソレ以外のルーチンや構文は入れておかないように。
  2. スクリプトエディタの画面で、「ファイル」⇒「版を管理」にて版を保存する。
  3. スクリプトエディタの画面で、「ファイル」⇒「プロジェクトのプロパティ」にて、Project Keyをコピーしておく。
  4. Project Keyを使いたい人に教えてあげる。
  5. そのライブラリが詰まったファイルへのパーミッションを公開や、対象のユーザに閲覧権限を与えておく。

注意事項としては、

  1. プロジェクト名はわかりやすいものにすること。相手に表示されますから。
  2. 利用されたくないメソッドを含めてしまってる場合には、アンダーバー付きの関数名にしておくと良いです。(例:myFunction_()といった具合)。この場合、その関数はライブラリとして利用できなくなり、プライベートな関数となります。

gaskey

図:Project Keyをここで取得する

ライブラリを参照する方法

逆に公開されてたり、他人から共有されたProject Keyを使いたい場合には、自分のプロジェクトから参照させて上げると、その関数を利用することが出来るようになります。ちょっとだけ癖があるので、利用時には注意して下さい。

  1. スクリプトエディタ画面に於いて、「リソース」⇒「ライブラリ」を開きます。
  2. 出てきた画面で、Project Keyを検索ボックスに入れて選択ボタンを押す。
  3. バージョンを選択します。これは保存された版の一覧です。
  4. 識別子とは、関数を利用する時の頭につける文字列です。好きなのをつけて下さい。短めに設定すると良いです。今回は、oreを付けました。
  5. 関数を呼び出す時は、関数名を直接書くのではなく、識別子.関数名というスタイルで書きます。ドットでつなげるわけです。(例:ore.myFunction()といった具合)。あとは普通の関数と全く同じです。
  6. 識別子が既存のクラス名などとバッティングした場合、オーバーライドされてしまうので注意です。変な名前のほうが被りにくいです。
  7. オートコンプリートでライブラリ内の関数はずらっと出てきますので、選ぶだけです。

oresama

図:ライブラリ参照追加画面

oresama2

図:ライブラリから関数を参照してる様子

メジャーなGAS用ライブラリ

こうしたライブラリは個人の方が提供してくれているのですが、Googleが提供してるものもあります。

Project Key : MHMchiX6c1bwSqGM1PZiW_PxhMjh3Sh48

主に日付や時刻操作系のライブラリが詰まっています。この辺りの操作は様々なシーンでぶつかるので、自分で頭悩ませて作るよりこういったライブラリ使ったほうが早いです。というか、標準で搭載してくれればいいのにね。

Project Key : MGwgKN2Th03tJ5OdmlzB8KPxhMjh3Sh48

汎用JavaScriptライブラリをGASに移植したようなものです。関数型プログラミングを強力に推進してくれるライブラリです。非常に短いコードで処理を記述できるようになるので、使っている方も多いかもしれません。

他にも、このページでそれらライブラリの1例をProject Key付きで紹介しています。ただ、ちょっと探しにくいので、他になかなか見つからないです。多分たくさんあると思うのですが。自分が見つけたのはこれくらいでした。DB系だとこんなのもありました。

ライブラリ化する上で便利な手法

ライブラリを作る上で、これをやっておくととても便利というノウハウをいくつか紹介します。

DriveにアドオンプログラムとしてGoogle Apps Scriptを追加する

Google Driveにはデフォルトアプリケーション以外に、Googleが提供しているが、標準にはなっていないものが提供されています。Fusion Tableなどもその内の1つですが、もう一つ大変便利なものがあります。それが、その名もズバリGoogle Apps Scriptという名前のアプリケーションです。単体のスクリプトファイルとしてファイルを作れる便利なシロモノで、ライブラリ化するには持ってこいのものです。他にもこの先紹介予定の複雑なウェブアプリケーションを作る上で重要な要素になります。以下に追加方法を記します。

  1. Driveの新規ボタンを押し、その他を選択、アプリを追加をクリックする
  2. 出てきた画面で、google apps scriptと入れて検索する
  3. 出てきた項目の【接続】ボタンを押し、追加されたらOKボタンを押す。

これで、ドライブの新規作成のアプリのその他に「Google Apps Script」が追加され、単独のスクリプトファイルを生成することができます。スプレッドシートのGAS上でライブラリを作るよりもずっと便利ですよ。

gasapp

図:GASアプリに接続した様子

自動補完時に表示されるドキュメントも付けておく

スクリプトエディタの画面で、JsDocというものを書き込んでおくと、利用者にとっては便利かもしれません。実はライブラリ化した段階で、そのライブラリのドキュメントが自動で生成されており、そのページはライブラリの参照追加画面から飛ぶことができ、今回自分が作ったものだと、こんなページが勝手に出来ています。その際に、このJsDocと呼ばれるものをコードの上に書いておくと、自動生成のページが装飾されて、Google Developersのサイトのように、どんなメソッドにはどんな値がとれて、何を入れるべきなのかの説明文が記載されるようになります。

@paramと@returnだけしか使えないのですが、他にも簡単なHTMLや<pre>、<code>といったタグが使えて装飾が出来ます。利用者にとって優しいものを作るなら設置すべきでしょう。たとえば以下のようなコードがそれになります。

これを設置したaddUser関数のページ(ページの少ししたの方にあります。)を見てみると、記載ルールが正しければ、関数名とそれに対するパラメータ、そのタイプ、そして説明文がちゃんと反映されています。このページをわかりやすいところにリンクを貼っておいて上げればなおOKですね。

adduseretc

図:自動生成されたページ

ついでによく参照する項目をDBとして整備しておくと便利

ライブラリ化と直接関係あるわけじゃないのですが、組織内部で利用するスクリプトの場合、プルダウンメニューに表示する項目類や、スクリプト内で利用する項目類を特定のスプレッドシートに整備しておくと、ライブラリ化同様にメンテナンス性が向上します。例えば、支店名や施設名などがそれに該当します。これらを1つのスプレッドシートへまとめて置き、他のスクリプトからソレを参照し、参照させておいて再利用するわけです。

スプレッドシート上のプルダウンリストなどの為に整備するアレと同じことを1箇所でやるわけです。当たり前ですが、アクセス権限がなければ再利用できないので、そこは注意。HTML Serviceを使ったGUIアプリケーションを作る上では、これをやっておくと、後で幸せになれます(自分の場合、百数十もある施設名をあちこちのスプレッドシートで編集する羽目になったので、現在整備しています)。

また、その際には、塊単位で名前付き範囲を指定しておいて上げると尚良いでしょう。他のスクリプトのコードの編集が必要無くなります。(例えば、getRange(“A2:A”)なんて参照のさせ方はありますが、この場合、空白のエリアまで含めてしまうので、あまりよろしいやり方とは言えません。HTML上のプルダウンメニューで空白の項目までリスト表示されるのはマズイですね)。

ポイント

  • ライブラリ化するに当たって、そのスクリプト独自の処理をしてるものは、ライブラリ化してもあまりメリットはありません。例えばカラムの数が異なるとか、独自の処理が入ってしまっているルーチンなど。
  • ライブラリとして使うわけなので、それを意識した作り方をしないと、思わぬ挙動になってしまうので、入力と出力・参照するファイルなどは注意を払って作らないと、アクセスができなくなったり、変な返り値が返ったりするので注意。
  • 関数の名前は、ホイホイ変更してはいけません。また、互換性を意識して、なるべく版を複数保存し利用できるようにしておきます。
  • 同様に、引数などを増やしたり減らしたりした場合も、ホイホイ変えてしまうと、せっかくのライブラリ化が無駄になり、プログラムが動かなくなる原因になるので、版を保存しておき参照出来るようにしておきましょう。
  • doGetやdoPostなどの特別な関数類はライブラリ化できません。
  • 長いルーチンで独自の処理も入ってしまってるものは、細切れにして部分部分をライブラリ化し、それを活用しながら動かせるように構築してあげると、コード量を減らせます。どこが共通化できるか見極めましょう。
  • プロジェクトを1つのファイルに複数持たせて管理するのもひとつの手法です。
  • HTML Service側からはgoogle.script.runでライブラリの関数は実行出来ないので、ラッピングしてあげる必要があります。
  • 但し他人のライブラリというものは、ブラックボックスなのでセキュリティ的には危ういものを含んでいます。安易に導入するのはやめましょう。

関連リンク

Pocket
このエントリーをはてなブックマークに追加
Bookmark this on Yahoo Bookmark
Pocket