内容
伊藤淳一さんのプログラミング初心者歓迎!「エラーが出ました。どうすればいいですか?」から卒業するための基本と極意 という動画の内容を自分なりにまとめたものです。
とても分かりやすくまとまっており、特に初心者にとっては有益な情報だと思ったので文字に起こしてみました。
エラーでチェックする項目
- エラーメッセージ
-
Comment(#XXXXXX) expected, got String (#XXXXXX)
、のようなもの。 - 英語がわからないなら翻訳してでもまずは何がいけないのかエラーメッセージを見ることでちゃんと確認する。
-
- エラーのタイプ確認
-
ActiveRecord::AssociationTypeMismatch
、のようなもの。 - ネットで調べると、どういった場合におこるエラーなのかがわかる。
-
- ユーザーが操作した手順
- サーバーのログを確認して、どのような操作や画面遷移によってエラーが発生したか確認する。
- 操作とは例えば、トップページにきた、あるページをクリックした、SQLが発行された、など。
エラー画面に出てくるトレースの種類とその説明
- Full Trace
- 自分が書いたコードからgemやrailsがどのような動作をしているかを確認できる
- 読み方としては、一番下がスタートで上に向かってどんどん呼ばれていく
- 一番上がエラーが起きているところ
- Application Trace
- 自分が書いているコードに関する内容
- Framework Trace
- フレーム側のみのトレース
- あまりデバッグをする際には使わない
便利なgem
- better_errors
- Railsの標準のエラー画面よりも使いやすい画面を提供してくれる
- 併せてbinding_of_callerというgemもインストールしておくといい。
- byebug
- デバッグ実行を行うことができる。
- pry-byebug
- デバッグを行いたい部分に
binding.pry
と書くとそこでアプリの実行が中断し、パラメーターなどをpryで確認することができる。
- デバッグを行いたい部分に
デバッグの具体的な方法
- putsコマンドを利用
- 例えば、
puts params[:comment]
などをコードに記述することでparamsに渡された値をターミナルのログから確認できる - いわゆる原始的な方法
- 例えば、
- byebugを利用する
- デバッグをしたいところ(エラーが起きているところ)でbyebugと書くとそこで実行がとまり、ターミナル上から確認したい変数などの中身を確認できる
-
params[:commnet]
やparams[:commnet].class
など - byebugの機能はhelpコマンドで確認できる
- デバッガ使ってない人はbyebugを利用するといい
- ブレークポイントをつける(RubyMineなどのIDEを利用している場合)
- デバッグをしたい箇所にブレークポイントをつける
- Rubymineにある虫マークのついた実行ボタンからサーバーを起動するとデバッグ実行できる。
- console から確認したい変数などの中身を確認できる
- better_errorsで表示されたエラー画面を利用する
- 画面上にコンソールがあるので(>>と出ている部分)、そこからパラメーターの値などを確認できる
- テストコードを書く
- エラーが起きるステップをテストコードに落とし込み、エラーを再現させる。
- 実際に画面上でエラーを再現するよりも、テストコードに落とし込んだほうが「修正→再実行」のサイクルを早く回すことができる。
- エラーが起きるかを確認するためだけの簡単なアプリを別で作る
- エラーでどうしても詰まってしまった場合や、アプリ自体が巨大な場合などに行う方法。
- 別アプリとして作成しエラーが再現するか確認することで、エラーが発生する場所を特定することができる。
その他、デバッグ時に行うこと
- 自分のコードに問題がなさそうなのであればgemのバグを踏んでしまった可能性もある。その場合は、エラーに関係していそうな怪しいgemの見当をつけてgithubで検索し、issueがあがってないか確認する。併せて、Readmeやwikiも確認するとよい。
- 公式ドキュメントを読む
- エラーメッセージで検索して、質問サイトやブログなどを確認。ただし、公式ページとは違い、当たり外れがあるので要注意。
- 同僚に聞いたり、ネット(Teratail, Stack Overflow, QA@ITなど)で質問してみたりする。
デバッグの心構え
- やみくもにデバッグしない。
- まずは仮説を立ててから検証を行う。
- 「仮説->検証」のサイクルを繰り返すことで徐々に原因を絞り込んでいく。
- 新しい知見はQiitaやBlogで共有する。
- 自分と同じことで悩んでいる人たちの助けになる
- さらに良い解決策のフィードバックがもらえるかもしれない
- 時間を区切る
- 例えば30分なら30分と決めて、無理だったら誰かに聞く。誰かに聞くと一瞬で解決するケースがよくある。
補足
個人的な経験としては、どうしても詰まった場合、その日は思い切って諦めて次の日に持ち越すと意外とすぐに簡単に解決することがよくあるのでおすすめです。
また、デバッグ時に例えばcurrent_user
というオブジェクトの中身を確認したいときは、modelやcontroller上で確認したければlogger.debug(@current_user.to_yaml)
やlogger.debug(@current_user.inspect)
を、view上で確認したければ<%= debug @current_user %>
と記述すると確認できます。原始的な方法ですが自分は結構利用しています。
まとめ
自分は開発をする際は我流でデバッグをすることが多かったのですが、デバッグについてちゃんと理解する良いきっかけになりました。
動画は1時間にわたる大作となっております。実際にデバッグを行なっているデモがありますし、説明も丁寧なので是非一度見てみるといいと思います。