akippaで採用しているLaravelのデザインパターンのお話：前編
akippaのリードエンジニア村上です。
前回は、akippaの開発環境の話で小難しい話をしてしまったので、ゆるいネタにしようか悩みましたが、まだ2回目なので、今回もエンジニアっぽい内容でいかせていただきます。
2017年後半ぐらいから、akippaのバックエンドは、PHPフレームワークのLaravelを採用しております。(それまで使っていた古いフレームワークもまだ現役でバリバリ残ってますが、それはまた別のお話…)
今回は、Laravelを採用してから今に至るまでの過程と、現在採用しているデザインパターンのお話の触りだけさせていただこうと思います。
初期
Laravelを採用してしばらくは、特に厳密なコード規約は定めず、というか定められる程の知識もなく、僕も含め、チーム全員割と好きなようにコーディングしていました。
基本はLaravelの普通のMVCアーキテクチャーという感じ。
有識者の方はRepositoryパターンを取り入れたりしてましたが、特にそれをチーム全員で決めて、それで行くぜーっていう感じではなく、ホントに好きなように…。
でもそれじゃいかんよねーっていう風潮が出てきて、少しずつルールを決めていきました。
中期
前述したRepositoryパターンを全員使いましょう、とか、FATコントローラ、FATモデルにならないようにする等の目的で、Serviceというレイヤーを用意し、そこにビジネスロジックを集約させよう。で、テストコードはこのServiceに対して書きましょうね。という感じのルール？ができました。(結構、採用で色んな方とお話しさせて頂きますが、Serviceレイヤーを取り入れたりRepositoryパターンを採用したという話はよく聞きます。)
これで数年やってきたんですが、例えばServiceレイヤー内の作り方に対しては厳密なルールを敷いてない等の理由もあり、以下のような問題を感じるようになりました。
作り手によって作り方にバラツキが出る
だから開発時もどれを参考にするのが一番よいのか、コードレビュー時も何を以て指摘してよいのか困る
DBやAWS系の技術詳細にビジネスロジックが密結合しててテストコードが書きにくい
という理由だけじゃないけど、テストコードを後追いにしがちで、結果的に書かないまま放置となるケースも出てくる
そんな問題を感じ始めていたある日、僕より長くakippaに在籍してくれていて、PHP、Laravelについて社内で一番アンテナを張ってくれている業務委託のエンジニアの方がいらっしゃるのですが、その方から「コアレイヤーパターンってのを取り入れてみたいんだよねー」という提案をして頂きました。PHP業界では著名な新原さんという方の以下記事で紹介されているパターンです。
現在
一言でいっちゃうと、上記で紹介されているコアレイヤパターンのアーキテクチャーをほぼそのまま採用しています。
サンプルコードなど、詳細な内容については、次回書く後編に回したいと思いますが、このアーキテクチャを採用した事での僕が感じたメリットを挙げると
多少の個人差はあるが、大体誰が書いても大まかな作りは同じになる(良い意味で言ってる)
だからコードレビューしやすくなった(多少ボリュームあるプルリクでも…)
ビジネスロジックと技術詳細が分かれた事でテストコードが書きやすくなった
テストを書きやすくなったから、テストコードは必須だ！というルールを敷いて、そしてそれを現在全員守れている
テストコードを書く習慣がつくと、たまにテストしにくいコードに出くわすが、そういうときに、あーこれはダメな設計なんだな、って気付けるようになった
とかですかね。
後半に挙げたメリットは、実装パターンというより、テストコードのメリットになっちゃいましたが、テストコードが書きやすいというのはとても大事なポイントだと思います。
プログラムは、変更のしやすさが大事で、常に変更やリファクタリングしやすい状態にしておくには、テストコードが必要だと思いますし、
また、テストコードがあるという事実は、その対象プログラムがテスタブル、つまり適切なモジュール設計ができている等の証明になると思います。
カッコつけて語ってますが、達人プログラマーの受け売りですw
今回はここまでにしておいて、次回の後編では、今取り入れているコアレイヤーパターンを使ってのサンプルコードで、このパターンのメリットをお伝えできればと思います！
最後に、akippaでこのデザインパターンを取り入れようという提案をしてくれた業務委託エンジニアの方のTwitterアカウントを載せておきます！