簡単コピー・プログラミングの罠

既存の処理とよく似た処理を作成する場合、ソースコードをコピーして流用することがある。リーダーからそういう指示が出された経験のあるプログラマも多いだろう。

しかし、そういう場合は注意してもらいたい。

コピーしてきたコードは、何箇所か修正すると思う。しかし、そのうちのいくつかを修正し忘れてしまう、というミスが本当に多いのだ。

修正作業自体は、変数名や関数名を置き換えるとか、条件式をちょっとだけ変更するとかいった簡単なものだろう。しかし、そういう簡単なものほど、漏れがあっても気がつきにくいものである。

また、このようにコピーしたコードは、直し忘れがあっても、コンパイルエラーや実行エラーが出にくい場合が多い。あるいは、動作実績のあるソースを流用している、ということで、作業者の気が緩んでしまうということもあるかもしれない。

ゼロの状態からプログラミングする場合には、コードを少し書いてはコンパイルし、動作を確認していく。少しずつ確認することで、品質の高いものが出来るのである（※１）。しかし、ソースコードを流用する場合、そうした地道な確認作業は発生しない。これもケアレス・ミスが発生しやすい原因かもしれない。

★

コピー・プログラミングの危険は、流用の際のミスだけではない。本当に危ないのは、その後である。

コピーされた処理にバグが見つかったり、仕様変更などでその処理を修正しなければならないときのことを考えてほしい。コピー部分の処理を修正する場合には、当然、コピーされた全ての処理を同じように修正する必要がある。

過去にコピー・プログラムに悩まされたことのあるプログラマであれば、他にもコピーされた箇所がないかどうかを疑い、検索して全てを修正してくれるかもしれない。しかし、あなたの周りにいる全てのプログラマが、必ずそのような措置をしてくれるだろうか？

★

一般に、同じ処理を流用したいような場合、その処理を共通化させて、複数の箇所から呼び出せるような形に変更（リファクタリング ※２）するほうがよい。ここでは詳しくは書かないが、共通化する技法は、色々ある。同じシステム内の共通化であれば、それほど難しくはないし、違うシステムであっても、ライブラリ化すれば可能である。

また、似たような機能を大量生産するようなシステムでは、最初から「どうすればソースをコピーせずに量産できるのか」ということについて頭を悩ませるべである。さもなくば、コピーだらけのソースコードになってしまうだろう。

★

とはいうものの、コピー・プログラミングを撲滅することは難しい。

既存のシステムを修正する場合などでは、稼動実績のあるソースを変更したくない、ということもある。また、緊急のバグ対応などでは、リファクタリングをするほどの時間が取れない、ということもある（※３）。

このような場合には、やむをえずコピーによる流用を行うこともあるだろう。しかし、そういった場合でも、流用したことコメントに残しておく程度の配慮はしておきたい。

間違っても、「コピーすれば簡単だ」などという安易な考え方は持たないほうがいい。むしろ、新しく作り上げる時よりも、慎重に作業をしてもらいたいのである。

応援のクリックお願いします →