2004年10月29日(金)
簡単コピー・プログラミングの罠
テーマ：コーディング
既存の処理とよく似た処理を作成する場合、ソースコードをコピーして流用することがある。リーダーからそういう指示が出された経験のあるプログラマも多いだろう。
しかし、そういう場合は注意してもらいたい。
コピーしてきたコードは、何箇所か修正すると思う。しかし、そのうちのいくつかを修正し忘れてしまう、というミスが本当に多いのだ。
修正作業自体は、変数名や関数名を置き換えるとか、条件式をちょっとだけ変更するとかいった簡単なものだろう。しかし、そういう簡単なものほど、漏れがあっても気がつきにくいものである。
また、このようにコピーしたコードは、直し忘れがあっても、コンパイルエラーや実行エラーが出にくい場合が多い。あるいは、動作実績のあるソースを流用している、ということで、作業者の気が緩んでしまうということもあるかもしれない。
ゼロの状態からプログラミングする場合には、コードを少し書いてはコンパイルし、動作を確認していく。少しずつ確認することで、品質の高いものが出来るのである（※１）。しかし、ソースコードを流用する場合、そうした地道な確認作業は発生しない。これもケアレス・ミスが発生しやすい原因かもしれない。
★
コピー・プログラミングの危険は、流用の際のミスだけではない。本当に危ないのは、その後である。
コピーされた処理にバグが見つかったり、仕様変更などでその処理を修正しなければならないときのことを考えてほしい。コピー部分の処理を修正する場合には、当然、コピーされた全ての処理を同じように修正する必要がある。
過去にコピー・プログラムに悩まされたことのあるプログラマであれば、他にもコピーされた箇所がないかどうかを疑い、検索して全てを修正してくれるかもしれない。しかし、あなたの周りにいる全てのプログラマが、必ずそのような措置をしてくれるだろうか？
★
一般に、同じ処理を流用したいような場合、その処理を共通化させて、複数の箇所から呼び出せるような形に変更（リファクタリング ※２）するほうがよい。ここでは詳しくは書かないが、共通化する技法は、色々ある。同じシステム内の共通化であれば、それほど難しくはないし、違うシステムであっても、ライブラリ化すれば可能である。
また、似たような機能を大量生産するようなシステムでは、最初から「どうすればソースをコピーせずに量産できるのか」ということについて頭を悩ませるべである。さもなくば、コピーだらけのソースコードになってしまうだろう。
★
とはいうものの、コピー・プログラミングを撲滅することは難しい。
既存のシステムを修正する場合などでは、稼動実績のあるソースを変更したくない、ということもある。また、緊急のバグ対応などでは、リファクタリングをするほどの時間が取れない、ということもある（※３）。
このような場合には、やむをえずコピーによる流用を行うこともあるだろう。しかし、そういった場合でも、流用したことコメントに残しておく程度の配慮はしておきたい。
間違っても、「コピーすれば簡単だ」などという安易な考え方は持たないほうがいい。むしろ、新しく作り上げる時よりも、慎重に作業をしてもらいたいのである。
※１
全く動かさずに全てのコーディングする人もいるが、個人的にはあまりおすすめしない。
※２
「リファクタリング」はプログラムの動作を変更せずにソースコードを変更すること。
※３
これは、「テスト・ファースト」を導入すれば、改善することが出来る。
■関連記事
・ソースコードの盗み方
・簡単フレームワーク・プログラミングの罠
面白くて勉強になります
開発者～管理者まで参考になる
良い本だと思うけど星３つの訳
文句なしに良書
しかし、そういう場合は注意してもらいたい。
コピーしてきたコードは、何箇所か修正すると思う。しかし、そのうちのいくつかを修正し忘れてしまう、というミスが本当に多いのだ。
修正作業自体は、変数名や関数名を置き換えるとか、条件式をちょっとだけ変更するとかいった簡単なものだろう。しかし、そういう簡単なものほど、漏れがあっても気がつきにくいものである。
また、このようにコピーしたコードは、直し忘れがあっても、コンパイルエラーや実行エラーが出にくい場合が多い。あるいは、動作実績のあるソースを流用している、ということで、作業者の気が緩んでしまうということもあるかもしれない。
ゼロの状態からプログラミングする場合には、コードを少し書いてはコンパイルし、動作を確認していく。少しずつ確認することで、品質の高いものが出来るのである（※１）。しかし、ソースコードを流用する場合、そうした地道な確認作業は発生しない。これもケアレス・ミスが発生しやすい原因かもしれない。
コピー・プログラミングの危険は、流用の際のミスだけではない。本当に危ないのは、その後である。
コピーされた処理にバグが見つかったり、仕様変更などでその処理を修正しなければならないときのことを考えてほしい。コピー部分の処理を修正する場合には、当然、コピーされた全ての処理を同じように修正する必要がある。
過去にコピー・プログラムに悩まされたことのあるプログラマであれば、他にもコピーされた箇所がないかどうかを疑い、検索して全てを修正してくれるかもしれない。しかし、あなたの周りにいる全てのプログラマが、必ずそのような措置をしてくれるだろうか？
一般に、同じ処理を流用したいような場合、その処理を共通化させて、複数の箇所から呼び出せるような形に変更（リファクタリング ※２）するほうがよい。ここでは詳しくは書かないが、共通化する技法は、色々ある。同じシステム内の共通化であれば、それほど難しくはないし、違うシステムであっても、ライブラリ化すれば可能である。
また、似たような機能を大量生産するようなシステムでは、最初から「どうすればソースをコピーせずに量産できるのか」ということについて頭を悩ませるべである。さもなくば、コピーだらけのソースコードになってしまうだろう。
とはいうものの、コピー・プログラミングを撲滅することは難しい。
既存のシステムを修正する場合などでは、稼動実績のあるソースを変更したくない、ということもある。また、緊急のバグ対応などでは、リファクタリングをするほどの時間が取れない、ということもある（※３）。
このような場合には、やむをえずコピーによる流用を行うこともあるだろう。しかし、そういった場合でも、流用したことコメントに残しておく程度の配慮はしておきたい。
間違っても、「コピーすれば簡単だ」などという安易な考え方は持たないほうがいい。むしろ、新しく作り上げる時よりも、慎重に作業をしてもらいたいのである。
応援のクリックお願いします → 
※１
全く動かさずに全てのコーディングする人もいるが、個人的にはあまりおすすめしない。
※２
「リファクタリング」はプログラムの動作を変更せずにソースコードを変更すること。
※３
これは、「テスト・ファースト」を導入すれば、改善することが出来る。
■関連記事
・ソースコードの盗み方
・簡単フレームワーク・プログラミングの罠
アンチパターン―ソフトウェア危篤患者の救出
posted with amazlet
on 06.04.01
W.J. ブラウン 3,Hays W. McCormick Raphael C. Malveau
Thomas J. Mowbray 岩谷 宏(訳)
ソフトバンククリエイティブ (2002/07)
売り上げランキング: 70,471
Thomas J. Mowbray 岩谷 宏(訳)
ソフトバンククリエイティブ (2002/07)
売り上げランキング: 70,471
おすすめ度の平均: 
STL―標準テンプレートライブラリによるC++プログラミング 第2版
posted with amazlet
on 06.04.01
ディビッド・R. マッサー アトゥル サイニ ギルマー・J. ダージ 滝沢 徹(訳) 牧野 祐子(訳)
ピアソンエデュケーション (2001/12)
売り上げランキング: 29,555
ピアソンエデュケーション (2001/12)
売り上げランキング: 29,555
おすすめ度の平均:
■同感です
はじめまして。
あっさり動いてしまったコードに限って、問題が埋もれてしまってたりするんですよね。
私の場合はある程度機能が見渡せる時は流用しますが、不安に思う時は新規に書いてしまったりします。
でも忙しい時は安易に流用してたりするかな。。
プログラミングのエッセンスがいっぱいで楽しいページですね。
またおじゃまさせていただきます。
それでは。