読者数203人
[一覧を見る]
以前、「簡単コピー・プログラミングの罠 」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。
そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。
アプリケーションに固有の「業務ロジック（ビジネスロジック）」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想である。これには、開発期間の不足や業務面・技術面でのスキル不足など、多くの問題があるが、最もやっかいなのは、多くのプログラマがコピー・プログラミングを好むということである。
あるプロジェクトで共通機能（基底クラス）を作ったら、そのソースを部分的にコピーして使う人がいて、更にそれをコピーして作る人が出てきて、結局コピーだらけになったという例もある。これには「プログラマの管理がうまくいっていない」という指摘もできる。しかし、それ以前に、プログラマに「コピー・プログラミングへの抵抗感がない」ということが問題なのである。
実際、多くの職業プログラマを自由にしておくと、むしろ好んでコピー・プログラミングを行うようである。みんなコピー・プログラミングが大好きなのだ。
たしかに、チーム開発で共通化をしようと思うと、他のメンバーと相談して仕様を決めたり、あるいは他のメンバーの作った複数のソースを変更したりと面倒なことは多い。そういう役割の人（「共通チーム」などと呼ばれる）ならともかく、単なる「一機能の担当者」であるプログラマが、共通化のためにそこまでの労力を払うことは、まずないだろう。
コピー・プログラミングなら、誰にも気兼ねすることなく、自分の担当機能を作ることができる。多くの職業プログラマにとっての最優先課題は「自分の担当機能を動くものに仕上げること」であって、「ソースコードが美しいかどうか」などは二の次なのである。
私はこれまでコピー・プログラムには何度も痛い目にあってきたので、自分のプロジェクトでは、いかにして共通化を徹底するか（コピーさせないか）、ということに頭を悩ませてきた。しかし、多くのプログラマがコピーが大好きなのだとすれば、それを前提とした開発方法を考えるのも一興である。たとえば、以下のようなことだ。
あるいは、開発ツールの助けにより、コピー・プログラミングの品質向上が見込めるかもしれない。既存のツールでも、例えば、Visual Studio 等の統合開発環境で、アプリケーションの雛形を作ってくれる「ウィザード」や、「よくあるコード」を挿入してくれる「コードスニペット」は、「コピー指向」であると言ってもいいだろう。ソースコードを現在のようなテキスト形式のみで保存することに拘らなければ、他にも色々な対策はできそうだ。例えば、どのコードがどこへコピーされたか、ということをエディタが記録してくれれば、後から追跡することが容易になるだろう。
私も「同じことを何度も書くべきではない」という考え方を変える気はない。しかし、同じプログラマといっても、プログラミングについて誰もが同じように考えているわけではない。むしろ自分のようなプログラマは少数派なのかもしれない。そう考えると、日々の「悪態」も少なくなってくるのである。
■関連記事
・簡単コピー・プログラミングの罠
・簡単フレームワーク・プログラミングの罠
・スキルアップのためにラップを剥がしてみる
■程度の低いプログラマに、ソースコードは触らせなければ良いのでは？
> あるプロジェクトで共通機能（基底クラス）を作ったら、そのソースを部分的にコピーして使う人がいて、更にそれをコピーして作る人が出てきて、結局コピーだらけになったという例もある。
基底クラスって事は、結局フレームワーク的な、キモの部分だから、その部分のソースコードを、その程度のレベルの人に渡すのも如何かと思う。
コンパイル済みの物のみを提供して、そもそも継承して使わないとムリってレベルにすれば良いだけなのでは？