以前に私はZennにて、動的型付け言語に関するポエムを書きました。
その際、型が無いと無秩序になりやすいという点や、動的言語自体の問題というよりはそれを使う側に問題があるという内容に触れました。もちろん、使う側のレベルやメンバーの知識の知識のバラツキの為に、静的型付け言語を採用することが有効なのは言うまでもないです。型に合わないような入れ方をしたら事前にコンパイルで落としてくれるし、型を見ることでそれが取りうる値も想定できます。
ただ、型を使えば実装としてそれがOKになるかといえば、必ずしもそうは言えないと私は考えています。その型に対する意味合いが明確でないと、結局その処理何がやりたいんだっけとなってしまって、最低限の秩序は保たれるものの、全体として意味が分かりにくくなってしまうことは防げないとは感じます。例としては少し極端ですが、下記の記事にあるようなJavaのコード例とかで、何も考えないと手続き的な書き方になってしまい、この処理は何がやりたいんだっけってのが分かりにくくなってしまう感はあります。もちろん、これは静的型付けにかかわらず、動的型付けにも言えることではあります。
例えばHaskellにしても上級者が高難度な型をたくさん作ってしまうと、まさに型パズルのような地獄にハマります。私も前の現場で少しHaskellを触ったのですが、この型どうやって合わせりゃいいんだみたいな気持ちになって、本来的に処理としての意味合いがよく分からなくなった気持ちにもなりました。（もちろん私のスキルが低いと言われればそれまでですが・・）
これに対する一つの個人的なアプローチとしては、意味合いを明確にすべきコアな「ドメイン」に対しては型をしっかり定義し、下記の私のZennの記事にまとめてある通り、それをモデルとして図示化できることが大事と思います。逆にコアじゃない部分に関しては無理しして型付けする必要はないと思っていて、ある程度ゆるふわでも良いかなと考えています。
今はPHPとかで、下記の記事のようにプロパティに型を付けられる機能が追加されています。Ruby3でも型をチェックできる仕掛けが追加されています。ので、動的型付け言語であっても、こういった型に関する意識は高まっています。
現在の私的な結論としては、コアなドメインに関してはしっかり型付けをし、コアじゃない部分は動的型付けでサクッと書く、というのがベターなアプローチではないかと考えています。結局何がコアになるんだというのは、きちんと業務的な重要性や概念を踏まえないと抽出できないので、第一歩は業務理解であることは言うまでもないです。メリハリをつけることで、その業務の理解が浅い人もコアな概念を押さえるところから始められるので、注力して見るべきところに集中できるのではと感じます。
