Laravel
coding
Tech DoDay 15

Laravelにおけるサービスコンテナとコードの美しさ


はじめに

ここ1年間PHP+Laravelプロジェクトに携わっててやっと気づいたことについて語ってみたいと思います。

珍しくコードの美しさについてです。


Love beautiful code?

Laravelの公式ホームページに接続すると、画面の真ん中に


”Love beautiful code? We do too.”

“The PHP Framework For Web Artisans”


って文言がポンと表示されます。それを少し言い換えてみると

「美しいコードで物をつくりたいウェブ職人のためのフレームワーク」

という意味になるでしょう。

初めて見たときは、ふつうに考えると、Powerful・Rapid・Smartなどの形容詞でフレームワークの凄さを誇るわけだけど

(もちろんスクロールダウンするとすぐに出てきます😅)

「あなたも美しいの好きでしょう?」と同意を求めてる文言って斬新だなーと思いました。

当時はそんなに気にならなかったですが、最近になってどんな意図を持っているのか知りたくなりました。

多分、今ソフトウェア職人()という本を読んでいるので、そこからの影響があったと思います。

コードの美しさって美しい風景を眺める時のようにアプリの設計から似たような体験できるからかと思い、

改めてドキュメントの設計コンセプトを読んでみました。


サービスコンテナ

サビースコンテナはLaravelアプリケーションを構成する概念、あるいは実装したそのものです。

Laravelが起動したらアプリ自体もコンテナとして扱えるので、Laravelはコンテナの集まりと言っても過言ではないです。

サービスコンテナは、名前通り特定のサービスに関わるビジネスロジックを含むクラスです。このサービスコンテナはサービスプロバイダによってアプリ起動時に登録され、

必要に応じて呼び出されてインスタンスが生成されます。これをかっこいい表現で依存性の注入(Depedency Injection)と言われています。

開発者は自分は書いてもないのに勝手に生成されるインスタンスを受け取り、活用するだけで済みです。これのことを制御の逆転(Inversion of Control)と言います。

まさにインスタンス生成の面倒さ・怖さからの開放ですね。

本書では具体的なサービスコンテナの使い方については記載しないので、詳しくはこのリンクを参考にしてください。


美しいコード

ということでService Containerについては分かりましたが、サービスコンテナを使うことで美しくなりますか?と聞かれると、

まずはコードの美しさとはなんなのか認識を合わせる必要があると思います。はっきりとは言いにくいですが、私が考える美しいコードの以下のような特徴を持ってると思います。


  1. 人が読みやすい

  2. 適切にモジュール化・抽象化されている

  3. 重複コードがない

IT業界の古典であるClean Codeの内容をまとめると似たような結論に至るのではないかと思います。

上記の特徴を持ってることでそれぞれ


  1. ロジックが理解しやすい

  2. 修正・拡張する箇所がはっきり見える

  3. メンテしやすい

という長所を得ることができます。

だからそれのどこが美しい?というと、人によって感じることが様々な芸術に比べてプログラムというものは同じ入力に対して同じ出力をだせないといけないわけです。

しかも一人でサービスができるウェブアプリはほとんどなくて、一人でやってるとしても、過去の自身が残したコードのせいで苦労する経験は開発者ならありますね。

またプログラム、特にウェブアプリケーションはユーザとのケミストリーが大事で、世の中の変化に応じて能動的に変化しないと価値を失ってしまいます。

コードの美しさとは抽象的なものではなく、その品質を担保しようとしてる行為だと思っています。

そのため、サービスコンテナなどの手法が生まれてきて、そこからコードの美学を感じるのではないかと思います。


どうでもいいじゃない?

私は「むしろそういう無理矢理入れようとして正反対に複雑な構造になってしまうのでは?」と思ってた時期がありました。

また「デザインパターンってただGeekな人たちの言葉遊びじゃないか」と思ったこともありましたが、

構造化せず、整理せず書いたコードはサービスコンテナを理解するより難しくなってしまうんだと肌で感じました。

もう少しでもコードを美しいコードを意識しながら書いたコードは人を喜ばせるし、品質までつながるのではないかと思います。


たまには美しくないコードが美しい時がある

もちろん心が折れそうな場合も多いですね。

ハードコードしてしまったり、設計する間もなく実装に追われて、リリースしてしまったりとか。

それはそれで理由のある対応なので、全然やる気失う必要はないです。

とにかく忘れてはいけないのは我々がつくるものはユーザの要件を満たすこと。

が、二度とそんな状況にならないように見直すことも大事ですね。


終わりに

残念ながら、ここ1~2年間書いたコードは恥ずかしくてたまらないくらいです。

やっといろんなカンファレンスに参加したり、本読んだり、周りにアドバイスをもらったりして

ソクラテスの言葉通り「知らないことを知っていると思い込んでいる」状態になったのかもしれません。

これからはせっかくLaravelの使っているので、LaravelのIlluminateのコードをちょっと読んでいこうと思っています。

Laravelぐらいの立派なものを磨いている人たちのコードを読んだらきっとレベルアップできますね。

けっこう文系感のある記事になってしまったんですが、

とにかくコードをきれいに書こうとする姿勢から生じるトレードオフはないと思うので

実践しながら少しずつでも成長できたら良いなーと望んでみます。