文系プログラマによるTIPSブログスマートフォン用の表示で見る文系プログラマによるTIPSブログ文系プログラマ脳の私が開発現場で学んだ事やプログラミングのTIPSをまとめています。既存のコードを参考にして新規にコードを書く事の光と闇2015-09-13既存のコードを参考にして新規にコードを書く事の光と闇IT業界TwitterGooglePocket恐らくこれは開発現場であるあるな出来事だと思います。今回のお題は「既存コードを参考にして新規コード書く」事についてです。あなたが部下または外部の方に作業依頼をする時、どんな風にコードを書いたらいいかを事前に説明しますね。その時「この辺に書いてある既存のコードを参考に書いて下さい」と言ったりしますよね。書き方の方針を伝えない場合は、依頼された側が「既存のこの辺のコードを参考に書きます、書きました」と言ったりします。「参考」とはこの言葉のポイントは「参考」という部分にあります。実はこの「参考」には光と闇が潜んでいるのです。この「参考」は、大抵の場合は「ほぼコピペ」を意味しているからです。「ほぼ」と言っているのは、数カ所違うだけのコピペの場合が多々あるためです。コピペのメリット周りのコードの書き方と足並みを揃える事ができる。バグが混入しづらくなる(かもしれない)。新規にコードを書くより速く書ける(かもしれない)。コピペのデメリット元にしたコードを書いた人の技量が低い場合、低品質なコードが量産される事になる。元にしたコードが書かれた時とほぼ同じコードが書かれてしまい、全く進歩が無く、効率化が測れない。似たようなコードが量産されてしまい、後々メンテがしづらくなり、融通が全く効かないコードが出来上がる。元にしたコードの問題(バグ・低性能・低効率)をそのまま別箇所に移植・量産される。元にしたコードが何をしている・したいのか、を考えなくなる。コピペして動けばいいと考えるようになる。DRY原則を簡単に破壊してしまうコピペは凶悪な存在です。破壊している事にすら気づいていない場合もあるので怖いです。メリットの「バグが混入しづらくなる」点は、開発のリーダー的存在が不在になってしまい、派遣社員一人で開発をしている場合はよく既存コードを参考に書かれます。下手に新規コードを書いてリスク(自分の知らない裏仕様等)を負うよりも、既存の仕組みを使ってリスクを回避する、という意味では正しいと思います。納期が厳しい時に既存コードをほぼコピペして納期に間に合う確率を少しでも高めるという方法は間違っていないと思います。実際よくあるのではないでしょうか。この光の部分を見ていられる期間は非常に短く、あっという間に手に負えない程の巨大な闇へと変貌してしまいます。コピペの闇の部分コピペは究極の思考停止であると思います。コピペ元のコードが何をしているのか、何がしたくてそう書いたのか、を考えなくなります。最初は考えていても、コピペの数が増えるにつき思考は停止し、量産する事しか頭に無くなります。量産の代償として、メンテ難易度の上昇、バグの誘発、メンテコストの上昇を招きます。その結果、チームの負の感情が渦巻くようになり、逃亡・放棄という最悪の結果を招きます。自分で何かを生み出す機会も生まれない(機会があってもコピペ元を探そうとして実際コピペしてしまう)ため、自分で何かを生み出すスキルが身につきません。元になる何かが無いと何もできない人間ができあがります。目先のリスクを回避するために、後々に大きな代償を払う事になるのがコピペです。「代償を払う?その現場から逃げればいいじゃんwww」と考えても無駄です。その現場に負の遺産を残して迷惑をかけますが、コピペ当事者にもしっかり負の遺産ができあがっています。前述した「思考停止」「元になるものが無いと何もできない」という遺産が積み上がり、以下のような負のループに嵌って抜け出せなくなってしまうでしょう。メンテコストが増大する。メンテに時間がかかって残業が増える。給料・単価が挙がらない。給料挙がらないし残業ばっかで辛い。