2008年09月27日(土)

コピー指向プログラミング

テーマ:コーディング

以前、「簡単コピー・プログラミングの罠 」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。


そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。


アプリケーションに固有の「業務ロジック(ビジネスロジック)」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想である。これには、開発期間の不足や業務面・技術面でのスキル不足など、多くの問題があるが、最もやっかいなのは、多くのプログラマがコピー・プログラミングを好むということである。


あるプロジェクトで共通機能(基底クラス)を作ったら、そのソースを部分的にコピーして使う人がいて、更にそれをコピーして作る人が出てきて、結局コピーだらけになったという例もある。これには「プログラマの管理がうまくいっていない」という指摘もできる。しかし、それ以前に、プログラマに「コピー・プログラミングへの抵抗感がない」ということが問題なのである。


実際、多くの職業プログラマを自由にしておくと、むしろ好んでコピー・プログラミングを行うようである。みんなコピー・プログラミングが大好きなのだ。



たしかに、チーム開発で共通化をしようと思うと、他のメンバーと相談して仕様を決めたり、あるいは他のメンバーの作った複数のソースを変更したりと面倒なことは多い。そういう役割の人(「共通チーム」などと呼ばれる)ならともかく、単なる「一機能の担当者」であるプログラマが、共通化のためにそこまでの労力を払うことは、まずないだろう。


コピー・プログラミングなら、誰にも気兼ねすることなく、自分の担当機能を作ることができる。多くの職業プログラマにとっての最優先課題は「自分の担当機能を動くものに仕上げること」であって、「ソースコードが美しいかどうか」などは二の次なのである。



私はこれまでコピー・プログラムには何度も痛い目にあってきたので、自分のプロジェクトでは、いかにして共通化を徹底するか(コピーさせないか)、ということに頭を悩ませてきた。しかし、多くのプログラマがコピーが大好きなのだとすれば、それを前提とした開発方法を考えるのも一興である。たとえば、以下のようなことだ。



あらかじめ完成度の高い「コピー元」を用意する

コピー元を品質の高いコードに集中させることで、「バグのコピー」や「似て非なるバージョンの散在」を防ぐ。



「コピーされたもの」が分かるようにする

例えば、コピー元のコードに特殊なコメントを埋め込む(もちろん、コピー先でも消さないでおく)などして、後からコピー先を検索しやすくする。これは、不具合修正や仕様変更などの際に、影響範囲(全てのコピー先)を特定しやすくするためである。



コピーしたコードは可能な限り変更しない

まず、コピー元はなるべく変更しなくてすむように作る。例えば、コピー先で関数名などがぶつからないように、ネーミングルールを作る。また、コピー先で無駄に変更することも禁止する。動作に影響のないからといってコーディングスタイルを自分流に変えたりしない。コピー先の記述の変更量が少なければ、コピー先の特定がしやすくなるし、記述の統一による可読性の向上にも繋がる。


あるいは、開発ツールの助けにより、コピー・プログラミングの品質向上が見込めるかもしれない。既存のツールでも、例えば、Visual Studio 等の統合開発環境で、アプリケーションの雛形を作ってくれる「ウィザード」や、「よくあるコード」を挿入してくれる「コードスニペット」は、「コピー指向」であると言ってもいいだろう。ソースコードを現在のようなテキスト形式のみで保存することに拘らなければ、他にも色々な対策はできそうだ。例えば、どのコードがどこへコピーされたか、ということをエディタが記録してくれれば、後から追跡することが容易になるだろう。



私も「同じことを何度も書くべきではない」という考え方を変える気はない。しかし、同じプログラマといっても、プログラミングについて誰もが同じように考えているわけではない。むしろ自分のようなプログラマは少数派なのかもしれない。そう考えると、日々の「悪態」も少なくなってくるのである。







■関連記事
簡単コピー・プログラミングの罠
簡単フレームワーク・プログラミングの罠
スキルアップのためにラップを剥がしてみる




アスペクト指向入門 -Java ・ オブジェクト指向から AspectJプログラミングへ
千葉 滋
技術評論社
売り上げランキング: 158663
おすすめ度の平均: 4.0
4 入門書として良く出来てます


初めてでもカンタン コピーするだけですぐに使えるJavaScript
立山 秀利
ローカス
売り上げランキング: 115209
おすすめ度の平均: 4.0
4 「とにかく今すぐ使いたい」と言う人向きです。
AD
いいね!した人  |  コメント(15)  |  リブログ(0)

コメント

[コメントをする]

15 ■ライブラリ設計のためのコピペ許容

逆に丸々コピペは禁止しておき、コピペしたことがわかるように自由にコピペ、改変させといて、後でコピペと改変の差分を集めると真に共通化すべき部分が見えてくる...てのはありそう。

「ちょっと違うのが欲しい」という場合が結構少なくないからね。

ライブラリやフレームワークの設計の困難さを分かってる人ならわかるはず。

14 ■はじめまして

lucy といいます。日記が面白かったのでコメント残させてもらいます。また寄らせてもらいますね^^

13 ■良い悪いの前に

みな さん、コメントありがとうございます。

HUNTER さんの仰るように、この記事の趣旨は、「コピーは悪」という話ではありません。むしろ逆で、「コピーは悪と考える人も、コピーを受け入れてみては?」と書いています。

つまり、kensir0u さんの意見とも近いことを言っているはずです。人材の教育と、プロジェクトの成功とは、往々にして両立しない。後者を優先するには、どうするか、という話なので。

もちろん、教育や個人のスキルアップの努力はしなくてよい、という意味でもありませんが。

12 ■とりあえずは、楽しましょ!

