無駄を省こう |
||
|
みんな一緒? |
||
|
みんなで同じもの作っているということはありませんか? |
|
ありがちなのは、データの格納形式のみを取り決めて、入力側と出力側を別の人が作るというような場合ですね。これだと同じ形式のデータ構造に関するコーディングが複数必要になってしまいます。入出力が1回だけならまだ良いですが、もしあちこちで読み込まなければならないデータだとしたら、いったい何人が同じものを作ることになるでしょう。これをひとまとめにして、作る量を減らす方法はすでに述べました。 |
||
|
さて、同じような処理をひとまとめにすることで、どのような良いことが起こるのでしょうか? |
||
|
第1に、開発効率が上がります。作る量が減るからです。当たり前です。 |
||
|
第2に、メンテナンス性が向上します。例えばバグが発見されたとき、同じような処理があちこちに散らばっていると収拾がつきません。どの機能も1カ所にしか存在しないという状況を作っておくことで、修正が簡単になります。もちろん改造や拡張のときも同じことが言えます。 |
||
|
第3に、コンポーネント化できる可能性があります。あちこちで使われる機能をひとまとめにするという作業は、その機能のエッセンスを抜き出すということです。そういう部分は、全然内容の異なるほかのプロジェクトでも通用するほど一般化できる可能性があります。オブジェクト指向に基づいた開発を行っている場合は、とくにコンポーネント化できる可能性が高いでしょう。 |
||
誰かがやる |
||
|
ここで述べたようなことは、腕のあるプログラマーなら自然に行っていることでしょう。しかし、各自が個別に行っても、たいした成果はあげられません。設計の段階で共通部分を見つけだし、効率的な戦略をチーム全体に適用しなければなりません。つまり、だれかが共通部分を作らなければなりません。もちろんすべての共通部分が設計の段階で見つかるとは限りませんから、コーディングの段階で発見された共通部分を設計にフィードバックすることも必要です(これは設計者がチームに所属している方が良い理由のひとつです)。 |
||
|
--- 設計とは、節約なり --- |
||
|
設計でもっと無駄を省きましょう。時間と労力を節約して、効率的に仕事をこなしましょう。 |
||
|
|
|
|
(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)