プログラムを分割することと図形に補助線を入れることはなんとなく似ている（気がする）

著者： 三田 紀房

タイトル： ドラゴン桜 (1)

ドラゴン桜という漫画が面白い。受験漫画というよりは、勉強とは本来どうあるべきかについて、示唆に富んでいる。初心者プログラマが今後いろいろなことを学習するにおいても非常に参考になると思う。

初心者プログラマがプログラムを書く上で最初につまずくのは、自分でプログラムを書く時に分割できずに、一つの関数にべたーっと書いてしまうことである。最初はそれで構わないのだが、どんどん拡張していくに従って、何がなんだかわからなくなってきて、書けなくなってしまう。

そこで先輩プログラマが、「分割しないからだめなんだ。分割はプログラムを作る上での基本だぞ」と言ったところで、どう分割していいかわからないのだから意味がない。

その昔を思い出すと、中学や高校の数学（幾何）の時間に、図形に補助線を入れると簡単に解けると習ったが、どこに補助線を入れればいいのかよく分からないというのが最初の印象だった。

点と点を繋ぐ補助線なら誰でも引ける。だがそれ以上（点と線上のどこか、図形外のどこか）になると、どこにでも引けそうな気がして、動けなくなる。プログラムも似たようなものではないだろうか。分割された後のプログラムを見れば理解はできるが、いざ自分で分割するとなると、どこも同じように思えてしまう。

プログラムをどう分割するかは経験則だ、と言ってしまうとそれ以上先には進まない。数学の図形の補助線は、ある程度までなら学習を繰り返すことで、補助線の書き方もパターン化できる。プログラムの分割についても同じことが言えるのではないだろうか。

分割を考えるには、プログラムを処理の固まりとして考える必要がある。抽象化ではなく、具体的なプログラムにおける固まりである。処理速度を優先すると、なかなか固まりが見えてこないので、処理の中身に意識を向けたほうがよい。

オブジェクト指向言語だと固まりを固まりのまま扱いやすい。そこから一歩進むと抽象化なりデザインパターンという話にも繋がっていく。どういう固まりが他のどの固まりと繋がっているか、その固まりはもっと小さな固まりにしたほうがよいのかどうか。ポイントはいくつかあるが、要はプログラムを眺めた時に固まりを意識できるかどうかである。

固まりを意識できれば、固まりと固まりの間は分割できそう、と思えるようになる。そこから先はテクニックを要するが、やりたいことが決まっていれば、もし誰かに質問しても的確な答えが得られるだろう。「何を分割したらいいか分かりません」という抽象的な質問には答えにくいが、「こういう風に分割したいんですが、この変数はどうやって渡せばいいでしょうか？」は具体度が増している。

分割統治、分割統治とお題目のように言われて、分割することだけを意識していると、いつまでたってもプログラムを分割できない。分割ありきではなくて、固まりありきなのだ。何もないところに補助線は引けない。どうでもいいところを分割してもしょうがない。簡単そうなものは実は難しいという典型的な例だが、コツを掴んでプログラミングに励んでほしい。