ノックアウトテスト

やあ子供たち。元気にしてたかな。寒いからって家でプログラミングばかりしていてはいけないよ。子供は風の子だからね。今日は人が書いたプログラムを理解しなくてはならなくなったときのためのお話だよ。
人が書いたソースプログラムを理解するのに一番手っ取り早い方法は動かしながらそれを読むこと。ただ読むだけではだめ。実際にビルドして実際に動作させながらソースの理解を深めていくのが一番だ。勿論それができない状況もあるだろうけど、部分的にでもそういうことができることが理想だ。
とくに有効なのは、とてもわかりそうにない記述がある箇所は、ためしにぶっ壊してはその結果どうなるかを動作確認し、その箇所がどんな処理をしているかを知ることだ。（ぶっ壊すというのは勿論ソースを削除してしまうのではなくて、すぐ戻せるようにコメントアウトすることを意味する、もしくはリポジトリ管理でいつでもリバートできる環境でやるのだ）機能の内容がわからない箇所があればそこをコメントアウトしては動作上の異変を確認し、処理内容を理解したらもとに戻す、この繰り返しで、ソースプログラムの理解はだいぶ深まっていく。
生物学の世界ではノックアウトテストという手法がある。機能のわからない遺伝子があればそこを壊して、どういうことになるのかを観察する。特定の機能が損なわれた特殊な病気をひたすら研究する中で医学は一歩一歩進んでいく。プログラムも同じなのだ。極端なことを言えば、あるコードをノックアウトして、ある機能が不全になれば、そのプログラムの言語を知らない人だったとしてもそこに何が書かれていたのかを知ることができるのである。
逆に、理解できない箇所を置き去りにして避けて通ってしまうと、それは自分が近寄りたくない場所を自分で作ってしまったことになる。人と話していてもそこにはあまり触れてほしくないし、何よりも理解してないので、不安や焦り、邪推の原因となる。わからないものは徹底的に解明し、それを礎として次のステップに進んでいくという科学的態度から遠ざかり、最後は祈りはじめたり、おまじないなんかを始めるかも知れない。本当にそういう人がいる職場もあるのだ。だからみんなはそうなってはいけない。そういうものが蓄積すると、最終的には仕事そのものがいやになってしまうだろう。
そのためにもわからない箇所を自分で作るのではなく、徹底的につぶしていって欲しい。
ソースのどこに何が書かれているのかはだいぶわかってきた、しかしどうしてこう妙にややこしい構造になっているのだろうと思えるようになったら、思い切ってそこをまるごと自分のコードで置き換えてみよう。ソースプログラムとの対話はここから始まる。自分で書き換えた機能だから、何も怖くはないし、周囲の入出力と連携してそれが動作する様を確認すれば、よりいっそう理解が深まっていく。
でも自分の改変したものをリリースに出すときは、必ず改変前のものと同じテスト結果が得られてからリリースしよう。改変コードにどんなに自信があったとしてもテストせずにはい、って人に渡しちゃうのが許されるのは新人の研修期間だけだからね。

細胞の分子生物学