やる気がストロングZERO

やる気のストロングスタイル

リファクタしてて「やっぱ静的言語はいいよなぁ〜」と思った件

DDDの実践練習として作成している趣味プロダクト(Go言語)で、ちょっと設計をミスったのでリファクタをした。
リファクタ内容は「2つのエンティティとして扱っていたものを、1つの集約として扱うようにする」。

エンティティはシステム内で広く使われるデータ型なので修正範囲が結構大きかった。

作業風景をyoutubeにアップしてて、以下の「契約管理システムを作る #115」から「#122」くらいまでがその作業にあたる。

youtu.be

なんとかリファクタ完了して「やっぱ静的言語はいいよなぁ〜(respect 志村けん)」と思ったので書いてみる。

ビルド時エラーが対応必要リストになる

とりあえずエンティティを変更すると、ビルドが失敗しまくる。

一気に大量のタスクが押し寄せるので精神的に「うっ、、」となるけど、対応すべき箇所がリストアップされているのと同義なので淡々とこなしていけばいい。
これが動的言語だったら(実際は動的言語だったら、というよりデータの扱いの設計によると思った※下記します)変更が必要な箇所を自分で(もしくはIDEの静的解析機能で)洗い出ししなければならず、もし漏れたら実行されるまで漏れている事に気がつけない。

「もう対応漏れはないか」の確認にかなりのコストを払うんではないかと思った。

動的言語が悪いのか?

動的言語が問題なのではなく「動的言語で組まれたシステムはデータをざっくりと扱いがち」なのが問題なのだと思った。

今回DDDを参考にアーキテクチャ設計をしているのでシステム内で扱うデータをきっちり型で定義している。(これがエンティティ)

一方、動的言語で組まれたシステムはシステムで扱うデータが型として明確に定義されず、配列や辞書データでなんとなく持ち回っているパターンが多い。
扱うデータを型で定義しないから、場所場所で微妙に違う形でデータを扱ってる。(一見似たようなデータだが、ある場所では1つ2つ項目が多い、等)
今回のようにあるデータの扱いを変えようとしたところで、似たそのデータ全てを手動で対応していかないといけない。
また、データの内容が似ているからといって同じく変更してもよいかどうかはその文脈や処理によったりするので、前後のロジックを確認する必要があったりもする。

一つでも対応が漏れたらバグになる。結構きつい。。

動的言語でもしっかりアーキテクチャ設計をして、扱うデータを意識して設計してやってたらそこまで差はない気がする(静的解析も効きやすいし)

しかしそこまで型を意識してやるなら静的言語をつかったほうがやりやすい。
動的言語のメリットが活きるのはこういう事をする場合では無い気がする。