はじめに
この記事はSymfony Advent Calendar 2019 25日目の記事です。
こんにちは、きゅ〜ぶです。
スタートアップでSymfonyベースで作られてるEC系の自社アプリケーション開発のエンジニアをやってます。
Symfony歴が2ヶ月半の若輩者ですが、一人でSymfonyを使って新規機能の開発やリファクタリングをする際、意識していることを書こうと思ってます。
あくまで個人的なやり方なのでもっといいやり方などあればご教授いただければと思います！
前提
○画面でどういう操作をしたらその機能が実現できるかを理解している。
→要件の理解ができていること。
○あくまで自分の個人的な経験に寄る知見であること。
Symfonyでデバッグする際は、dumpを使おう
以下公式ドキュメントを見たらだいたい使い方は載っております！
How to Dump Debug Information in Twig Templates
自分は最近ぶっちゃけデバッグする際、dumpよりXdebugを使うことが多いんですけどね・・・
一応今は、PhpStormとVirtualBoxを使用して開発しててその際、Xdebugの環境を作った時の記事を以下にまとめてあるのでこちらももしよければ参考にしてみてください。
PHPStormでVirtualBoxのサーバーと連携してリモートデバッグ(Xdebug)の設定方法
Twigの特定
まずコードを追う為のきっかけを見つけるため、画面ベースで関係する部分の洗い出しを行います。
Symfonyは、Twigというテンプレートエンジンを使用しています。
なので画面表示はTwigで行なっています。
まず登場人物として出てくる対象のTwigを探します。
コツは、画面に表示されている文言の中でもぱっと見少なそうな文言をプロジェクト内で検索することです。
(デベロッパーツールとかも駆使していくとよりいいです)
→検索数が少ない文言のが特定が楽にしやすい。
Twigでのデバッグ
{{ dump(変数名) }}
これで変数名の中身を見ることができます。
Controllerの特定
Twigが特定できたら次はどのControllerが動いているかを特定します。
基本的に作りとして画面遷移やボタン操作などのアクションを起こす際、Controllerが動く形になってます。
うちは、routing.ymlでpathとcontrollerを管理してるため、先ほどの対象の画面を表示しているTwigの画面URLに紐付くものを探せばどこのBundleのControllerを使用しているかが特定できるかと思います。
Controllerでのデバッグ
dump(変数名)
これで変数名の中身を見ることができます。
Xdebugならブレークポイントを貼ればそこで止まるのでControllerの先頭にブレークポイントを貼ったりします。
DB周りの特定
あとは大きなところで言うとDB周りの特定が鍵になってくるかと思ってます。
うちは例えば以下みたいな感じで使用しています。
->getRepository('xxxBundle:Test')
->createQueryBuilder('t')
->andWhere('t.status = :status')->setParameter('status', StatusType::START)
->andWhere('t.store = :store')->setParameter('store', $a->getStore())
->orderBy('t.orderedAt', 'ASC')
->getQuery()
->iterate();
get Repository()をしているところを探してこれだとTestって言うテーブルが使われていて条件としてstatusがSTARTのStatusTypeのものとstoreが$a->getStore()でASC順で並び替えた情報を取得してます。
ここで実際phpMyAdminの方をみて対象DBを見たりしてだいたいどんな情報が入ってるかなど把握できます。
終わりに
個人的に以下4つが分かればだいたい新しい機能実現の実装には困らないかなぁと個人的には思ってます。
・要件(やりたいこと)
・機能実現に関係する画面
・機能実現を行うController
・機能実現に関係するテーブル
拙い文章でしたが最後まで見ていただきありがとうございました！
仕事で今後もSymfonyは触っていくのでまた知見の共有などは定期的に行っていければと思います。