kintone

怖いよ怖いよ、安易なカスタマイズ

2019-12-10

こんにちは！サイボウズ公認 kintone エバンジェリストの金春です。

この記事は kintone Advent Calendar Part2 の12月10日分としての記事です。ちなみにパート1はこちらです。

最近のkintone

kintone界隈ではすでに古株になってきている私ですが、最近kintone界隈が盛り上がっていてうれしいところです。

ただ、盛り上がるにつれて「怖いな」と思う場面も増えてきています。kintoneエバンジェリストとして「kintoneバンザイ！」なことばかりではなく、少しネガティブなことも発信すべきだと思うので、今回の記事では少しネガティブなことを書いていこうと思っています。

「今年の憂いは今年のうちに」です。

JavaScriptは甘くない

kintoneのJavaScriptカスタマイズ（以下、JSカスタマイズ）については、Cybozu Developer Networkで様々な質問が飛び交っています。

ここでやりとりされている質問および回答をみていると怖いものがいくつかあります、いくつか例を上げてみていきましょう。

ほんとJS怖いですw

グローバル汚染

JSには、グローバル変数があります。ただ、様々な人が書いたJSが混在しながら動く環境下で、グローバル変数を使うと、意図しない挙動をすることがあります。

var hogehoge;

(function () {
	“use strict”;}()
);

‍

こういうやつですね。hogehoge は、即時関数の外で定義されているので、JSファイルをまたいで利用することができます。しかも、この書き方だとhogehogeがいつ初期化されるかも不明なので、より怖さがアップしています。

JSファイルをまたげるということは、自分が書いたJS以外からでもアクセスできるということです。

そうすると、他のJSが同じ変数を変更していたら・・・当然意図した動作をしなくなります。

そもそも、kintoneのJSカスタマイズにおいて、カスタマイズコードは即時関数として作成しろというルールがあるのは、このグローバル汚染を防ぐためなんです。なのに、グローバル変数を自ら定義してしまうと、即時関数を作っている意味が薄れてしまうわけですね。

自分しか命名しないような変数名にするから大丈夫

という方もいらっしゃるかもしれませんが、複数のJSファイルから参照される変数を定義すると、それだけでプログラムの可読性が大幅に落ちます。未来永劫自分で面倒見るようなプログラムであれば、上の主張も構わないと思いますが、異動になったり退職したりして誰かが引き継ぐとなったときに、それでも大丈夫と言えますか？

Promise地獄

kintoneでは一部のAPIがPromiseに対応していますが、Promiseの理解を正しく行わないまま、見よう見まねでPromiseを使っている例があります。

Promiseに対応した非同期APIは、当たり前ですが非同期に実行されます。

for( let i = 0; i < 100; i++ ){
	return kintone.api(なにがしかiを使う);
}

‍

みたいなコードが散見されます。kintone.apiは非同期なのでこのループは、1つ1つのkintone.apiの終了を待つことなく、くるくる回って抜けてしまいます。

この手の解決策として、処理対象をmapして、reduceを使ってthenでつないでいきましょね。ということになるのですが、map / reduce で非同期処理って、非同期がちゃんと想像できないと動きのイメージが持ちにくいので、よりカオスになる人が多いんです。

async / awaitがメジャーになればもうちょっと楽にはなるんですが、それにはもうちょっと時間がかかりそうな情勢なので、今の時点ではPromiseをちゃんと使えるようになりましょう。

抑えるべきキーワード

他にも例は色々ありますが、kintoneのJSカスタマイズを実装するにあたり、以下のキーワードはその意味と意義まで理解しておいていただいたほうがよいんじゃないかと思います。これらを理解せずにカスタマイズをすると思わぬ罠に引っかかることがあるやもしれません。

kintoneのイベントとそのイベントでできること（やっていいこと/できるけど無理することになること）
即時関数（JavaScriptの変数スコープ）
var / const/ let の違い（変数の巻き上げ）
グローバル汚染
Promise（今後は、async/awaitも）
map / reduce
XSS（クロスサイトスクリプティング）

つまりは「責任持てるかどうか」

こういうことを書いて**「素人はJSに手を出すな」とかを言いたいわけではない**のです。勉強のため、自分のスキルアップのため色々カスタマイズにトライされるのは素晴らしいですし、どんどんやっていただきたいと思います。

ただ、これを業務で使うシステムでやっている場合は、話が別です。上にも書いた引き継ぎの問題や、引き継ぎはない環境だとしても、1年後に自分のコードを見たときに理解できるか？書いたコードが問題を起こしたときに、自分で責任を持てるかどうかが、業務で使うコードを書くときの重要な観点だと思います。

Cybozu Developer Networkに載ってたコードをコピペしたのでわかりません

では、業務で使用するのは怖くて仕方ありません。（ちなみに、Cybozu Developer NetworkにTIPSとして掲載されているサンプルコードは本当にサンプルコードで、我々プロの目から見ると怖いコードがいくつかあります）

最近、そういうケースをちらちら見るので、老婆心でこういうことを書いてしまいましたが、つまりは gusuku Customine 使えということです(^o^)（最後にステマ^^; ）

だって、こうなんだもん（笑）

gusuku Customineを使うかどうかは別として、安易なカスタマイズは結構危ないので気をつけようねというお話でした。