1. エンジニアの気づき - しむしむラジオ -
  2. イミュータブルでデバッグが楽..
2021-04-25 07:43

イミュータブルでデバッグが楽になった話

この番組はアプリケーションエンジニアをしている「なおしむ」が開発ネタや育成ネタなど日々の気づきを共有するテクノロジー系ポッドキャストです。
この番組では皆さんからのご意見、ご感想を募集しています。メッセージは匿名でも送れますのでお気軽に。
https://marshmallow-qa.com/naosim_#new_message

00:01
こんにちは、アプリケーションエンジニアのなおしむです。
最近、予算管理とか、そういうのを4月なのでやらなきゃいけないということで、
いろいろ考えてるんですけど、その流れで、そういうのをExcelで管理するのもいいんですけど、
もっとちゃんとしたUI上で管理したいなと思って、
最近、またGoogle Apps Scriptで、そういう予算管理っぽいツールを作ってます。
言語もGoogle Apps Scriptなので、Java Scriptで書けばいいんですけど、
メンテナンスできるようにTypeScriptで書いていたり、
あと、まあ、とはいえ、わざわざドキュメントを書いてまで作るかというと、
そこまではやらないなという気がしているので、
せめてコードを読んだときに、ある程度どういうものかがわかる状態をキープしたいなと思ったので、
設計のところはドメイン駆動設計を使って、
できるだけコードが動き、振る舞いであったり、そのドメインを示すような形で、
そこから理解できる状況というのを作ろうと思って、
ドメイン駆動設計で作っています。
実際やってみて思ったことなんですけど、
ドメイン駆動設計で作ると結果的には、
一つ一つのクラスが、わりとイミュータブルな形になっていくんですけど、
やっぱり改めて、ニューイミュータブルっていいなという風に感じたので、
今日はそれをシェアしたいと思います。
イミュータブルって何かというと、
ウィキペディアによると、
イミュータブルなオブジェクトとは、
作成後にその状態を変えることのできないオブジェクトであると書いてあります。
そうなんですけど、
それだけじゃ正直よくわかんないなと思っていて、
今回イミュータブルで作ってみた結果、
イミュータブルといっても結局、
リスト型、アレイ型であったり、
デイト型というのは、JSの場合はわりと破壊的なクラスになっていて、
いつでも中身を変更できるので、
実質イミュータブルじゃないと言えられればそれまでなんですけど、
とはいえ、自分の手の届く範囲内でイミュータブルに作っておくだけでも、
すごくいいなと思っています。
なので、いろんなところでイミュータブルに作ってほしいなという思いはあるんですけど、
これって結構人に説明するのが難しくて、
イミュータブルとは何かを説明するのは簡単なんですけど、
結局何がいいんだっけみたいなところを理解してもらうのが結構難しくて、
結構そういうものってたくさんあって、
03:01
やってる人にはわかるんですけど、
まだやってない人には全然わからないみたいな、
そういうものってすごくたくさんあって、
オブジェクト思考とかイミュータブルというものも、
何かそういうもので人に伝えるのが難しいなと思っていました。
今回ちょっとやってみて、すごく目先のメリットみたいなものが見えたので、
それを今日話したいなと思います。
なので多分これから話すことというのは、
イミュータブルにとって本質的な利点ではないんですけど、
とにかくこれぐらいのいいことがあるからやってみようよっていうぐらいには使えるので、
一ついい事例かなと思います。
何が良かったかというと、
イミュータブルに作るとデバッグがしやすいです。
どういうことかというと、
まず前提としてなんですけれども、
イミュータブルってどんなクラスかというと、
例えば、ネームという氏名にあたるクラスがあったとして、
そのクラスの中にフィールドとして、
ファーストネームとラストネームというストリングのフィールドがあったとします。
この2つの値がミュータブル、変更可能なものだとしたら、
よくあるのはセッターがあって、
セット、ファーストネームみたいにやると、
ファーストネームが変わるというようなものだとします。
このファーストネーム、ラストネームをガッチャンコした、
フルネームというゲットフルネームみたいなものを作ろうとしたときに、
ミュータブルで作ると、
このゲットフルネームというところに何が入っているかというのが、
デバッグで取得できないんですね。
できないというのはちょっと言い過ぎて、
ツールによってはできるんですけど、
ちょっと取得しづらい。
なぜかというと、このゲットフルネームというものは、
ファーストネームとラストネームを結合しないと
算出できないものになっているので、
毎回メソッドを実行しないといけないんですね。
そのデバッガーにもよるんですけど、
メソッドを実行しなきゃいけないものは、
何が入っているか計算してくれないというデバッガーもあるので、
そうなると結局このファーストネーム、ラストネームが何に入っているかというのは、
デバッグ時にそれを取得するのが結構難しいという場合があります。
それをミュータブルに作っておくと、
ファーストネーム、ラストネームというのがコンストラクターで設定されたら、
その後一生変わることがないので、
フルネームというのもコンストラクターで決定するんですね。
06:03
そもそもゲットフルネームというメソッドすらなくてもよくて、
フィールドにフルネームというフィールドがあればいい。
そうなるとデバッグの時にもフルネームというフィールドを参照すれば、
その中の値が何かというのはわかるので、
すぐデバッグのタイミングで値がわかるというのがあります。
今回私も予算管理のシステムを作っている中で、
うまくいかなくてデバッグしながら、
ここの値何が入っているんだっけみたいなのを見ながら進める時があったんですけど、
やっぱりそのタイミングで算出されるような値についても、
みんな見える、みんな値がわかるというのは、
すごいデバッグがしやすくて早いなと思いました。
なので、イミュータブルのメリットというのはそんなちょっとしたことではなくて、
もっと大きな本質的なところではあるんですけれども、
まずはデバッグが楽というのは、
エンジニアにとって目先の目標にしやすいので、
もしも何かイミュータブルというのを、
初級者の人に説明する時というのは、
ここら辺から説明すると、もしかしたら入りやすいのかなと思います。
なので、ぜひちょっとしたJSのツールでも何でも、
ちょっとしたものを作る時にも、
イミュータブルというのを意識して作ってみると、
開発が楽になっていいことがたくさんあるんじゃないかなと思います。
今日は以上です。ではまた。
07:43

コメント

スクロール