スパゲッティなプログラムの法則 Part1

スパゲッティなプログラム…それは、アジエンスのCMに出てくるおねーさまのような指どおり滑らかな髪の毛に例えられるようなすっきりしたものではなく、ハタオリドリの巣のようにどこがどうなってんだかさっぱり分からないグチャグチャになったプログラムのことを指す。

ここ数日、そんなプログラムと付き合っている。

なぜ、スパゲッティプログラムはできるのか。できるべくしてできているな、と思いながら、今日もコード解析をする。

スパゲッティ化するべくしてできている部分とは、例えば、こんな部分である。

共通化部品を作ろうとしている痕跡はある

が、

1) 共通化部品にしないほうがいい部分なのに無理矢理共通化部品にしようとしている
2) 大括りで共通化してしまって身動きが取れなくなる
3) 共通化部品の作り方を間違っている
4) 共通化部品を使う(呼び出す)位置を間違っている
5) 部品にしようとしたりしなかったり、はたまた思想がばらばら

のである。

1)は共通化部品を作るべきでない部分で、無理に共通化部品を作ろうとしているということであるが、結果として、3)を引き起こすのは必須の傾向がある。
どうしても共通化部品を作りたいのであれば、呼出だけ共通になるようなインターフェースを作成してやるのが望ましいとCAMUSは思う。
オブジェクト指向系の言語で言うところのオーバーライドとか、共通できない部分は分割してプログラムを作成してプログラムインターフェースのためだけの関数やクラスを作ってソコから呼び出してもらうとか方法はいくらでもあると思う。

2)は部品を分散すればすっきりするにもかかわらず、大掛かりな部品を作ってしまったが為に部品自体が何をしているのかよくわからなくなってしまっている、ということである。
1とのコンビネーションを形成することにより、余計に複雑度を増してしまっている傾向がある。
IF文のネストがてんこ盛りで、もう何がなにやらさっぱりわからなくなってしまっていたりする。

3)は共通化部品としての作り方を無視して作った挙句、共通化部品としての役割を果たしていないということである。
5に共通することなのであるが、どういうタイミングでどういう作り方をするか、という共通部品の作り方のストーリがないと、「共通部品の作り方」が一致せず、何のために共通部品を作っているのか挙句の果てにわからなくなってくる。

4)は例えばあるデータを作成するのに、そのデータを作成するためのストーリを順に追って部品を呼び出すのではなく、プログラマが呼び出したい順番で部品を呼び出しているということがある。
AというデータとBというデータを作成するためのストーリと利用する部品は同じであるが、部品を呼び出す際の引数が違う、という場合には、AもBも同じ順番で部品を呼び出すことが望ましいとCAMUSは思う。
しかし、それをしていないプログラマも中にはいる。困ったものダス。

5)は3でも書いたが、作り方の思想を統一していないと、何がなんだかよくわからないプログラムに化けるのは一瞬なのである。
これは、同一人物が思想をコロコロと変えないうちに一気に作ってしまうべきだ、ということではない。
はじめの大括りの部分、どこを部品化するかの方針だけを決めておき、プログラム内にコメントを書いておくだけでいいのですよ。

…なんてトッテモ抽象的に提言するかのごとく書いてしまいましたが、

要するに今の仕事の愚痴なんです

というわけで、もう少しこのスパゲッティさんとお付き合いをしなければならないんです。
コイツを解析して何をしているのかを表にしてドキュメント化しておくんです。
それが今の私のお仕事です。(疲)

ところで、タイトルにPart1とうっていますが、今後このシリーズを続ける…ことはないことを祈っといてください。
だって、スパゲッティプログラムを見せ付けられたときにでる愚痴Blogなんだもん。(^^;)
見ないに越したことはありませんから。