APIをわざと壊して学ぶ——エラー対応力を鍛える実践的な学習法

APIドキュメントは、APIの基本的な使い方を教えてくれます。しかし、問題が発生したときのことは、ほとんど書かれていません。エラーメッセージは不完全だったり、誤解を招いたり、まったく役に立たなかったりしがちです。そもそも、NoMethodError: undefined method '[]' for nil:NilClass なんてメッセージを目にしたとき、一体何をすればいいのでしょうか?

APIやフレームワーク、ライブラリを学ぶとき、順調に動いているときの使い方だけ覚えていては不十分です。 エラーが返ってきたときにどう対処すべきかも、あらかじめ把握しておく必要があります。

コードの壊し方

使っているAPIが壊れたときの対処法を学ぶ、とても簡単な方法があります。それは、自分でわざと壊してみることです。

たとえば、次のようなことを試してみましょう。

• 誤った型のデータを渡す。 Stringの代わりにシンボルを渡す、Arrayの代わりにStringやHashを渡すなど、型を意図的に間違えてみます。

• 不完全なデータを渡す。 nil、一部のフィールドが空のハッシュ、初期化したばかりのオブジェクトなどを渡してみます。

• ネットワークアクセスが必要なAPIなら、WiFiを切るかケーブルを抜く。 単にタイムアウトするだけなのか、それともどのサービスに接続できなかったのかを教えてくれるのかを確認します。

• ブロックを渡せるAPIなら、ブロック内で例外を投げたり、誤った型のデータを返したりする。

優れたAPIなら、何が間違っていたのかを教えてくれます。さらに優れたAPIなら、どう直せばいいかまで示してくれるでしょう。しかし現実には、Rubyの NoMethodError や予期しない nil、最悪の場合はまったく意味不明な戻り値に遭遇することの方が多いものです。

なぜコードを壊すのか?

これは決して無駄な作業ではありません。オープンソースのgemを触っているなら、その予期しない挙動がどこから来て、なぜ起きたのかをじっくり調べられます。デバッグをして少しコードを読むだけで、ライブラリやAPIの内部構造について多くのことを学べるのです。

NoMethodError の発生源が特定できたら、さらに一歩進んでみましょう。同じ問題に本当に遭遇した次の人のために、エラーメッセージを修正できるのです! 小さなエラーメッセージの改善は、オープンソースへの貢献として最適で、手軽なプルリクエストになります。そして、Rubyエコシステム全体を、すべての人にとって少し良いものにしてくれます。

たとえクローズドソースのREST APIでも、この練習から得られるものはたくさんあります。APIが返しうるさまざまなエラーを事前に見ておけば、本番でエラーに遭遇したときの原因特定と修正が、格段に楽になります。

身の回りのコードのエラーを目にして、修正することに慣れてくると、壊れたコードを「解くべきパズル」として捉えられるようになります。画面に例外とバックトレースがダンプされても、思わず身を引くことはなくなるでしょう。代わりに、自分が扱っているシステムをより深く理解できるチャンスとして受け止められるようになります。

最終的には、コードが壊れても、また元通りに組み立てられるという自信が手に入ります。新しいライブラリやAPIを試すことへの不安が減り、その大胆さが新しい技術を学ぶスピードを加速させてくれるはずです。