フレームワーク≒哲学だよねって話

ポエム IT

TL;DR

前にこんなツイートしてたの思い出して、大事だと思うのでそれをさらに掘り下げます。

つらつら書きます。

哲学とか意識高杉ワロタ

完全に人の意識的なことなので「ワロタ」案件でしょうし、

実際の技術だったり、お客さんからの請負仕事だけのときはいらないよと思われるかもしれませんが、

必ず必要なものだと思います。

正直、いわゆる「エンジニア」になるなら必須です。

特に哲学が大事になるのは、フレームワークを使う時ですね。

SymfonyのFrench感体得したい

過去に私も、SESでシステムを作っている時にStrutsなどを名前だけ借りてカオス化・魔改造されていく独自フレームワークの中で仕事をしていました。就職してたぶん4年くらいはずっとそんな仕事をしてきたのでそう思っていました。

最初にフレームワークの哲学が大事だと感じたのは、うちが元請けで業務システムを開発する時に、PHP技術者が多かったことからSymfony（当時は2.7だったかな）を選択したときです。

それまでPHP技術者といえども、Wordpressのカスタムだったり、オリジナルでも規模の小さなWebサイト・アプリを作っていた程度で、これから本格的に規模の大きなシステムをPHPでやっていこうという時に、ある程度中核をなすフレームワークの選定の必要がありました。

Cake3、Fuel、CodeIgnitor、Symfonyあたりから、うちの会社の性質・顧客層を鑑みてSymfonyを選択しました。フルスタック・大規模・ロードマップなど要件ベースでの選択です。

ですが、実際開発を始めようと、composerでプロジェクト作成をしたものの、最初はひたすら混乱しかありませんでした。

トップ階層にはBundle, Vendor, DependencyInjection……srcは……srcはどこ？

そもそも当時はDependencyInjectionさえわからない現場プログラマだったので、そこも問題ではありますが、全くフレームワークの使い方が想像できませんでした。

体得できずダサく・めんどくなった

結果から言いますと、その案件のフォルダ構成はBundle内に当該システム用Bundleを１つ作成し、そこに全部システム機能を詰め込みました。あとはTCPDFとかの必要なVendorを取ってきて、というくらいです。

SIerあるあるですが、あまり開発基盤準備に費やす時間がなかったので、プラクティスの模索の前に案件の達成が目の前にありました。 下手に使うより、この下に収める、ということだけ決めて走りきりました。

ですがまぁツケは後から回ってきまして、運用開始した後の機能追加でも、結局必要なコードを同じBundle配下にベタにベタベタ書くしかありませんでした。

Doctrineも諸事情から全く効果を発揮せずSQLは完全にビジネスロジックにベタ書き。 後から考えてみれば、既存DB構成があったうえDoctrineで推奨されない主キーなしテーブルも普通にあり、選定段階で適所ではないと判断すべきでした。

うまく構成できたのはTwigくらいのものだと思ってます。まぁテンプレートエンジンですし。 Twigの記述好きですよ。

フレームワークに委ねる

最近でもAngularで仕事をしていますが、いろいろなところで哲学的なポイントに遭遇します。

フレームワークのフォルダ構成、コンポーネント・ディレクティブの分割、ライフサイクルなど。

使用しているプログラミング言語は同じPHP、Typescript（Javascript）でも、それを使って枠組みの中で仕事をしようというのがフレームワークですよね。

その枠組みを理解して、その枠組みの「中で」要件を満たしていくこと。

そして、もっと大事なのがそこに「委ねる」ことですね。

Struts時代のように現場に合わせて魔改造していては、負債になるだけで、長期的（※）に見てだれも幸せになりません。このへんはそこらじゅうで言われてますよね。

※長期的

これがまたキモい話で、ここでいう長期的というのは、システム保守期間数年間とかではなく、システムを使って仕事をするエンドユーザ（なので私たちの業種よりも産業の次元が深くなるところ、第一次産業まで掘り下がる）でシステムを使用して働く従業員の意識、それによって発生する価値（財の部分ですね）の変遷、その変遷による当該業界・文化の変遷まで影響します。

まぁ要するに、「悪い文明、粉砕する！」ってことですね。

フレームワークの哲学ケバブ

「フレームワークの哲学」というのは、たぶん、どのフレームワークでも検討されている軸がいくつかがあります。

  • 処理の役割分担

モジュール分割、DIとかそのへんですね。

  • 実際の機能 or 開発中の取り回しのための階層構造

実際に現れるのはフォルダ階層とその名前の付け方ですね。 Webコンポーネントなんかも、この階層構造に関する各社の共通認識という感じでしょうか。

  • 「こういうのは時と場合によるので自分でやってくれ」
  • 「こういうのは世の中のシステムとして良くないのでやらせない」

これはそのフレームワーク開発者の、フレームワークの対象となる要件（Webサイトとか、大規模業務システムとか……）に対する考え方が現れてくる箇所ですね。

ビジネスロジックを書かせる範囲（Symfony2ならController、Angularならサービス、Springなら@Controller）、そのロジックを回収してランタイムにつなぐランナー（Symfonyならapp.php、Angularならmain.ts、SpringBootなら@SpringBootApplication）、とか。

やらせない方向の助力として、Linterの推奨設定とかもありますね。

フレームワークの哲学に従うメリット

哲学を理解して従うのは、結構大変だと思います。

なぜならその開発者（なりチーム）の考えを理解するということなので。実際のフレームワークのコード、そのドキュメント、コメントに全てが現れてくるとは限らないはずです。

ですが、それなりのメリットがあると思っています。

質問できる手段があるなら質問できますね。

  • いわゆる一子相伝の回避

これも、ルールの依存先がフレームワークになれば、それを使う組織に依存しなくて済みます。

チーム内でできあがるコードもそうですが、コミュニティにも相談しやすくなります。

  • ビューティフルさ

フレームワークが目指すビューティフルになるはず。

おわりに

というわけで今回は「フレームワークの哲学」を理解することの大事さをつらつら書いてきました。

同じ意識を持つ人を広げるのは大変ですが（人ごとのモチベーションポイントは違うので）、布教活動頑張っていきたいですね。

今後のブログネタとしは「ビューティフル」とか「モチベーションポイント」とか書きたいですが……気が向いたらでいきます。また長くなってしまった。