俺の設計：設計は言語 > フレームワーク >= ソフトウエアアーキテクチャ

まえおき

そんな大したものではないけど、自分なりの設計のやり方みたいなのを整理して文書化したいなみたいな気持ちがある
無意識で良しとしてやってることが多すぎるので

— やんく✌('ω')✌ (@yy_yank) March 23, 2024

というわけで「俺のプログラミング」シリーズです。 自分が何を大事にしてプログラミングをしているか、自分でもよく分かってないので思いついたものを書いていく予定です。 今回は言語とフレームワークとソフトウェアアーキテクチャについて。

言語には向き不向きとトレードオフがある

言語って大事で、言語によって向き不向きがある。トレードオフもある。

コンパイル速度、実行速度、エコシステム、言語機能、イディオムなどなど。

バックエンドは何使ってもかける

バックエンドは言語はなんでも使えると言えば使える。

RubyでもJavaでもRustでもTypeScriptでもGoでもJavaScriptでもPHPでもPerlでも。

どの言語でも、結局書けてしまうと言えば書けてしまう。

書け！と言われたり、書こう！となったら出来ないことはない。

モバイルアプリは何使っても書ける、がハードルは高まる

例えばAndroidならKotlin、Java。iOSならSwiftみたいになる。 けど、GoでAndroid書いている人もいるし、React Nativeとか、flutterとか使ったりクロスプラットフォーム対応なものを使ったりする人もいる。

ただ、ネイティブ対応な言語よりはハードルは高い。 Goがめちゃくちゃ好きで、AndroidもGoで書きたい！みたいな気概、熱意が求められる。折れない心さえあればその技術選定もアリだと思う。

クロスプラットフォーム対応のものも流行り廃りが4〜5年ぐらいのスパンである気がしていて、 取捨選択や追従が出来る企業、メンバーに限られるのかなと思う。

したがって、モバイルはネイティブアプリを実装できる言語を使うかクロスプラットフォームな技術の船に乗るか、の選択肢になりそう。 一番の安牌はネイティブアプリを作れることだろうか。 結局クロスプラットフォームなものでも突き詰めるとネイティブ実装をするシーンもよくあるし。

フロントエンドも何使っても書ける、がハードルは高まる

フロントエンドに関してもざっくりいうとTypeScriptとReact一強みたいになっている。 でもReasonのようにOCamlだったり、ScalaやKotlinやClojureでAltJs書いたりとかハードルの高い選択肢もある。 これについても同様、気概、熱意が求められる。折れない心さえあればその技術選定もアリだと思う。

デファクトスタンダードを敢えて踏み外す勇気はあるか

気概、熱意がある人はかなり限られているので、大体の人はネイティブ対応言語やデファクトスタンダードな方をフロントエンドやモバイルでは選ぶ。それは僕自身のスタンスとしてもそう。
たまたま変な気概、熱意を持った人がたくさんいる企業とかでない限りはそういう選択肢になるだろう。

もしくは、趣味プロジェクトやとても小さい業務プロジェクトであれば、ハードルの高い選択肢を選ぶのまた一興、という感じもある。ただ、業務で使うと引き継ぎが面倒になるため、あまり現実的ではないなという気もする。

つまりフロントやモバイルは専門性がカギ

上記の前提から考察すると、さまざまな選択肢は無いので、フロントやモバイルは広さよりも専門性が問われるかもしれない。

コアになる言語は熟知しておいて損はないはずだし、フレームワークやライブラリなどは全てを把握・理解することは難しいので理解度や実践レベルに個人差が出る。そうすると各フロントエンジニア・モバイルエンジニアの強みや特徴が現れるポイント（差別化ポイント）になるのかなと思った。

何が言いたいかっていうと、フロントやモバイル詳しい人ってどこ行っても通用するんでは？みたいなこと。

言語>フレームワーク>=ソフトウェアアーキテクチャ

ということで、今回の内容は特にバックエンドに関して言及する感じになる、のかも。

自分が思っているのは、言語が一番コアであるということ。一番大事。

その後にフレームワークが来る。ソフトウェアアーキテクチャはそれに付随するオマケぐらいに思っている。

なので、レイヤードアーキテクチャとかオニオンアーキテクチャだとかそういう構造を考えたりインターフェースの使いどころを律するような手法が中心となる考え方は実はあまり好きではない。

フレームワークやソフトウェアアーキテクチャに踊らされない

自分の感覚としては、言語やフレームワークの強みを最大限活かすのが良いのであって、ソフトウェアアーキテクチャに縛られると良くないと思っている。

時にその強みを押し殺して無個性化する時が発生しているのではないだろうか。

逆を言えば、どんな言語、フレームワークであっても普遍的に採用できるのがソフトウェアアーキテクチャなのかもしれない。そこに全く重要性がないとも感じていない。
フレームワークとソフトウェアアーキテクチャのトレードオフみたいなものがあると思っている。
どちらか一方を優先しすぎると、旨味が消えてしまう。

言語を熟知して、それぞれの強みを上乗せする

言語、フレームワーク、ソフトウェアアーキテクチャにチームや自分の強みを上乗せする。
それが出来るような選定をするというのが大事。

前提として、言語を理解しておくことが最重要。
その言語の上にライブラリやフレームワークも機能実装も成り立っている。

理解した前提の上で、チームや自分自身が最もやりやすいフレームワークやソフトウェアアーキテクチャの組み合わせを取る、というのが正しい向き合い方、正しい選定だと思う。
言語を熟知していないと結局選定もブレやすい。

言語を熟知して、フレームワークとソフトウェアアーキテクチャだけに集中する

ということで、ここまで書いてきたように自分は言語がど真ん中だと思っている。 そして、その言語をしっかりと習得してしまえばフレームワークとアーキテクチャの選定や使い分けの意識だけになる。 もっというと、フレームワークやアーキテクチャも使いこなすと、思考の際のノイズはかなり少なくなる。 本質的な設計やユースケース、拡張性、運用をどうするかなどに集中できるという感覚がある。

全てを身につけて、習熟した先には言語もフレームワークもソフトウェアアーキテクチャも無意識となり、 どうでもいい世界になる。最終的にはビジネスだけに集中してモノをつくる、みたいなのが自分の理想だったりする。 この感じが伝わるかはわからないけど。