第1章
「世界で闘うプログラミング力を鍛える150問」と並行して、こちらも少し読み始めました。
まず1章読んだので、軽くまとめ。
ポイントは"TRAFFIC"
T rack : 問題をデータベースに記録する
R eproduction : 障害を再現する
A utomate : テストケースの自動化と単純化を行う
F ind : 感染源の疑いがある箇所を見つける
F ocus : 感染源の疑いが最も高い箇所に着手する
I solate : 感染の連鎖を分離する
C orrect : 欠陥を修正する
言葉で書かれてもピンと来ない人向けに、実際のプログラムの問題解析をベースに解説されています。
サンプルは sample.c にありますが、せっかくなんでPythonで書きました。
汚い(特にsort_list関数)ですが、それはわざとです。ロジックが分かりづらいソースコードの解析のためですね。
まぁこれよりひどいのをよく見かけますが。。。
#encoding: utf-8 import sys def sort_list(num_list, size): h = 1 while True: h = h * 3 if h > size: break while True: if h == 1: break h /= 3 i = h for i in range(1, size): j = i v = num_list[i] while True: if j < h or num_list[j - h] <= v: break else: num_list[j] = num_list[j - h] j -= h if i != j: num_list[j] = v if __name__ == '__main__': num_list = [] for i in range(0, len(sys.argv) - 1): num_list.append(sys.argv[i + 1]) sort_list(num_list, len(sys.argv))
先に書いておくと、Cとは挙動が違います。
テキストにあるcのコードだと、以下のような挙動になるようです。
> ./sample 9 7 8
Output: 7 8 9
> ./sample 11 14
Output: 0 11
Pythonのコードだと、どちらもエラーになります。
この問題はallocしたメモリ外をアクセスすることによって発生するってものなんですが、
Pythonだとそもそもメモり外をアクセスした時点でエラーってことですね。
Cだとそうならないのが辛いですよね。とりあえず動いちゃうから、ある日突然障害が起きたりするわけで。。。
さて、テキストではこの問題について、先ほどのTRAFFICに沿って問題調査をします。
が、まとめるの面倒なので省略。ただ、それぞれの詳細な説明については、以下の通り各章であるようです。
T rack : 問題をデータベースに記録する
➡2章
R eproduction : 障害を再現する
➡4章
A utomate : テストケースの自動化と単純化を行う
➡3章、5章
F ind : 感染源の疑いがある箇所を見つける
➡7章、9章
F ocus : 感染源の疑いが最も高い箇所に着手する
➡7章、8章、10章、11章、13章、14章、16章
I solate : 感染の連鎖を分離する
➡6章
C orrect : 欠陥を修正する
➡15章
実際にはFind、Focus、Isolateを繰り返す作業になります。
これが一番大変なのですが、そのための技術を「自動デバッグテクニック」として紹介。
入力の単純化
➡差分デバッグを使用。詳細は5章。
プログラムスライス
➡演繹法で、怪しいソースコードを絞る。詳細は7章。
状態の観察
➡デバッガで特定時点の状態を観察。詳細は8章。
状態の監視
➡デバッガで特定変数を監視。詳細は8章。
アサーション
➡Unit Testのアサーションのこと?詳細は10章。
異常
➡異常の検出法と書いてあるけど、全部そうなのじゃ?詳細は11章。
ミスから学ぶ
➡これは毛色が違って、過去のバグ報告から、不安定なモジュールを選んでactiveに調査。詳細は15章、16章。
最後に言葉の定義。
欠陥(defect) :不正なプログラムコード (コードに含まれるバグ)
感染(infection):不正なプログラム状態 (状態に含まれるバグ)
障害(failure):外部から観察できる、不正なプログラムの動作 (動作に含まれるバグ)
今後やることについての概観って感じの章でした。
さて、ジム行ってくる!