こんにちは、ほけきよです。
趣味の開発でバグがみつかり、学びがあったので備忘録として!
感心をした話
先日、開発していたコードの中に、バグが紛れ込んでいるのを発見してしまいました。 gitで細かくコードの進捗を管理していたので、どこで紛れ込んだのかわからなくなってしまったのです。 100コミットくらいしていたので、どこに間違いがあるか、わかりません。
幸い、近くに超絶優秀な友人がいたので、相談しました。友人は、
友「そういうわからないときは、二分探索が良いんじゃない?log(N)で見つかるし」
と言いました。
なるほど確かにそうすれば高々7回で見つけられるわけだ。図を見ても分かる通り、序盤は驚くほどすばやくバグの範囲を絞れていく。
私「うーんでも、この辺にあると思うんだよねぇ」
友「いや、こういうときは愚直に調べたほうが早いよ。そうしよ?」
と言われたので、その通りにやることにしました。すると、思っていたより早くバグを見つけることができて、感心したという話です。
なんで感心した?
「別に、普通のことでは?」
と思う方も多いでしょう。二分探索なんて、アルゴリズム的に言えば単純なもので、多くの人が理解できるものですし。
私が友人に感心したのは、こういうちょっと焦っている状況のときに、
- すばやく問題から本質を抽出して「二分探索」という解法を当てはめることができる
- アルゴリズムが持つ性質を知っていて、勘を排除し論理に委ねる事ができる
ところです。これって、案外難しいと思うんですよね。
知識をただ持っている人と、それをどう使うか考えている人で結構な差が生まれるんだろうなと感じました。難関大学の数学とかも、こういう傾向が強い。
難しい問題の解法が簡単なものだったとき、
- 「なんだ、こんな簡単だったんか。考えて損した。」
- 「別に、こんなん思いつくでしょ。」
と斜に構えがちになるのですが、本当にその発想に至るには、案外鍛錬が必要。
「三角関数なんてなんの役に立つの?」 ではなく、三角関数をGETしたら、どういう場面で使えるかを考えてみようということです。
こんなふうに冷静に道具として使えてこそ、その分野の「教養」があるのかななんて思いました。
反省をした話
二分探索の前に、友人に開口一番言われたのは
「いや、テスト書こうよ」
でした。笑
ここで言うテストとは、コードを書いたあとに、思い通りに動いているかチェックする機能のことです。テストを書いておけば、バグが発生したときに、「バグです」と見つかっていたはずです。めんどくさがらず、はじめにちゃんと「どう動くのが理想なのか」を定義して、自動的にテストが走るように環境を作っておく。それがその後どういう効果をもたらすのか、身をもって実感しました。
めんどくさがらずにテスト。大事ですね。反省です。
まとめ
というわけで、基礎の基礎かもしれませんが、大事なことだなと思うので、まとめてみました。ちゃんと次に生かさないとな。ではではっ。