ぼくのかんがえたさいきょうのGAS開発手法2023

前提clasp の制約、Script API の考え方、Google Drive の考え方に素直に従うその条件下である程度モダンな開発環境での開発を目指す 可能ならコードは VCS で管理する（pull-req など）ドキュメントベースで共同作業に向いた手法で開発を進める特にカジュアルに始めやすい Google Apps Script は悪い意味での属人化まっしぐらになりやすい。これが長期間の業務に影響しないような、ワンショットのものなら別にそれでもよいが、これが誰かに引き継がなければいけないような状況が生まれると一気に地獄みが増してしまうので、そうなってしまう前により良い開発手法を考えておきたい。 考慮したことGAS は素朴に作ると Script 本体の構造がそれを利用する container （例えば Spreadsheet）のデータ構造などと密結合になってしまう。この状態のままコード

[lyiase]

末尾に書いてあるとおり、GASは簡単だけど Google Workspace 上でしか動かない(アカウントが消えたらコードもトリガーもデプロイ消える)ことを最初に意識するべきだよね

[otchy210]

GAS はつまるところ Google 版 VBA であり、VBA が持つデメリットをほぼそのまま引き継いでいる。…ので、大袈裟なシステムの一部には使いたく無いなぁ。やるにしても大部分は別に持って GAS 自体は薄いラッパに徹するとか。

[thongirl]

GASはまともな管理とかローカルでのテストとか諦めた方がいい。vscodeでソース書いてgitで管理して(だからts大事)、claspでデプロイして、実行テストは全部ブラウザ。すぐ死ぬデバッガには期待しないでconsole.logデバッグ

[nharuki]

TypeScriptはエディタのサポートが得やすくなるのとclasp push時にJSへ自動変換されるから使った方が良いと思う派。たしかにデータ管理基盤が弱いのは同意。でもだからこそ型有りコードで補うべきでは？とも

[efcl]

GASの開発環境

[hihi01]

GASは素人として使っているのですが、この内容にはついていけませんでした。

[ftype]

型がないコードはもう無理

[ed_v3]

今ならaside使うのが良いのでは

[quality1]

人に紐づくんだよねー。どうにかならんものか

[wdoomer]

参考にします

[dekaino]

Gnu Assembler(ソース拡張子は.s) GASを使った開発ではなくて?

[yarumato]

“TypeScript は使わない。そもそもデータ側がふにゃふにゃ（DBMS のような堅いschemaを持っていない。データ側のrollbackはできない）であり、コードだけカチカチにしても意味がない。”