これを読みました。
Twitterで流れてきたので。
オブジェクト指向が廃れる理由。フロントエンド向けAPIの提供とデータの読み書きが主たる役割になったサーバーサイドは、オブジェクト指向の強みが薄れる一方で、並行性とミュータブルな状態共有の辛さは残るため、OOPよりFPのほうがウェブと相性がいい。という主張。 https://t.co/ja6x2ad3eX
— ❄️suin (@suin) June 19, 2018
フロントエンドとの分担によってバックエンドもといサーバサイドに求められる要件の性質は変わってきているので、オブジェクト指向じゃないのもやっていこうぜ、って感じにユルく受け止めています。
フロント／バック分担はレイヤー化のひとつ
と考えておいて差し支えないかな、と思います。
WebAPIが最終的なエンドポイントになるようなアプリケーションもあると思いますが、業務システムのようにフロント〜データベースまでして一貫して作成されるようなものの場合は、レイヤーの１つであるといえます。
ネットワークを挟んでる、という意味ではデータベースとアプリの間にもあります。
ということでここからは「レイヤー化」で考えます。
レイヤー化によるメリットとして、「関心事を減らして、レイヤー内の実装に集中できる」ということはよくいわれます。
関心事減るの、めっちゃ好き
です。
大きく理由が２つ。
脳のリソースを余計なことに使わない
プログラムを記述する一つ一つの所作が、アプリケーションの挙動に影響を与えるわけですが、この影響範囲を考える際の負担が全然違います。 枝葉が伸びるほど、影響のパターンはねずみ算式に増えていきます。
その計算負荷を必要最小限の範囲に止めることで、一つ一つのプログラム記述の負担が減ります。
また、影響範囲が少ないということは、１つの変更のために複数箇所を修正する必要のある場合が減るので、コミット単位も小さくなります。 これはプログラマの心理的な安心感をもたらします。
デグレなく変更が完了するまでに何日もかけ、数十・数百行にも及ぶコミットをいっぺんに行わなくて済む、ようになるかもしれません（場合によりますからね！
作業の区切りや見積もりも行いやすくなります。作業把握ができることによるマネージャの安心感にもつながるかもしれませんね。
レイヤー毎に異なる非機能の品質の確保
影響範囲が増えるとき、単純に枝葉が遠いことによってパターン数が増えるだけでなく、その性質もレイヤーごとに違ってきます。
例えば、フロントエンドのクライアントアプリケーションではユーザにデータが見える順番など、UI/UXを気にする必要があります。
中心部分になるトランザクションからは逃れることはできませんが、ドメインデータを複数のテーブルに分割する際の整合性や、登録日時・更新日時などテンプレート的なデータ設定などは、リポジトリレイヤーに都合のいいようにすることも必要になります。
前の記事にも書きましたが、非機能要件はリファレンス的なものだけで済まず、ノウハウ特化になってくるので、経験が豊富な方が安心感があります。
知見のある人を適切なレイヤーの中心人物にすることで、本人たちのモチベーションにも、マネージャから見ての信頼性も確保できます。
分割する能力について
レイヤー化を適切に実現するには、分割をまず考える必要があります。
一つの情報があったとき「これはどのレイヤーが主導権を取るか？」というのを見極める必要があります。
そういった「諦めずに考える／分析する」ことが必要になってくると思います。
私自身できるかどうかはわからないので、ここでは、ここまで。。。
分割する負担について
レイヤー化をすることで関心事は減りますが、レイヤー間のつなぎ部分、いわゆる変換コードはある程度のボリュームで出現してくると思います。
これを、「どこまでを是／どこまでを否」とするかが、システム要件によって異なってくると思います。
ちなみに私は先ほどの理由から、関心事が減ることの方が大好きです。
「変換コードに集中できるやん！変換コードとして完成させれば完了やん！」ということで、コードの量というもの自体は増えますが、システムとしての安心感／メンバー・運用者の安心感、を得るためには苦にならないコストかな、と思います。
関心事を減らして、毎日うまい酒を飲もう
関心事が減る一番いいことは、「日々前進しているモチベーションが得られるようになる」ということかもしれません。
プログラムの開発単位を小さく・シンプルにしていくことで、毎日「終わるかなぁ、できるかなぁ」という不安を抱えたまま眠らなくて済みます。
毎日「今日も終わったから酒飲むか！」という感じでやっていきたいですね。
こちらからは以上です。
