5年の時を超えて

公開日:2024-12-04

この記事は Customine(カスタマイン) – Qiita Advent Calendar 2024 12/4の記事です

昨日(12/3)は、こたけさんの わったーかすたまいんちゅ/Customineでもくもく会!|こたけ|星野リゾート でした。

はじめに

2024/11/13に、[旧]顧客ごとの自動採番 その2  という記事をリフレッシュしました。

この記事は元々2019年10月に最初に書かれ、その後あまり大きな変更もされていなかった記事でして、この度5年振りの大幅リフレッシュをする事になりました。
※なおリフレッシュをする事になった契機は、チャットサポートにお寄せ頂いた 「やること」に誤記があるのでは? とのご指摘からでした。 ご連絡頂き、ありがとうございます!🙇‍♂️

今回、5年の時を超えたリフレッシュに当たり、アクションの画像などを再取得する必要もあってカスタマイズの再検証を行ったのですが、その結果アクション数が8から6に減少しました。

さて、なぜこんな事が起きたのでしょうか?

具体的にカスタマイズがどう変わったの?

実際に、画面のカスタマイズのビフォーアフターを見てみましょう。

旧カスタマイズ

まずは、旧カスタマイズを見ていきましょう。
※古い記事の画像なので、UIもリフレッシュされる前のものが多い

旧カスタマイズ
旧カスタマイズ

旧カスタマイズ

※注:この「レコード中のフィールド合計値を計算する」は誤り(ご連絡頂いた件)で、正しくは「レコード中のフィールド最大値を計算する」です。新カスタマイズでは修正されています。

 

旧カスタマイズ

●レコードが0件の時の処理の続き

旧カスタマイズ

●レコードが1件の時の処理の続き

旧カスタマイズ

新カスタマイズ

新カスタマイズ

結局のところアクションがどう変わったかというと、アクション5の条件「いずれかのアクションの実行が完了した時」で、その後の処理が一本化できたのでアクションがシンプルになりました。

ビフォーアフターで作り方が変わった理由

新旧のカスタマイズは、それぞれその当時では妥当な形で作られている筈です。
なぜこういった違いが出てしまうのでしょうか……?

我々はその謎を探るべく、更新履歴の奥地に向かいました。

そして原因が判明。

そう……!

更新履歴

条件「いずれかのアクションの実行が完了した時」は2020年9月に新たに追加された「条件」だったのです!
※注:この記事が書かれたのは2019年10月です

なので、記事執筆当時としては正しい作り方をしていたアクションでも、その後のバージョンアップにより より適切なカスタマイズ方法が出てくる事がある という事が改めてわかりました。
※注:なお、私がR3にJoinしたのは2022年7月で、入社前のこういった時系列については、あまり普段は意識する事がなかったため新鮮でした。

そういえば、他にもそういった「作り方」が変わる「やること」や「条件」ってあるよね?

はい。色々あります。さっと思いつくもので個人的に影響が大きそうだなぁ と感じているものを主観で上げてみました。
※カッコの中はリリース日時です。

「やること」だと、

なにもしない」(2021-04-08)
※「なにもしない」を使う事でアクションのフローをより柔軟に作れます。具体的な例は 「なにもしない」でなにかする で。

条件を組み立ててレコードを取得する」(2022-07-07)
※「クエリで条件を指定してレコードを取得する」へと置き換えてカスタマイズの可読性を上げられるはず

リストから要素を取り出す」(2022-05-26)
日付の範囲から日付を取り出す」(2022-06-09)
数値の範囲から数値を取り出す」(2023-02-16)
※レコード毎に処理したり、ループを実現したりと 実現できる事が非常に増えました

「条件」だと、

いずれかのアクションの実行が完了した時」(2020-09-17)
※このブログのようなケース。

リストから要素を取り出した時」(2022-05-26)
リストからの取り出しが終了した時」(2023-02-16)
※前述の やること「~を取り出す」3種と同様。

カスタマイズを見直す機会があれば、その時に処理内容なんかも見直せると処理がシンプルになったり、引継ぎなどもより楽になりそうだな~ という気がします。

冬に既存のアプリやカスタマイズの見直しをされる方も多いと思いますが、ぜひ処理構造にも目を向けてみてもらえると嬉しいです!