面接前日の1枚まとめ

フレームワークを使う理由

認証・ルーティング・DB操作など、どのアプリでも要る土台を毎回作らず、本質的な価値の部分に集中するためです。車輪の再発明を避け、チームで共通の書き方に揃えられるのが利点です。

MVC

リクエストの受付(Controller)、データと業務知識(Model)、表示(View)を分けて、変更の影響範囲を局所化する考え方だと理解しています。役割が分かれているので分担とテストがしやすくなります。

規約より設定(Convention over Configuration)

命名やディレクトリの規約に従えば設定を書かずに動く、という思想です。全員が同じ場所に同じ名前で書くので、初見のコードでも迷わず読めるのが大きい、と説明します。

Fat Controller問題

コントローラに業務ロジックを詰め込むと、テストできない・再利用できない・読めない、の三重苦になります。コントローラは入口の交通整理に徹するべき、と考えています。

サービス層

「申込を確定する」のような業務手順はサービス層に集約し、コントローラから呼ぶだけにします。同じ処理を複数の入口から再利用でき、単体テストもしやすくなるからです。

FormRequest

入力チェックはFormRequestに分離します。コントローラが本処理に集中でき、バリデーションのルールも一箇所にまとまって再利用・見通しが良くなるためです。

Eloquent(ORM)

DBの行をオブジェクトとして扱えるORMです。SQLを直接書かずに関連データも辿れて可読性が上がりますが、便利さの裏でN+1が起きやすい点は意識しています。

N+1問題

一覧を1回取ったあと、各行の関連を都度取りにいって発行クエリが件数分増える問題です。100件なら1+100=101本になります。気づき方はDebugbar等で発行SQL本数を見ることです。

Eager Loading(with)

関連を事前にまとめて読み込み、N+1を2本に抑える手法です。まず関連を一括取得しておくのが基本、と説明します。

インデックス

検索や結合で使う列に張って絞り込みを速くします。ただし書き込みは遅くなるので、闇雲でなく実際のクエリを見て必要な所に張る、というスタンスです。

マイグレーション

DBスキーマの変更をコードで版管理する仕組みです。チーム全員が同じ手順でスキーマを再現でき、巻き戻しもできる。手作業でのDB変更を避けられるのが要点です。

トランザクション

複数の更新を「全部成功か、全部取り消し」にまとめる仕組みです。在庫を減らす処理と申込作成のように、片方だけ成功すると壊れる場面で必ず使います。

悲観ロック / 楽観ロック

競合をどう防ぐかの二択です。先に鍵をかけて他を待たせるのが悲観ロック、更新時にバージョンの食い違いを検知してやり直すのが楽観ロック。競合頻度で使い分けます。

冪等性

同じ操作を何回実行しても結果が変わらない性質です。二重送信で申込が二重登録されないように、キーで重複を弾く設計を意識します。

PSR-12 / コーディング規約

書き方を標準に揃える規約です。差分がスタイルでなくロジックの変更に集中でき、レビューが本質に向くのが利点。整形は自動化して人手で議論しない、と考えます。

Gitフロー / PR

作業はブランチを切り、Pull Requestでレビューを経てから取り込みます。コミットは意味の分かる粒度で刻み、レビューしやすい小さな単位を心がけます。

コードレビューで見る点

設計の妥当性・可読性・テストの有無・セキュリティを見ます。指摘は人でなくコードに向け、理由を添えるようにしています。

テストを書く意味

動作の保証と、変更で既存が壊れるリグレッションの防止です。仕様がテストとして残るので、安心してリファクタや機能追加ができます。

.env・秘匿情報

APIキーやDBパスワードは.envに置き、Gitに含めません。環境ごとに値を変えられ、コードは設定を直接持たない、という分離が目的です。

実装はAIに任せられる前提での人間の価値

コードを書くこと自体より、要件を設計に落とす判断、AIの出力をレビューして良し悪しを見極める目、詰まったときに切り分けて自走する力に価値があると考えています。

未経験だがどう学んだか

作れることより「なぜその設計か」を説明できることを目標に、悪い例と良い例を対比しながら理解を進めました。用語も面接で使える言い換えまで落とし込んでいます。

詰まったときの動き方

まず現象を再現し、原因を一つずつ切り分けます。エラーメッセージと発行SQL・ログを見て仮説検証する、という順序で進めます。