ほんとのコピペなら、後々大変なことになるのは目に見えているのだから。。。

まぁ、grepして同じコードを探せばいいことだが、修正箇所はまとまっているにこしたことはないですな。。

一部の仕様変更の影響範囲がつかみ辛く、広くなる弊害もあるにしても。

なんにしても、最初の設計次第です。

11 ■無題

努力も必要ですがビジネスでは結果が求められるわけです。
つまり納期が迫っている場合では成果物を挙げる
ということが最大限の努力であるわけで、現状のレベルを重々認識した上でそうしているわけです。

結果を出すために努力するのだと思いますが。
努力する必要があるため納期が遅れ、また品質が低下しています。というのはエゴというものです。
ということで絶対悪でない例を挙げたのですが・・・

10 ■久々に割込みっと…

> 全員がレベル高いPGではないので
 しかし
(職業PGであるならば)報酬を貰うわけですから
「そのままにしていても良い訳」でも無く
更に上のLevelを目指して努力すると思うんですが…

> ビジネスの上では絶対悪とは言えないと思います。
 必ずしも「悪い」と仰っている訳ではなく
良い部分を模索されている様に感じました
では、失礼

9 ■無題

こういう人はどうでしょう?

コピーしたら内臓バグ3個
自分で書いたらバグ10個

書いたほうが品質も、生産性も悪い

全員がレベル高いPGではないので
ビジネスの上では絶対悪とは言えないと思います。

8 ■皆さん、コメントありがとうございます。

デキる人ほどコピーがよくないことは知っていて、「程度の低い奴らにはソースコードを
提供しない」とか「コピー根絶」と、頑なに構えてしまいがちです。しかし、それで現実に
運用しようと思うと、難しいんです。

この記事で伝えたかったのは、逆に「コピーヲ抱擁セヨ」という発想もあるよ、ということ
です。「どうしてもコピーしちゃうよね、人間だもの。じゃぁ、コピーで上手く開発するに
はどうしたらいいか、考えてみよう」ということです。

もちろん、そういう考え方を既に持っていて、対策をとっている人もたくさんいます。
そういう人とっては「陳腐」な話でしょう。しかし、この記事で「はっ」とした人も
いるのではないかと思っています。

本文の「たとえば」のくだりは、あまりいい例を思いつかなかったので、実践的情報を
求めている方のご期待には添えません(このブログではいつもそうなのです)が、
はてブのコメントなども拝見すると、うまく対処されている方もあるようです。

「コピー指向言語」のような発展性も考えなくはなかったのですが、具体的なイメージが
できませんでした。色々と考えるきっかけになればと思います。

7 ■補足です。ごめんなさい。

『あらかじめ完成度の高い「コピー元」』
という表現を始め、コピーフリー志向というよりは、ライブラリ志向の亜種であると思ったので上記のようなコメントです。表現がたりなくてすみません。

6 ■ライブラリ志向を説くのなら

ライブラリ志向を説くのなら
まず先に
こういうケースの場合はコピーの方が優れているというケースを紹介して、それ以外はライブラリの方が良いという
ケースバイケースの場合分けを書いてくれないと
そりゃ、ライブラリの方が良い場合は良いでしょ?


で、どこか分水嶺なのか?という議論をみんなしているのにわかんないよ。

ってなっちゃいませんか?


コピー志向には、コピー志向の良いところが
ライブラリ志向にはライブラリ志向の良いところがあり


その配合がプログラマのマネージングの妙技だと思っているので。片方だけ紹介されても賛同はちょっとできないかな?
という感じです。ごめんなさい。

5 ■コピー指向言語

コピー指向ルールを守らせるなら
コピー指向言語があっても良い気がします。
親ソースからコピペしてきたら
自動的に差分を取ってうんたらかんたら
自然なコピー指向ルールを言語に組み込むという。

4 ■興味深く拝見しました

私がどうしてもコピーする場合は、どこからコピーしたかコメントに残すようにしています。可能なら、コピー元にもどこにコピーしたかを書き残します。
最近は類似コードを検索する技術も出てきたようなので、もう少しすればコピーしても問題にならなくなるかもしれませんが、それまでは、気をつけて行う必要がありますね。

3 ■無題

仮に陳腐だとしても未だにコピーは横行してるわけだから、コピー指向根絶のために努力はし続けるべきだと思う。
コピー新規で作る行為を「リスク分散」だと信じて疑わない上司にはほんと辟易します。

2 ■無題

今更こんな陳腐なことを語るなら、もいちょっと上の視点からいってほしかったな

1 ■程度の低いプログラマに、ソースコードは触らせなければ良いのでは?

> あるプロジェクトで共通機能(基底クラス)を作ったら、そのソースを部分的にコピーして使う人がいて、更にそれをコピーして作る人が出てきて、結局コピーだらけになったという例もある。

基底クラスって事は、結局フレームワーク的な、キモの部分だから、その部分のソースコードを、その程度のレベルの人に渡すのも如何かと思う。

コンパイル済みの物のみを提供して、そもそも継承して使わないとムリってレベルにすれば良いだけなのでは?

コメント投稿

AD

Ameba人気のブログ

Amebaトピックス

      ランキング

      • 総合
      • 新登場
      • 急上昇
      • トレンド

      ブログをはじめる

      たくさんの芸能人・有名人が
      書いているAmebaブログを
      無料で簡単にはじめることができます。

      公式トップブロガーへ応募

      多くの方にご紹介したいブログを
      執筆する方を「公式トップブロガー」
      として認定しております。

      芸能人・有名人ブログを開設

      Amebaブログでは、芸能人・有名人ブログを
      ご希望される著名人の方/事務所様を
      随時募集しております。