先行評価(Eager Evaluation)勉強法とトラブルシューティング

新人プログラマのよしおかです。どうぞ、よろしくお願いいたします(ぺこり)。という日々を送っている。日々のトラブルシューティングの話なんかをここに記したい。

そもそもAsianux Mobile Midinux 2.5Jというのは、Intel Moblin(http://www.moblin.org)準拠なのでいろいろお作法が違う。

debianのパッケージング方法なんかも一から勉強である。最近はインターネットのおかげで高速道路が整備されているので、必要なマニュアルは全てオンラインで入手できる。debianのドキュメントの充実度は目をみはるものがある。一見遠回りのようでいても、ドキュメントをひととおりざっと眺めてみることは、重要である。何か問題にぶちあたったときにググって断片的な回答を発見するのではなく、まづマニュアルにあたってじっくり仕組から理解をする。すぐに回答にたどりつかないように見えてもそれは自分に対する投資なのであせらない。習熟曲線というのは最初はなだらかで、ある程度いくとぐぐっと立ち上がる。そのぐぐっと立ち上がるところまでは自分に対する投資である。

まわりにいる、debian使いの人のお世話になって、最初の道案内をおねがいし、読むべきドキュメント、マニュアル類をおさえる。これ非常に重要である。必要になるかならないかわからないけどドキュメントをちゃんと読む。Eager Evaluation(先行評価)勉強法である。で、わたしは、その投資のリターンが非常に高いことを経験則として知っている。ドキュメントを読む時間(投資コスト)は低いので、ローリスク、ハイリターンな投資となる。

日記界隈のハッカーは遅延評価勉強法をとっているようである。何か問題にぶつかったら、それについて調べるというスタイルである。こちらの方が、一見レスポンスタイムが短かくお手軽ですぐれているように思えなくもない。しかし、一つのことを極めようと思ったら初期投資をおそれてはいけない。結局はマニュアルなど原典にあたることになる。

まあ、こーゆースタイルは誰かに強制するつもりもないし、強制できるものでもない。遅延評価で場当たり的にやっていても結局いつの日かマニュアルを読むことになって実はああ何か遠回りをしたなあと気がつく。マニュアルをはじから読むなんていうことは、自分にはなかなかモチベーションをキープするのが難しい。どうしてもつまみぐいになってしまう。という声も聞くが、人それぞれなので、もちろん強制はしない。

わたしなんかは、何度も言っているようにIntel Software Developer's Manualを読むのが趣味という芸風なので特殊例だとは思うが。

で、トラブルシューティングのお話なのであるが、最初はその問題について初心者で動作原理を十分理解していないから、現象を見ただけでは、なんでそのような現象が発生するかチンプンカンプンの状態からはじまる。これが、その問題についてのいろいろ経験して理解がすすんでいけば、現象を見ただけで、ある程度原因がわかっちゃったりするのであるが、そこにいくまでは、いろいろな試行錯誤の連続になる。プログラマはその経験のつみかさねで自分の適応可能領域をどんどん広げていくことになる。

初心者の場合、毎回毎回初めてみる現象に遭遇し、そのたびに、わけがわからなくて、どこからあたりをつけていいかわからないので、試行錯誤をくりかえす。初めての問題なので、そもそも簡単な問題なのか難しい問題なのかすらわからない。ひょっとしたらとんでもない超難問にぶつかってしまったのではないだろうかとか不安になったりもする。解決するには何日も何日もかかるような問題なのではなんて思ったりもする。

第一歩は問題を正しく理解することである。何がおこっているか正しく理解することである。安易な解決策に飛びつこうとしない。先入観をすててありのままに現象を観測する。それが第一歩である。

先日遭遇した問題はこんな問題であった。

ソースコード管理システム(git)からソース一式を持ってきて(git-clone)してビルドする。問題なくビルドできる。いろいろ変更して再度ビルドすると、ビルドできない。Makefile他ビルドシステムそれ自身は一切変更していないので何がなんだかわからない。こーゆー状況に遭遇した。

問題を切りわけるために、原点にもどってみる。git-cloneしてビルドする。問題なくビルドできる。いろいろ変更したのが問題かもしれないので、何も変更しないでビルドしてみる。ここが最初のチェックポイントだ。ビルドが失敗する。ここからトラブルシューティングの旅がはじまるのである。

何がなんだかわからない事は、その通りなのである。解決できるかできないかも、その時点では見通しすらたっていない。どういう戦略でトラブルシューティングをしていくか。

ビルドのログをじっくりながめてみる。エラーがないのか、あるのか。ビルドができないのは結果であって何でビルドができないのかを理解することが必要になる。そうすると、パッチをあてることを失敗している。なぜなんだろうか？debianパッケージの場合オリジナルのソースに独自パッチをあて、その後ビルドをするというプロセスになる。

なぜパッチをあてることを失敗しているのだろうか。

ビルドする前に前回あてたパッチをとりのぞいて真っ新な状態にする。そして、今回ビルドするにあたって再度パッチをあてビルドする。ログを見てみると、前回あてたパッチをとりのぞくことに失敗している。そのために同じファイルに2度目のパッチをあてることをこころみ結果としてそのビルドに失敗している。

なぜパッチをとりのぞくことに失敗しているのだろうか。

問題のパッチのコードを眺めてみることにする。失敗したパッチには.rejというファイルができているので、それもあわせて読む。

パッチのコンフリクトしている部分がrejファイルには記述されているので、それを見た。

そうすると、ある行についてパッチがあたらない。なぜか。

パッチファイルにはTABで書かれていたが、それが空白に変換されて適用されていた。そのためパッチをとりのぞく時に、とりのぞけなかった。

さて原因がわかった。現象を分析し正しく理解すれば原因がわかる。原因がわかれば解決策を作るのは簡単である。パッチファイルのTABを空白にした。再度ビルドしてみてビルドできることを確認した。

理解してみれば他愛のないことである。しかし現象をみた段階で、何がなんだかわからなかったことも事実である。問題を一歩一歩理解していくといくプロセスがトラブルシューティングの王道である。

その道標としてマニュアルをきちんと理解しておくことが重要である。

ハッカーと遅延評価勉強法/Slow Dance
http://d.hatena.ne.jp/LukeSilvia/20080402/1207149044

私の言語遅延学習法 - 三つのルール+1/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50999338.html

遅延評価的勉強法/IT戦記
http://d.hatena.ne.jp/amachang/20080204/1202104260