6月になりました.
庭のバラが咲く時期、5月にまたひとつ歳をとりました.
定年まであとわずかとなりましたが、有難いことに戦力外となることなく、若い人たちと一緒の現場で働かせ貰ってます.
そんななか、現場の最前線でバリバリやるよりも若い人たちに自分の持っている技術(…といっても大したことはないんですが…)を伝授する役割にシフトしていってます.
若い人たちに如何に自分の技術を伝えていくのか、ここで自分なりの整理が必要だと考えたので、このテーマで書いていこうと思います.
Table of Contents
継承が難しい技術
例えば何の理論やプログラミング言語なら、
「この本、まずは読んでおいて」
と参考書を紹介することである程度の技術継承ができるかと思います.
それは言語化ができる技術分野、だから継承がやりやすいのだと考えます.
逆に継承が難しい技術、言語化が難しい技術分野は何だろう？と考えた場合、その代表例が
デバッグ、
トラブルシューティング
ではないか、と考えてます.
デバッグ対応についていままで自分なりに考えて対応した方法について書いていきたいとおもいます.
デバッグ、トラブルシューティングの手順
一般的にバグが発生した時の対処の手順は、自分なりに考えると以下の感じかと,
(諸説あります)
- ログ等のデータ分析
- 分析結果から原因を推定、仮設を立てる
- 立てた仮説を立証、原因を特定
- 特定した原因を修正
- 修正した結果を評価
では、それぞれの手順について書いていきます.
データ分析
データの入手
まずバグを発見したら次のような情報を用意します.
他の部署からのバグ報告であれば以下の情報を要求しましょう.
- バグの内容.
- バグの発生手順.
- 現象の発生確率、同じ手順で毎回発生するのか、どうか.
- バグが発生したときのログ.
次のような情報があるとバグ解析に有益な場合もあります.
- 同じ環境で正常動作したときのログ.
- バグ発生させた手順を撮影した動画.
バグ発生条件を文章や口頭でもれなく伝えるのは難しいので、特に現象発生時の動画があると役に立つこと多いです.
検証範囲を限定
対象のシステム、プログラムの規模が大きい場合、あるいは入手したログが巨大な場合、バグの内容と発生手順よりおおよその発生原因を推測して検証するデータ範囲を絞ります.
ログデータの検証
データのおおよその見る範囲を絞れたら、ログを以下のような観点で読んでいきます.
- 呼び出しているライブラリ、関数でエラーを吐いてないか?
- 処理が途中で止まっていないか？
- 来るべきイベントが来ているか?
- 逆に想定してないイベントが来ていないか？
- 想定した順序で処理がおこなわれているか?
- こちらから投げたイベントに対して応答は来ているか？
などなど…
場合によっては正常に動作したログと見比べることも必要となります.
仮説を立てる
ログを含め入手したバグに関するデータ、情報からバグの原因の仮説を立てます.
たとえば、
- 呼出した関数の使い方が間違っているのではないか？
- 入力されるイベントの順番が逆になることを想定してないのでは？
- 入力データが大きすぎて用意しているバッファがあふれたのでは？
入手したデータから仮説をなるべく多く立てます.
持論ですが、
立てられる仮説の数と質は経験と技術力に比例する
と思ってます.
ここで技術者の力量が問わると思ってますが…どうでしょうか？
仮説を検証する
立てた仮説を一つずつ検証していきます.
例えば、呼び出した関数の使い方が間違っているかも？という仮説に対して、man コマンドなどで使い方を確認します.
イベントが逆になるのを想定していない、という仮説の検証はイベントの順序を逆にするような操作、あるいは周辺のプログラムを改造して動作をみます.
そうやって仮説を一つずつ検証していって、すべての仮説が外れることも良くあることです.
その時は最初のデータ分析からやり直します.
バグ対策の30～40％はこの工程が占めます.
また,検証の結果、自分達の担当以外の他の部署担当に原因があることも良くあります.
その時には相手が解析しやすいような情報を渡してあげます. これについてはまた後日書きたいと思います.
原因を修正
立てた仮説がズバリ立証された場合、その原因となっている箇所を修正して行きます.
経験上、ここの工程はバグ対策全体の10%程度かなぁ、と…
ほとんどの場合、バグの原因ってごく小さいモノなのです…
しかしながら、基本設計のバグによるものだとかなり大がかりな改修となって、場合によってはその周辺作りなおしになる場合も…
というわけで設計レビューは大事なんですよ…設計そこそこでコード書きたい気持ちは分かります…
修正した内容を評価
発生したバグが想定通り修正されているか、さらに修正したことによる副作用、すなわち新たなバグを発生させていないか評価します.
この評価工程がバグ対策全体の５０％ほど占めます…修正内容の規模にもよりますが…
ここでNGだった場合、修正してもなおバグが再現される場合、データ分析からやり直し.
バグは発生しないものの副作用が出るときは修正方法に問題ありなので、原因を修正からやり直しです.
バグ対応フローチャート
いままで書いた内容を以下のようなフローチャートになるかなぁ、とおもいます.
ということで以上の情報が若い方々のデバッグ対応向上のお役に立てれば幸いです…
デバッグ対応は力量がモノをいう
先にも書きましたが、デバッグ対応はエンジニアの力量が問われます.
その反面、デバッグ対応で技術力が身につくというもの事実.
デバッグ・トラブルに対して真摯に対応した若い人がめきめきと技術を身に付けていった光景を良く見てます.
…ということで、デバッグ対応はチャンス、と前向きにとらえて対応したいものです…
（でもバグ対応はいやですよね…ｗ)
デバッグ指南の本って少ないのですが,仲間内ではこの本が結構参考になってます.
対応が終わったときの対処が大事
バグの修正作業で技術的に得るものは少なくないです.
作業がおわったときの仕上げに以下の点を整理しておくと良いです.
- 今回のバグの原因の本質は何か？
- 本来どういう設計・実装すればよかったのか？
- 似たようなバグを出さないように今後気を付ける点は？
これを整理しておくとバグ対応の経験が確実に技術力として身についていくと思います.
どこかにメモしておくと良いでしょう. 詳細は忘れてしまうことが多いですが、「たしかこういうバグをどこかで見たことあるなぁ」という記憶は残るはずです. その時にメモを見直せばよいです.
そして、この対応の積み重ねが次のバグ対応の効率を上げていく、はずと思っています.
