どうも、ウェブ系ウシジマくんです。
さて、プログラミングをやっている時に、想定した挙動にならなかったり、エラーになったりして詰まることってありますよね。
その際、Googleで検索すると思いますが、一向に問題解決できない時ってありませんか?
Twitterで次のようなツイートをしたところ、多くの方に反応をいただいたので、同じように困っている方が多いようですね。
ライブラリなどを使っていて、挙動を知りたくなったら、何時間もかけて日本語の解説記事を探すよりも、
✅公式リファレンス
✅Issue
✅ソースコードを追っていくのが一番手っ取り早い。
「コードがムズい」と思うかもしれませんが、そんな時こそ認識あっているか有識者へ質問してみると良いかと。
— ウェブ系ウシジマくん@リモート専門エンジニア (@web_ushizima) July 26, 2019
ということで、今回は「プログラミングで詰まった時に問題を解決するためのググりかた」をテーマを取り上げたいと思います。
ググる時にはヒットしやすいキーワードに選定する
ググってもうまくエラーが解決できない時の要因として、エラーメッセージをそのまま検索していることがあげられます。
特に、検索キーワードにファイルパスなども含めてしまっている場合は、その傾向が顕著ですね。
というのも、エラーメッセージと共に表示されるファイルパスというのは、基本的に実行環境ごとにユニークなはずなんですよね。
では、どうしたらいいのか。
具体的な例をあげて説明しましょう。
例えば、railsのActiveRecordを使ってDBを作成するコマンドbundle exec rails db:createを実行した際に、次のようなエラーが出たとしましょう。
Access denied for user 'root'@'localhost' (using password: YES)
Couldn't create 'hello_world_rails_development' database. Please check your configuration.
rails aborted!
Mysql2::Error::ConnectionError: Access denied for user 'root'@'localhost' (using password: YES)
/Users/web_ushijima/git/hello_world_rails/vender/bundle/ruby/2.5.0/gems/mysql2-0.5.2/lib/mysql2/client.rb:90:in `connect'
この時、検索するキーワードとして、
この辺りで検索しようとしても、なかなかドンピシャな記事にたどり着くのは難しいでしょう。
これは、 'hello_world_rails_development'
の部分で記載されているデータベース名というのは、それこそ実行環境ごとに違うからなんですよね。
それよりも、
このような形で、どの実行環境でも必ず出てくる汎用的なキーワードで検索した方が、より問題解消に役立つページにヒットしやすいんです。
なぜなら、これらのキーワードは、フレームワークやプログラミング言語にエラーメッセージとして実装されているから。
def create(*arguments)
configuration = arguments.first
class_for_adapter(configuration["adapter"]).new(*arguments).create
$stdout.puts "Created database '#{configuration['database']}'" if verbose?
rescue DatabaseAlreadyExists
$stderr.puts "Database '#{configuration['database']}' already exists" if verbose?
rescue Exception => error
$stderr.puts error
$stderr.puts "Couldn't create '#{configuration['database']}' database. Please check your configuration."
raise
end
上記はrailsのactive_record内で定義されているタスクランナーのdatabase_tasksのコードです。
エラーメッセージとして、
この文字列を返そうとしているので、実行環境問わず表示されるメッセージになっています。
このように、フレームワークやプログラミング言語固有のキーワードでググるのが、効率よく問題解消する時のコツですね。
公式リファレンスを参考にする
「公式リファレンスを参照したいけど、難しい表現が多くてイマイチ理解できないんだよ。。。」
はい、確かに言いたいことはわかります。
慣れないうちは、Qiitaなどのような第三者が書いた記事を参考にするのもいいでしょう。
ですが、その場合でも、同じようなことがリファレンスにも記載されていたり、コードとしてそのような実装になっているかを確認するクセをつけるといいですね。
というのも、当然ながら公式リファレンスの方が一次情報になるので、情報が正確なんです。
加えて、バージョンアップなども含めると随時公式リファレンスはアップデートされるので、
ということもザラです。
余程情熱的な人でない限り、一度記述された技術記事が公式リファレンスに合わせてアップデートされることは稀だと思うので。
公式リファレンスに書かれた説明がイマイチわかりにくい場合は、メンターやコミュニティなどで、その部分を質問するのも有効。
積極的に公式リファレンスに触れていくといいでしょう。
公式リポジトリのIssueを確認する
フレームワークやプログラミング言語は、基本的にGitHub上で公式リポジトリを立てていることがほとんど。
それぞれのソースコードが公開されているのはもちろんのこと、バグ報告や要望などをIssueとしてまとめられています。
あなたがフレームワークやプログラミング言語を使ってコード書いていてぶち当たった壁や問題は、大抵世界中の誰かが過去同じような経験をしているんですよね。
上記画像のようにrailsだけでも過去closeされたIssueが12,000件以上もあります。
もちろん、中にはIssue起票者の勘違いや、回答者が誰もつかずに期限切れでcloseされてしまったIssueもありますが、大抵はコントリビュータや有志のエンジニアが回答してくれています。
あまり公式リポジトリのIssueを見たことがない場合は、一度覗いてみることをオススメしますね。
GitHubの検索スペースを使う
GitHubには検索スペースがあるのをご存知でしたか?
意外とこの検索スペースが非常に便利で、僕はよく外部ライブラリやメソッドの挙動を追う時に活用しています。
使い方としては、検索スペースにキーワードを入れると、2つのプルダウンが表示されます。
それぞれのプルダウンの違いは、
> in this repository…現在開いているリポジトリページの中からキーワードを検索する
> All GitHub…GitHubに存在する、公開レベルがPublicである全リポジトリの中からキーワードを検索する
上記のような形になります。
使い分けとしては、
- in this repository….特定のライブラリの挙動を追いたい時
- All GitHub…サンプルコードが知りたい時
僕はこんな感じですね。
英語ばかりで難しく感じるかもしれませんが、コードを重点的にみるようにすれば、チンプンカンプンということはないと思いますので、活用してみてください。
まとめ
ということで、僕なりに「プログラミングで詰まった時に問題を解決するためのググりかた」をまとめてみました。
問題に直面した際、その解消スピードが早ければ早いほど波にのって仕事ができると思いますし、短い時間で集中できると思います。
今回紹介した手法がお役に立てたら嬉しいです。