結論
10,000行以上ならドメイン駆動モデルによる静的言語。
10,000行以下ならMVCモデルによる動的言語。
注意
とても乱暴な数字ですが、イメージをつけやすくするために
10,000行とする考えを採用させていただきました。
表1.結論
項番 | 項目 | 静的 | 動的 |
---|---|---|---|
1 | 開発速度(大規模) | O | X |
2 | 開発速度(中規模) | O | O |
3 | 開発速度(小規模) | X | O |
開発速度としては、つぎのような感じで場合分けして軍配があがります。この人の記事は、使い分けも、含めて書いてくれてるのでありがたいです。
という風に使い分けてもいいんじゃないでしょうか。
Python と Java で AppEngine アプリを開発してみて - present
で、実際作り込みってどれくらいなんだろ(´・ω・`)
僕の立場を書くと、動的型付言語にメリットはあると思う、しかし構築するシステムの規模やチーム規模が大きくなるにつれてそのメリットよりデメリットが大きくなる。そしてそのメリットとデメリットのが反転する規模の分岐点は(常人が思っているより恐らくは)小さい、というものだ。具体的には10K行程度。
静的型付言語/動的型付言語のメリット/デメリットについて考えてみる - think and error
理由
規模が大きくなると静的言語のほうが有利になる理由は、
規模が大きくなるに従い...
2. 動的言語は、テストしずらくなる。
3. 動的言語は、リファクタリングしずらくなる。
6. 動的言語は、MVCのモデルが肥大化し、メンテナンス性がさがる。
から。
各論
表2.各論
項番 | 項目 | 静的 | 動的 |
---|---|---|---|
1 | 実行速度 | O | X |
2 | テストのしやすさ | O | X |
3 | リファクタリングのしやすさ | O | X |
4 | 可読性 | X | O |
5 | ドメインモデル 対応フレームワーク |
O | X |
6 | MVCモデル 対応フレームワーク |
X | O |
2. テストのしやすさ
そして静的型システムは、動的型システムよりもテストの記述を少なくしてくれる。以下ではそれを示そう。
静的型付言語/動的型付言語のメリット/デメリットについて考えてみる - think and error
と、記載されているところ、以下の文章を読んでください。長いので引用は控えました。
3. リファクタリング
リファクタリングって何?
リファクタリングにありがちな誤解を解く
リファクタリング (プログラミング) - Wikipedia
動的言語で Python 使ってますが、確かにリファクタリングしづらいかも。
データ構造を書き換えて大幅にコードも書き換えようとするときに、困りはしないけど不安になる。型が明示されてないものだからエディタ, IDE が補完してくれない。補完してくれないからこれで正しいのかな.. と。
Python は 3.5 以降、確かに型アノテーションが出てきたけど、vim の開発環境ではいい感じに補完してくれない。Pycharm ではやってくれるのだろうか...
4. 可読性
Ruby, Python を念頭に基本的には動的言語に軍配をあげたいと思います。理由は Ruby, Python ともに言語の設計思想として、プログラミングすることの楽しさ、読みやすさを理念に据えているからですし、実際に自分もそのように感じています。
この記事面白かったので(´・ω・`)つ
Rubyの生産性の高さはどこまで本当か? - 分裂勘違い君劇場 by ふろむだ
6. MVCモデル
Model -> Controller -> View の3層構造です。Java の Slim3 のように静的な言語で強く MVC に沿う静的言語のフレームワークもあるようです。
- Java ... Slim(GAE)
MVCモデルで規模が大きくなっちゃうと
ただ、それを忠実に実践していった結果、モデルが肥大化し
Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)
メンテナンシビリティやテスタビリティが低下する
という問題も多く指摘されています。
Django(Python) での対処の仕方。Service Layer みたいなのを作ってあげて、モデルをラップしてあげる。もちろん暫定対処で、ほんとうに大きくなったら、Spring とかへの移行を考えたりしないと行けないのかな...どうなんだろ。python - Separation of business logic and data access in django - Stack Overflow
from library.models import Book def get_books(limit=None, **filters): """ simple service function for retrieving books can be widely extended """ if limit: return Book.objects.filter(**filters)[:limit] return Book.objects.filter(**filters)
補足①
動的言語=MVCモデル, 静的言語=ドメイン駆動モデルという訳ではないのですが、動的言語の有名なフレームワークはMVC モデルに、静的言語のフレームワークはドメイン駆動モデルに沿うことが多いような気がするため、このように表記しています。
ドメインモデルに分類したフレームワークであっても、MVCモデルのように記述することもできます。例えば、Spring には Spring MVC という機能があります。また、MVCモデルのように分類したフレームワークであっても、リンク先に書かれているように Django, Rails もドメインモデルのように記述することができます。
Webフレームワーク比較してみた - やさしいデスマーチ
補足②
Ruby にオプショナルで静的型付を検討したこともあるようですね。一緒に Python についても書かれたリンクもあります。
やっぱ将来Rubyに静的型は導入するのやめようと思った。 たとえオプショナルでも。| Matzにっき
型アノテーション
結局ウェブアプリも大規模化してきて、型を明示するような流れになりつつあります。この記事は死ぬほど面白かったです。
注意してほしいのは、ここでいう型宣言の需要は、人間のために書く、ドキュメントとしての型アノテーションで、コンパイラに効率よくランタイムを生成してもうらための型ではありません。これを混同している人が多いですし、「高水準な、良く設計されたプログラミング言語」はそれらを区別せずにプログラマに書かせようとしてきます。(Rust などは低水準を目指しているので明示的に区別します)
ttp://mizchi.hatenablog.com/entry/2018/07/05/180219