過去の記事を読んで、何言ってるのかわからんなで整理しました
自分が書いた記事なんですが
何いってるのかよくわからなくて(・_・;
直近の仕事はＣ＋＋で、組み込み系の仕事を
しました。
本格的にＣ＋＋で組み込みでした。
ソースコードの総量は200万STEPくらいあるかと
そう簡単に解析できる規模ではなかったです。
特にＣ＋＋は小さな部品の集まりで
ソースを読んでいられなかったです
それでも不具合がでたら調査させられますから
必殺の裏技を使いました。
さいわいLinuxの環境があります。
簡単なプログラムを作って
パッケージ（ある大きな単位）下の
全ソースの急所にデバッグ印字を入れて
やりました。
手順
１、Linuxの検索コマンド（find、grep）を
使って、キーワード（調査する際に急所となる
メソッド名など、今回は通知を送信するメソッド名
を使いました）に引っかかるソース名と行数を
ファイルに出力させる）
２、出力されたファイルを読み込んで、検出された
行に来た時に、当該行を丸々一行印字するprintf文をソースに追加する、その時に通し番号も印字させる
これで実行させると、不具合が発生した箇所に
至るまでのシーケンス（通知するのは他のスレッド
に通知するので、スレッド間のデータのやり取りが
分かる、即ちシーケンスが分かる）が分かります
これで不具合の箇所を絞り、
たぶんこのプログラムが怪しいと分かったら
そこには全パスにデバッグ印字を入れて
どの処理を通ったか分かるようにします
これでほぼ不具合の原因が特定されます
（複雑でない不具合のケースですが）
全パスにデバッグ印字を入れる方法は
｛を見つけたら、その下に通し番号つきの
デバッグ印字を追加するというやり方です。
簡単なプログラムを作ってしまいます。
一度全プログラムの全パスをデバッグ印字を
入れたことがあるのですが、
膨大な量の印字で、システムが立ち上がるのに
２０分以上かかり、あと量が多すぎて印字結果の
解析もやっていられなかったので
上記のような２段回に分けるやり方を採用
しました。
あのわかりづらいＣ＋＋のソースが
分かりやすい？Ｃ言語のように
処理ルートが分かって作業効率が上がりました
簡単な方法なんですが、周囲の人はやらないんですよね、頭良いからこういうことは不要なんでしょうか？
しかし私はこのやり方がかなりの不具合対応を
早めにできたと思います
