技術系のコミュニケーションにはミニマムコードは欠かせません。 現象を100の言葉を並べて説明するよりも動作するプログラムを1回動かしてもらう方がよく理解してもらえるのです。 まさに百聞は一見に如かずといったところでしょう。

ミニマムコードに求められること

ミニマムコードとはなんでしょうか？「ミニマム」＋「コード」ですから、最小限のコードといった意味合いです。 最小限だけれども、それだけで動作する完全なプログラムである必要があります。 該当部分のコードの抜粋とは違うのです。

• それだけで動作するコードであること
• テーマを再現できること
• テーマ以外が極力含まれないコードであること

テーマと言っているのは、その時々で話題にしている議題のことです。 ある現象について話しているならその現象を起こせるコードということです。 コードは余計なものが含まれていないことが理想的です。

余計なコードがあると、本来テーマにしたい部分が埋もれてしまいます。 コードを隠すならコードの中というわけです。論点をはっきりさせるために、関係ないところはそぎ落とします。 設定ミスなどの場合、そぎ落としていく過程で何が悪かったのかが分かることがあります。 最小限だと動くのに、本番のコードは動かないとなれば、その差分の部分にバグがあるわけです。

科学実験に学ぶ検証手法

あるコードがうまく動かないとしましょう。問題がどこにあるのかを検証するには、科学の実験の手法が踏襲します。 該当の箇所に問題があるか、ないかを知りたければ、ターゲット以外が全く同じ状態で検証を行うのです。

一度にいくつもの部分に修正を入れると、どれが作用したのかわからなくなってしまいます。 また、外的要因によって結果が違っているのかもしれません。 そういった場合に正しく問題個所を絞り込むことができなくなってしまいます。

こういった科学実験の基礎は理学や工学系の大学に行くと学生実験という形で学びます。 大学以前の学校での理科の実験なども基本的には同じですが、 それほど科学的検証を厳しく問われないので印象としては薄いかもしれません。 （厳しい大学だとレポートの再提出に学生は苦しむ）

オカルトなどでは、因果関係を正しく掴まないことによるものが多くあります。 とくに、結果ありきでの実験のレポートは見るに堪えません。 結論付けたい事柄があって、そのことに都合がよいように実験をしてはいけません。 プログラムのバグの検証も、頭の中で「XXが悪いに違いない」などと強く思うと 堂々巡りでなかなか解決できないところに迷い込むかもしれません。

部品単位で検品を行う

プログラムはパーツパーツで動作確認をとって組み上げる必要があります。 小さなパーツが正しく動くかどうかテストすることは簡単です。 しかく、組み合わさって大きな機能になると、動作確認は格段に難しい。

boolean値がひとつ増えるだけでテストケースは2倍になるのです。 全部組み上げてから部品のテストを行うなどと考えてはいけません。 急がば回れということです。

仕様がよくわからないといったときには、とにかくミニマムコードを書いて動かして検証しましょう。 もし、理解できない動きがあるのであれば、そのときはコードを示して質問するなどすればよい。

問題の切り分けもできず、長いプログラムを掲示板に張り付けたところで、 労力をかけてまで読んでくれる人は稀です。 ミニマムコードにまでそぎ落としてあれば検証してくれる人はぐっと増えることでしょう。