前回、コードに垂直方向のスケーラビリティ――コード規模のスケーラビリティについての式を考えた。
Nがコードの規模、Wがそのコードを作る労力であり、wが単位規模のコードを作る労力、rがコードを加える際に既存のコードを調べたり・改造したりする割合を示す係数である。
全体の労力を少なくするにはどうすればよいだろうか。式からして３つしかない：
- wを小さくする
- Nを小さくする
- rを小さくする
wはNの項にもかかっており、wを小さくするのは開発全体を効率化するということを意味する。「ITこそITで効率化せよ」でも書いたので、今回は説明を省く。
rNNが0に近ければ全体のコードの規模は加えた労力に対して線形に大きくなる。そういうコードはスケーラビリティを持っていると言える。
もしかしたら、log(rNN)をコードのエントロピーと呼ぶことができるかもしれない。統計力学・情報理論のエントロピーだ。コードの乱雑さを示す値であり、コードの情報量を示す値である。
エントロピーが小さいコードは美しいコードであり、拡張性に優れたコードである。
Nを小さくするとは、つまりソフトウェアの規模を小さくするということだ。Nの自乗で効いてくるので、コードがコンパクトになる効果は高い。これが実際最も効果がある。最速のソフトウェア開発手法は作らないことだ。要するに、いらんもんを作るな、いらないものは除いていけということだ。
誰も望んでいない意味のない機能は作らない。どのモジュールからも呼び出されていない関数は削除する。あるいは、すでにライブラリが用意されている機能は作らない。重複したコードはまとめる。
開発というとコードを増やすことだと思っている人がいる。コードの規模に価値をおいている人が多い。しかし、コードを小さくすることの重要性はあまり気づかれていない。
新しく作るなら、プログラミング言語を選択する時に、コードの規模を小さくできるかどうかを判断基準に含めたらよい。ライブラリが充実していないようなプログラミング言語は使ってはいけない；間違ってもShellスクリプトなんかで新しく機能を作ろうなんてしてはいけない。あるいは冗長性が少ない簡潔な記述ができるプログラミング言語がよい。*1
とはいっても、Nを小さくするにも限界がある。書かずに機能を実現できるのが最もいいが、全く書かないというわけにはいかない。
そこで、rを小さくする必要があり、ここからがプログラマーの腕に見せ所となる。rの大小は設計の問題だ。スパゲッティコード・クソコードといわれるものはrが大きい。
１人で全部書く場合は既存の部分を理解しているわけだから、rは小さくみえる。他の人が拡張する場合でも、rが増加しないコードというのが良いコードだ。
rが小さいコードを書くというのは非常に難しい。凡庸な開発者には難しい。天才たちが数々の手法を考えてきたが、銀の弾丸はない。私も手法だとかコンセプトだとかはいろいろ知っているが、いつも苦労している。
こういうコードを書ける人は貴重だ。
