カットアンドペーストでプログラミングするやつらを「ぺたぺただん」と呼ぼう

公開日時：: 2007/01/04 17:59
著者：: danjo

コメント(7)

ブックマーク(-)

最近、仕事の関係で２つのJavaのコードをさわった。同じような目的の処理に対して、
全く違うアプローチをとっている点が面白かったので感想と提案をしてみる。

プログラムは両方ともバッチ処理で、データベースとファイルの間で入出力を行う

ためのものだった。私はそれぞれのプログラムの検収と機能追加を行った。

プログラムの概要は以下。

DBとファイルの間でデータの入出力を行う
類似した処理が複数ある（対象テーブルが違うが同じような処理が必要）
Javaで実装

実装に要求される詳細な用件は違うものの、基本的なロジックは同じものになる。

このプログラムに対して、２人の技術者が開発を担当した。

技術者の特徴は以下。

技術者A
- プログラム開発の経験豊富
- 技術的なトピックについての知識欲旺盛
- スクラッチから作成
技術者B
- プログラム開発の経験少ない
- 技術的なバックグラウンドはなし
- 別の開発者Cが以前作成したプログラムを流用して作成

上記技術者A、Bが作成したプログラムX、Yの概要は以下。

バッチX
- プログラム内の機能別に適切に設計されたクラス設計
- SQLはJavaソースとは別の定義ファイルに記述
- DBアクセスについてはDAO用の数クラス、数メソッドのみを作成
  (JavassistによりDAOクラスのメソッド呼び出しをフックし、メソッド名から定義ファイル内のSQLを取得する)
- レコード内容は対象テーブルの定義によらず同一クラスのインスタンスに格納
  (BeanUtilsのLazyDynaBeanを使用)
バッチY
- １クラス、mainメソッドのみで実装
  
  （全対象テーブルを一発処理）
- 同じ処理の繰り返しをJavaコードの繰り返しで記述
- SQLはコード内で固定で記述。
  （文字列連結でSQLを組んでいるため、SQLの検証も面倒）

検収の段階では、X,Yとも機能に対する要求は満たしているのでその点で差はないと思う。

（実は開発範囲が広いXの方がバグ総数は多かった）

次に私がX,Yに対して機能追加を行ったのだが、Xの内容は勉強にもなるので読んでいくのが楽しかった。

そしてYのプログラムはもう見たくないと思った。

さて、今回提案したいのは、バッチYのようなプログラムを私達はもう見たくないので、それを減らしていくために社会的にマイナス方向のインセンティブをあたえていくのがいいんじゃないかということだ。

手段としては、特定のコーディングパターンに対してカッコわるい名前づけを行うことはどうだろうか。

（例：暴走族→珍走団）

上記のバッチYの例でいえば、「同じ処理の繰り返しをコードの繰り返しで記述」というのはカットアンドペーストで

プログラムを作ったのだろう。そういうプログラムを書いたプログラマを「ぺたぺただん」と呼ぼう。

きっと彼らは次の開発のときはぺたぺたしないはずだ。

※このエントリは CNET Japan ブロガーにより投稿されたものです。シーネットネットワークスジャパンおよび CNET Japan 編集部の見解・意向を示すものではありません。

ログインしてコメントするこのエントリを評価する

運営事務局に問題を報告この記事についてブログを書く（ブロガー専用）

このエントリーへのコメント

haruomitroiさんこんにちは。よろしくお願いします。

社内標準化という話ですと、それが行えていないのは私の力量不足ですね。恐縮です。

ところで、haruomiさん場合はそのような事象はありましたでしょうか。差し支えなければ、良い実装を社内標準にこぎつけるまでのプロセスについて教えていただければと思います。

danjo on 2007/05/30

プログラマXさんの仕事にしても、「ものすごく」高度な内容ではないように思うのですが、なぜそれがさっさと標準化と研修の対象にされてしまわないのか、それが「名人芸」のように思われているという現状が貧しいと思います。

haruomi on 2007/05/30

danjoさん
ご回答ありがとうございます。

なるほど。理解しました。
まったく反対の状況を経験したのでブログ内の状況を正しいとは思えず、聞いてみました。
立場によって見方は大きくかわると思いますし、言語によっても違います。
今回はバグをつぶすことに主眼を置いた内容であれば、可読性を重視されるべきでしょう。
バグは作ったもっとも理解しているはずですので、作った側の主張も聞いてみるともっと理解が深まりそうですね。

ソースコードのコピーに関して言わせていただくと、そそまま動くコードを使えるような内容であればそれほど問題ないんじゃないでしょうか？

問題はコピー＆ペーストでできてしまうことにあると思いますが、そこは設計者に聞いてみたいところですね。

troi on 2007/01/31

troiさんこんにちは。今後ともよろしくお願いします。

＞どんなに優秀でもバグをつくったら仕事にならないと思いますが、いかがでしょう？
バグの内容や仕事の内容にもよるのかなと思います。
今回の件では私は検収する立場でしたので、リリースまでにバグを潰せれば問題はないので
バグのありなしよりも、バグが見つけられること、修正できることを重要に考えていました。
もし私が利用者の立場なら、あるバグのために仕事にならないこともあるかと思います。

＞”コーディングが汚い”=悪いプログラム　とはならないと思いますが、どのようにお考えですか？
コーディングが汚いのは悪いことだと思います。ただ、「悪い」と言う言葉は広い意味合いのある言葉なので、
たとえコーディングがきれいでも、汚いそれよりも悪い場合はあると思います。
深刻なバグを含む場合などはそうでしょうね。

danjo on 2007/01/30

どんなに優秀でもバグをつくったら仕事にならないと思いますが、いかがでしょう？
”コーディングが汚い”=悪いプログラム　とはならないと思いますが、どのようにお考えですか？

troi on 2007/01/30

>流れがちゃんと把握できてメンテしやすければコーディングスタイルだわる必要はないと思ったりします。

その通りですね。ただ私の思いとしては、長期間的にみてそれがわかる目を養うためにコーディングに"楽しさ"を探していくことは大事だと思います。
#楽しさを仕事より優先してしまっては本末転倒です。

danjo on 2007/01/14

実際にコードを共有してるわけじゃないし、コード量も違うと思うので、全てがそうとは言いませんが、以外とカットアンドペーストプログラミングも悪くないですよ。

理路整然にクラスやインターフェースを作り込みすぎて、階層化しすぎてEclipseなどのツールがないと追えないプログラムになってしまったり、結局、微妙に引数が違う個別メソッドが大量生産されていくだけとか。もしくは汎用性重視しすぎて使いにくいメソッドができたりとか。

要は流れがちゃんと把握できてメンテしやすければコーディングスタイルにこだわる必要はないと思ったりします。

（楽しい、という文脈が危険なんですよね。さして再利用もないコードで、正規化するのが仕事じゃないのに、とか。）

えふしん on 2007/01/13