この記事はミライトデザイン Advent Calendar 2021の4日目の記事です🚀
昨日は＠Nyokki 大先生のMySQLのEXPLAIN ANALYZEの読み方を勉強したよ という記事でした！
皆さん読みましたよね！？
なんでお前がミライトデザインのアドベントカレンダー参加してるんや！？って思うかもしれませんが
エントリーは自由です、社内外の人たちと盛り上げていきたいです。
って書いてあったし、@hirodragon112ファンなので参加しましたｗ
さて、何を書こうか迷っていましたが、ミライトデザインといえばPHPってイメージが強いのでPHPネタということでXdebugのことを書こうと思います。
最近の若いエンジニアはXdebug使わないし、知らないらしいのでXdebugの紹介を簡単に書いてみます。
(もしかしてPsySHあるし、そんなに需要なくなってきたりしている？）
Xdebug is 何？
公式サイトによると
Xdebug is an extension for PHP, and provides a range of features to improve the PHP development experience.
つまり「debugは、PHPの拡張機能で、PHPの開発環境を改善するための様々な機能を提供します。」とのことです。
(ありがとうDeepL)
様々な機能というのは主に以下の5つになります。
- Step Debugging
- Improvements to PHP's error reporting
- Tracing
- Profiling
- Code Coverage Analysis
一つ一つ内容を確認していきましょう。
Step Debugging
メインの機能言っても過言ではない、ステップ実行です。
ブレークポイントと呼ばれるものをコードの行に設定するとその行でプログラムの実行が止まり、変数の状態を確認することができる機能です。
Improvements to PHP's error reporting
var_dumpがリッチになったり、エラー時にスタックトレース表示してくれたりエラーをわかりやすくしてくれる機能ですね。
最近だとフレームワーク側でデバッグツールがよくなってきているので若干恩恵を受けづらくなっている気もしますが...。
Tracing
引数と呼び出し場所を使用して、すべての関数呼び出しをディスクに書き込みます。オプションで、各関数のすべての変数割り当てと戻り値も含まれます。
どのように関数コールされているか、調査するときに便利ですね。
(ぶっちゃけ使ったこと無いです...)
Profiling
視覚化ツールを使用して、PHPアプリケーションのパフォーマンスを分析し、ボトルネックを見つけることができます。
Webgrindと組み合わせて使うのが一般的なのかな？
昔はxhprofとか使ってたけど、今だとXdebugで良さそうな気もしています。
Code Coverage Analysis
PHPUnitで単体テストを実行するときにコードベースのどの部分が実行されるかを示す機能。
これ地味に便利で、テスト漏れとか可視化されるので結構好きな機能一つです。
XdebugのStep Debuggingの良いところ・悪いところ
さて、Xdebugの機能をざっと説明しましたがかなり幅広い機能が沢山ありますね。
Xdebug入れると遅いとかいう人もいらっしゃいますが、まあちょっと遅くても堅牢ならそのほうがいいのではって思ってしまう自分です。
全部の機能を細かく説明していくとかなりの量になってしまうので、今回はStep Debugging(ステップ実行)のことについてつらつら書いていきます。
良いところ
Xdebugの一番重要な機能と言っても過言ではないStep Debugging。
ブレークポイントと呼ばれる、ソースコード上の処理を一時停止したい箇所にマークをし、実行時にブレークポイントの箇所で処理を止めて変数の中身を確認したりする機能です。
（赤い枠の右側の赤い丸がブレークポイント）
どこかでエラーが発生しているけど、よくわからない場合や、どこでこのメソッド呼ばれてるんだ？？？みたいな状況に非常に有効です。
あとは、webフレームワークを理解するときにも大活躍します。
私はXdebugがあったからこそ、Symfonyへの理解を深めることができました。
個人的に良いと思う理由は以下の二点。
- Variablesで実行時の変数を確認することができる
- Framesで実行順序が確認できる
Variablesで実行時の変数を確認することができる
実行時に処理をとめて、変数の中身を確認することが出来ます。
var_dumpやLaravelのddで十分かもしれませんが、見やすさや、見れる変数の範囲を考えるとこちらのほうが遥かにいいかと思います。
Framesで実行順序が確認できる
Frames実行時のスタックを知る事ができます。
この場合だとindex.phpから始まってProfileControllerの38行目が実行されていることがひと目で分かるかと思います。
また、各スタックをクリックすることでVariables側に変数を表示してくれます。
こういった側面があるのでフレームワークのソースコードはめちゃくちゃ追いやすいです。
とくにSymfonyみたいに抽象度の高いフレームワークだとめちゃくちゃ理解に役立ちますし、実際のプロジェクトでもソースコードの把握にすごく役立ちます。
悪いところ
- 設定が難しい。(どこが原因でうまく動かないのか原因の特定が難しい)
- パラメータの項目よくわからない。（とくにXdebug3になって変わってしまった）
- ローカルな開発環境がなく、Xdebug導入が難しい(よくある)
といったところでしょうか？
正直な話n回設定することで覚えるのでここは頑張るしかないのかなと思ったりもします。
Docker+PHPStormな環境でXdebugの設定をする
一番重要なポイントですが、大事な内容は自分のブログにちょっと前に書いています。
Docker環境でphp8 + Xdebug3を設定する
コチラを参考にしていただければと思います🙇♂️
最後に
個人的にはもっとみんなが気軽にxdebugを使ったステップ実行をする未来になればいいなと10年ぐらい思い続けています。
なにか困ったことがあれば@polidog にメンションくれればある程度はヘルプしたいと思います。
良かった気軽にリプライくださいー！
明日は@tkek321さんのAWSに関する記事です！お楽しみに！！！