こうしてゴミソースは繁殖する

元ネタ
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=41464&forum=7
http://blogs.wankuma.com/jeanne/archive/2007/10/11/101389.aspx

一度提供したクラスやクラスのシグネチャは変更してはならない。という原則があります。しかし、
一度作成し提供した Method_A(int,int) を改変してMethod_A_Ex(int,int) を作った場合、Method_A()をMethod_A_Ex()に一斉に変更せよと通達を出すのはよくあることです。その時点でMethod_Aは死ぬので破棄していいと思うのです。ところが、Method_A()が過去の異なるプロジェクトで作成したものであったら怖くて消せないです。
別のケースでは必要でないのに使うかもしれない、あれば便利だろうという親切心から作成する開発者がいたりします。(以下の例はジェネリックが普及する以前と思って下さい。)
Method_C(int,int); を作った開発者は、このルーチンは他の型でも使えると考えて、Method_C(long,long), Method_C(double,double) と類似のMethodを複数個作成した。しかし使われるのは Method_C(int,int)のみであって、Method_C(long,long)とMethod_C(double,double)は使われることはなかった。
後日指摘すると、使うかもしれないので作って置いたと言う。
別の例では、Method_A()のロジックの出来が不満足で改良した際に変更前のMethod_A()をMethod_A_Old()とrenameし新たにMethod_A()を作り、Method_A_Old()は残骸として残存して月日が流れて、だれも怖くて削除できなくなった。
　コードレビューを実施する部署は多いですが、納品物のソースを隈なくチェックすることは出来ないです。作り手の姿勢に依存するのでしょうね。
　使うかも知れない、後日必要になるかもしれない.......まず使われることはありません。
そのようなコードは個人のFileに格納しておいて、変更依頼があれば引き出すようにすればよいのでは。
いずれにしてもソースを汚すも汚さないも人次第なので、前近代的な産業だなぁって思います。

投稿日時 : 2007年10月11日 13:14

Feedback

# re: こうしてゴミソースは繁殖する 2007/10/11 13:20 凪瀬

イマドキはIDEで使用の可否をチェックできるようになったので、適時リファクタリングでバッサリ斬ることが多くなりました。
どうせバージョン管理されてるんだし、大規模改修の際にはどうせ全体の結合テストするんだし、リスクは最小限じゃん、と思うのですよね。
むしろ整理しないことによるリスクを自分は重く見ていますが、この辺は感性によるのかな。

# 不要なメンバを救う会。 2007/10/11 13:21 拝啓、さかもとと申します

http://blogs.wankuma.com/jeanne/archive/2007/10/11/101389.aspx http://blogs.wankuma.com/rti/archive/2007/10/11/101400.aspx

# 不要なメンバを救う会。 2007/10/11 13:21 拝啓、さかもとと申します。

不要なメンバを救う会。

# re: こうしてゴミソースは繁殖する 2007/10/11 13:35 まどか

> Method_C(int,int); を作った開発者は、このルーチンは他の型でも使えると考えて、
> ・・・・・と類似のMethodを複数個作成した。
> しかし使われるのは・・・・・は使われることはなかった。

いわゆる規模や保守を考えると必要最小限という考え方はでてくるかと思います。
一方、OOのみの観点ではそれがクラス設計の抽象化された結果であればなんら問題は無いと思います。
クラス設計の時点で利用者は存在しませんから。

そういう意味でゴミとは
・品質がゴミ
・プロジェクト独自の思想によるゴミという判断
のいずれかになるのではないでしょうか。

# re: こうしてゴミソースは繁殖する 2007/10/11 13:59 かつのり

自分の場合ですが、
業務ロジックの類は必ずインターフェイスを前段にかませるようにして、
利用クラスが直接業務ロジックの実装クラスのメソッドを利用しません。

なので、インターフェイスのメソッドは無理ですが、
インターフェイスを持たないメソッドは、
大抵副作用なしでバッサリ切り捨てられます。
逆に副作用があれば、それは実装クラスのメソッドを直接利用しているからで、
それは行儀の悪いプログラムということにして、利用者の責任としています。
例えばsun.xxxで始まるパッケージのクラスを使って、
JDKのバージョンが変わった時に動かなくても、
Sunに文句言わないですよね。それと同じことです。

クラス内で閉じているprivateなものは、Eclipseなら警告を出せるし、
クリーンという処理を実行すれば副作用なしで自動削除もしてくれますよ。

# re: こうしてゴミソースは繁殖する 2007/10/11 16:12 Ognac

>むしろ整理しないことによるリスクを自分は重く見ていますが、この辺は感性によるのかな。
>いわゆる規模や保守を考えると必要最小限という考え方はでてくるかと思います。
私は(も?)呼ばれない処理の存在はゴミにしかみえません。

>一方、OOのみの観点ではそれがクラス設計の抽象化された結果であればなんら問題は無いと思います。
基底クラスとなるクラスは汎用性を考慮してあったらいいな的なメンバーの存在はOKです。
話の前提が基底の場合と業務アプリ其の物の場合の2分してないと話がややこしくなりますね。業務アプリ其の物を想定してました。失礼しました。

>・品質がゴミ
>・プロジェクト独自の思想によるゴミという判断
意味深な分類。使わせてもらおぅと。

>それは行儀の悪いプログラムということにして、利用者の責任としています。
>クリーンという処理を実行すれば副作用なしで自動削除もしてくれますよ。
その方面でもEclipseが進んでますね。

これらのゴミは生ゴミですね。

「コードに修正を加えるときは、修正前の状態をコメントアウトして残しておく」という化石みたいなコーディング標準が残っている会社が現存します。ソースセーフかCVSを使っていながら..... 可読性が悪化する一方だとぐちってました。

こちらは廃棄ゴミだなぁ。

# re: こうしてゴミソースは繁殖する 2007/10/11 16:15 凪瀬

> コードに修正を加えるときは、修正前の状態をコメントアウトして残しておく

ありますねー。
そんなことを言う管理者にはバージョン管理ソフトの存在意義を
説教部屋でみっちり叩き込んでやりたくなります。
目的(履歴管理)が忘れられて手段(コメントアウト)が残ったケースも多いとは思いますが。

# re: こうしてゴミソースは繁殖する 2007/10/11 17:05 かつのり

以前VBで、
'''''''200x-x-x author del begin
この間数千行
''''''200x-x-x author upd begin
この間数千行
''''''200x-x-x author upd end
この間数千行
'''''''200x-x-x author del end
見たいなのを見た。

コメントと呼ばれてないprivateな部分を全部消したら、
100行ぐらいになりましたｗｗ

# 不要なメンバを削除する 2007/10/12 1:05 かつのりの日記２

不要なメンバを削除する

タイトル		タイトルを入力してください
名前		名前を入力してください
Url
コメントコメントを入力してください
名前をブラウザに記憶する