こんにちは！PA Labメディアです。
前回の記事に引き続き、調査方法のワークフローの後編を書いていきます。
オープンソースソフトウェア(OSS)で問題が出てきた際のデバッグの方法に関しての記事を執筆していきます。OSSに限定して記事を書いていますが、OSSに限らず適用する事ができます。
地味に見えるかもしれませんが、問題が起きた際の調査力はエンジニアにとって非常に重要なスキルで見たことのないエラーを解決出来る能力はどの現場でも求められます。
問題を特定するためには実際には様々な調査方法がありますが、今回は最もシンプルなワークフローエラーが出た際の修正方法、対応方法を簡単に解説していきます。

今回の記事では以下のような方を対象にしております。

本記事は上記のような方を対象にした記事となっています。
結論から話していくと、以下のような流れで調査を進めていきます。

今回は実際に現場で発生したエラーに関する調査ワークフローを例にして解説していきます。
Pythonを対象とした例になっていますが、どの言語でも適用可能なので是非最後まで読んでいただければ幸いです。
本記事は２部作となっており、後半の記事となります。

まだ前半記事を読んでいない方はこちらから読めます。

デバッグを行う

Pythonに限定した紹介を行いますが、いくつかデバッグの方法があります。Pythonに限ると、Jupyterで試す方やprintデバッグを試す方が多いですが、デバッガを使用する方は少ない印象があります。

デバッグの種類

データ分析の文脈だとprintデバッグや分割統治法がよく用いられる事が多いですが、システムやソフトウェアの開発ではデバッガを用いる事が多く、特に3番目のIDEを使用する事が多いです。

最近ではVisual Studio Codeで開発を行う方も多く増えてきていますが、IDEでの開発は便利な事が多いのでこちらの記事も是非参照してみてください。Pythonでは特にPyCharmというIDEがよく使われています。

デバッグの工程

デバッグの基本的な手順に関して見ていきましょう。

デバッグの基本的なステップは以下である。

1. バグの存在を認識する

2. バグの発生源を分離する

3. バグの原因を特定する

4. バグの修正方法を決定する

5. 修正し、テストする

https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%90%E3%83%83%E3%82%B0

それでは一つずつ見ていきましょう。

(1)デバッグの工程: バグの存在を認識する

エラーが起きる前にもある程度予測をつける事ができます。例えばユーザーが入力する値は想定している入力とは違うものが入る可能性が高いため、バグになりやすいです。数字のみの入力の箇所で文字列を入力する、XSS(クロスサイトスクリプティング)のように意図的になにかを実行させるような処理なども考えられます。

とても当たり前の事なのですが、実際に現場でタスクが増えて忙しくなってくると何も考えずにコピペで検索してしまったり、その場しのぎで解決策を探してしまう、といった方が多くいるようです。

「エラー文をしっかり読んで、どこに問題がありそうかを考える」という動作を行うことで、着実に技術力が身についていきます。逆に言うと技術力が高いエンジニアは見た事ないエラーでも早い段階で的確な当たりをつけて問題を特定する能力が高いです。

(2)デバッグの工程: バグの発生源を分離する

どこでバグが発生しているか、問題を切り分けていく箇所になります。コードレベルに限らず、ネットワークやインフラでも同じように分離していき問題を特定していくフェーズは必須になります。最も簡単な問題分離としては二分探索を用いる方法があります。例えば1から10までコードを書いている場合、半分の5の段階でprintデバッグを行い問題が1~5にあるのか、6~10にあるのかを切り分けていく手法です。

二分探索は現実の概念にも適用がしやすいし、簡単なアルゴリズムですが強力なので覚えておくと良いです。

(3)デバッグの工程: バグの原因を特定する

