どうも。つじけ（tsujikenzo）です。今日は単発で「ノンプログラマーによるGAS設計の現在地2022年1月」についてご紹介します。
この記事は、#GASDevelopementタグがついております。
はじめに
GAS Developementというブログ内の新企画を発表しましたが、「GAS開発」と言ってもとても範囲が広いものです。
なので、「この企画では、なにを目指そうとしているのか」などを、課題も含めて整理したいと思います。
どうやったらGAS開発がうまくいくのか
以前、「ノンプログラマーでも、ソースコードを処理のまとまりで書く、というスキルを手に入れることはできないのでしょうか。」という記事を書きました。
この記事を書いたときは、処理のまとまりで書くことは、イコール、オブジェクト指向やドメイン駆動設計だと思っていました。
しかし、学習を進めていくにつれ、「処理のまとまりで書く」という手法にも、ピンキリあることに気付き始めました。
なので、今後の開発メモをブログに残しながら、「処理のまとまりで書く」という手法を、棚卸していきたいと思います。
あとで考察を楽にするために意識する、開発中に注意しておく現段階での4つのポイントを、ご紹介します。
GASはオブジェクトの集まり
GASはJavaScriptをベースとした、プログラミング言語です。
Googleが提供している、Google Workspace Servicesをはじめとした、さまざまなサービスを操作できる、プログラミング言語です。
それらのサービスは、クラスとして提供され、プロパティやメソッドのリファレンスも提供されています。
なので、わたしたちは、必要なクラスを呼び出し、命令するGASを書くだけで、業務アプリケーションが作れます。
しつこいようですが、わたしたちがクラスを作成する必要はないのです。
ここが、注意するポイントの1つ目です。
データモデルは大活躍してきた
プログラミングの歴史をのぞいてみると、「オブジェクト指向」が流行する前は、「データモデル」が大活躍していました。
上から順番に流れるように処理を書く、「手続き型」のアプローチでは、データを扱うクラスと機能クラスを実装していました。
データを中心としたプログラミング手法が、「データモデル」です。
やがて、時代が移り変わり、情報量が増え、ソースコードも肥大化して、管理が大変になったとき、「データ中心じゃなくて、オブジェクト中心で書いたほうがいろいろ楽なんじゃない？」 と、言い出した人がいて支持を集めました。（かなり雑にまとめています）
逆にいうと、情報量も多くなく、ソースコードも小さければ、データモデルが大活躍する、というのがわたしの仮説です。
Googleがせっかく「ノーコード」とうたってGASを提供していますので、GASはデータモデルで実装する方がいいかもしれません。
ここが、2つ目のポイントです。
if文を書いていないか
ソースコードの可読性を落とす要素のひとつに、条件分岐があります。
if文やswitch文が増えるたびに、ソースコード全体の可読性が落ちると言われています。
if文やswitch文を排除するには、判定の対象要素を、クラスから生成されるオブジェクトにするテクニックがあります。
詳細は、別の記事でご紹介しますが、コードのなかにif文を書き始めたときは、操作しているデータをオリジナルクラスのオブジェクトにできないか検討しましょう。
ここが、3つ目のポイントです。
規模の大きな開発にはドメインモデルを
ノンプログラマーとはいえ、部署の基幹システムをGASで開発する機会もあると思います。
がっちり要件定義してからウォーターフォールではなく、あとで機能追加できるように、アジャイル開発したい、という声が多いでしょう。
後で機能を追加したり、保守性を高めたり、コードの再利用性を高めるためには、オブジェクト指向が強力な武器になります。
とくに、業務領域（ドメイン）を、ソースコードに反映させるドメインモデルは、オブジェクト指向の要素を取り入れた、最新の開発手法です。
わたしたちノンプログラマーでも、ドメインモデルから学ぶことはたくさんあると思います。
ここが、4つ目のポイントです。
弱いオブジェクト指向と強いオブジェクト指向
ポイントをまとめます。
ノンプロ研GAS中級講座で、はじめて「クラス」を学びます。まず、クラスは、「共通したデータや処理を集めておく場所にする」 と便利です。
もしかしたら、その “場所” は、スプレッドシートやGmailかもしれません。
前述した通り、スプレッドシートやGmailは、Googleが提供している既存クラスです。
なので、データモデルやGWS既存クラスに寄せたGAS開発を 「弱いオブジェクト指向」 と呼ぶことにします。
いっぽうで、ソースコードからif文やswitch文が排除されており、業務内容がそのままソースコードに反映されて、個々の部品をオブジェクトして全体を作り上げていくGAS開発を 「強いオブジェクト指向」 と呼ぶことにします。
まとめ
以上で、「ノンプログラマーによるGAS設計の現在地2022年1月」をお届けしました。
弱いオブジェクト指向か、強いオブジェクト指向かを決める要素はいくつかあると思います。
- 業務アプリケーションの規模
- 業務内容
- 扱うサービスの種類と数
- ウォーターフォールかアジャイルか
などなど
そのほかにも、外的な要因で、弱いオブジェクト指向で設計した方がいい、などの発見もあるかもしれません。
まずは、場数を踏んで、結果としてどのような形になったのかを、考察していきたいと思います。
