プログラムは小さく作って積み上げろ

1987年（昭和62年）。

アメリカのUUNETというインターネットサービスプロバイダ(ISP)のサービスが始まった年です。日本では1992年（平成4年）にIIJが先駆けとなって、以降インターネットは世界中のすみずみにまで届き、我々にとってなくてはならないインフラとなりました。

この革命的な出来事は自分たちの生活を一変させただけでなく、コンピュータのシステム開発にまで変革を起こしたのです。

インターネット以前のシステム開発

パソコンショップというものが東京は秋葉原、自分の地元では愛知県の大須あたりに立ち並び、ハードウェアと共にソフトウェアも陳列して売っていました。
この頃のシステム開発はとにかく動くことがまず先にあって、あまりシステマチックな開発ではありませんでした。プログラムが多少読みづらくてもテストが通ればエイヤー！でリリースしてしまいました。

なので新規の開発は前システムを継承するというのはそこまで重視されておらず、下手をすると一から作り始める始末でした。

インターネット以後のシステム開発

WEBが浸透してCGIという技術ができると、ブラウザで買い物するなど、サーバーにデータのやりとりする様々なサービスが現れました。これによってプログラムはサーバー側にあり、入出力はユーザーのブラウザを介して行うようになりました。

これによってどうなったかというと、アプリがリリースした後でも開発側で管理できるようになったので、プログラムの変更や改修は作成したアプリ上にどんどん行うこととなったということです。

これまでは一度作り上げたプログラムはあまり触らないという文化から、作り上げた後でも何度も改善・改修する文化へと移ってきました。
今ではWEBでないアプリもネットでバージョン管理され、どんどんアップデートされていってます。

つまりはシステム開発でも、動けばよい。という作り方から、改修しやすい。デバッグしやすい。テストしやすい。というところも含めて求められるようになってきました。

では、改修しやすい。デバッグしやすい。テストしやすい。というプログラムはどういうプログラムなのでしょうか。
これについては先人たちが様々な理論を考え出されては淘汰されていき、現在、正解じゃないかもしれないけどまだ淘汰されるに至ってはいないという考え方が、タイトルにある「小さく作って積み上げる」という方法です。

「小さく作って積み上げる」ってどういうこと

「小さく作って積み上げる」開発ってどういうことなのでしょう。
例えば、レゴブロックを想像してください。レンガの様なブロックに接続用の突起の付いたおもちゃです。これでロボットを作ろうとしましょう。

まず小さいブロックをかき集めて組み立て、手や足、顔、胴体のパーツをそれぞれ組み立てます。その後に手足顔のパーツを胴体にくっつける。
そんな感じに組み立てていきます。

プログラムでいうなら、まず小さな関数、それこそ式が一つだけとか、くり返し文一つだけとかの小さな関数を必要なだけ作ります。
その関数を組み立て、一つの関数を作ります。さらにその関数を組み立て、大きい一つの関数を作ります。さらにその関数を組み立て…と組み上げ組み上げていってシステムを作り上げるのです。

「小さく作って積み上げる」がなんで改修しやすく、デバッグしやすく、テストしやすいの？

まずはなぜ「小さく作って積み上げる」が改修しやすいのか。
例えば不要な機能を外して、新しい機能を着けたいとします。
先ほどのレゴブロックのロボットの例でいうなら、腕をドリルにしたいとしましょう。この場合、使わなくなった腕を外して、新しいレゴブロックで作ったドリルを装着します。とても簡単に言っていますが、積み上げて作っているからこそ出来ることなのです。

次になぜ「小さく作って積み上げる」がデバッグしやすいのか。
障害が報告されました。どこに問題があるのか探すとします。
順次関数を呼び出すという作りになっているので、呼び出す関数の戻り値を順番に確認し、戻り値が異常になる関数を追っていけるので、異常個所の特定が容易になるのです。
この「小さく作って積み上げる」作り方以前は変数を追っていました。
１行づつ命令を走らせ、値が異常になる部分を特定する作業はとても根気と時間を伴う作業でした。

問題個所を直しました。テストしましょう。
「小さく作って積み上げる」で作った場合、単体テストは直した関数のみテストすればいいのです。だって、他の関数変更していないし。
小さく作っているので、修正した影響も限定的なので単体テストの範囲も限定されることになるのです。

「小さく作って積み上げる」方法のさらなるメリット

さらに「小さく作って積み上げる」という方法には複数の個所で同じ処理をする場合、関数を共有して使いまわしができます。
一度テストを通った関数と別の場所で呼び出す場合、呼び出した関数の製造・テストは行う必要がなくなり、開発コストが削減されます。

特にプロジェクトをまたいで利用できる共有関数のパッケージ、共有ライブラリは会社の資産です。帳簿に計上はされないけど。
共有ライブラリが充実すればするほど、開発コストは減っていくのです。だって基礎の部分の開発は終わっているのですから。

ということで、プログラムは「小さく作って積み上げる」。そして共有ライブラリは充実させるように開発しましょうね。というお話です。

プログラム開発者にとって幸いとなりますように。