次にバグの原因を特定していく必要があります。入力データに問題がある可能性もありうるし、ロジック上のエラーもありうるので、上述したようなipdbやIDE上のデバッガを用いて一つずつ見ていくと良いでしょう。デバッガにはステップ実行という機能があります。それぞれの変数の挙動を確認するためのデバッグ方法で1行ずつ実行する事ができるため、これを用いて詳しく原因を見ていく必要があります。

ステップイン

基本的に1行単位で詳しく実行していく。別の関数が呼ばれている場合、その関数内部にも入り込んでデバッグを行う。

ステップオーバー

ステップインと同じように1行ずつ実行されるが、別関数が呼ばれている場合、その関数を実行して次の行に入り、関数内部には入らない。

ステップアウト

今実行している関数の呼び出し元に戻るまで実行をする処理。

この3つを組み合わせてステップ実行を行い、バグの原因を特定していきます。

(4)デバッグの工程: バグの修正方法を決定する

どのようにバグを修正するか、という決定を行います。実際の修正コストと修正した時のメリットを比較してどのように修正するかを考える事が多いです。現場でよくある修正方法は一時的な修正を行った後、時間に余裕ができたタイミングで正しいアプローチでの修正を行う、というものです。

システムの修正はよく六法全書の法律文を改修するようなものに近い、という言い方をされる事があります。例えば、六法全書のある法律の一文を修正した場合、それに関連する全ての法律に影響がないか、確認をする必要があります。一文の修正自体は簡単でもシステムの全体に影響がないか、という点を考慮して修正するのが最も大変な箇所となります。

(5)デバッグの工程: 修正し、テストする

修正方法が決定された場合、修正してテストを追加して動作の確認を行います。
テストを追加する事で今後別の問題が起きた時に今回起きたバグに関してのエラーが起きていないか、などの確認ができます。

ドキュメントを書く

エンジニアの方ではドキュメントを書く事を軽視する方が非常に多いですが、基本的には何らかの処理を行った際には簡単にドキュメントを書いておく事が大切です。大きく分けると自分に向けて書くドキュメントと他人にも分かるように書くドキュメントの2種類があると思いますが、ラフでも良いので基本的には行ったことは少なくとも自分にわかるようにメモしておくと良いと思います。

他には、サーバー内で実行したコマンドの一覧なども取っておくと良いです。Linuxではhistoryコマンドで実行したコマンドの一覧が取得可能ですので、ドキュメントツールなどに保存しておくと良いです。

ちなみにドキュメンテーションツールに関してはこちらの記事に詳しく記載しております。

ログを見てみる

簡単なスクリプトやJupyterなどでは出てきませんが、システムであればきちんとログを取るようにする必要があります。基本的にはシステムは作成するだけではなく、運用・保守が必要になってきます。システム障害も発生したときに、ログを足がかりにして原因を探っていく必要があります。これがないと、原因が分からず障害のときに大変な事になります。

スタンドアロンだったり、スケール性があるアーキテクチャを採用していたり、Webアプリやモバイルアプリなどによってログの取得方法は検討する必要がありますが、基本的には同じ仕組みになるので、最低限の仕組みを覚えてログに書き込む癖をつけると良いでしょう。

最も簡単にできる箇所としては、print文の代わりにロギングのライブラリを使用する癖をつけましょう。Pythonであればloggingというライブラリが標準であるため、活用していきましょう。

まとめ

今回の記事は後編という事で、デバッグ・ドキュメンテーション・ロギングというアプローチから解説していきました。エンジニアであればどの職種でも問題解決力は問われる場面は多いので、見たことないエラーに対してもコピペだけで済まさずに、きちんと考えた上で解決を図っていくことで技術力向上につなげながら日々の業務を行っていく事ができます。

PA Labでは「AIを用いた自動化×サービス開発」の専門家として活動をしています。高度なデータ分析からシステム開発まで一貫したサービス提供を行っており、特に機械学習やディープラーニングを中心としたビジネス促進を得意としております。

無料で分析設計/データ活用に関するご相談も実施中なので、ご相談があればお問い合わせまで。