元ネタ
http://blogs.wankuma.com/ognac/archive/2007/10/11/101444.aspx
http://blogs.wankuma.com/jeanne/archive/2007/10/11/101389.aspx
Ognacさんのエントリのコメントにも書いたのですが、自分がJavaでやる場合の話です。
メソッドを副作用なしで削除するということですが、自分の場合は事前に設計段階で考慮します。業務アプリでもフレームワークでも同じなのですが、実装クラスは極力隠蔽してインターフェイス経由で利用させます。特にレイヤーを跨ぐ場合は必須です。
例えばレイヤーモデルを採用したWEBアプリの場合、ビュー層、ビジネスロジック層、データアクセス層というようにレイヤーが分かれますが、ビュー層からはビジネスロジック層の実装クラスを直接利用するのではなく、ビジネスロジックインターフェイスを経由して利用します。ビュー層が直接ビジネスロジック層の実装クラスを参照しないようにDIコンテナなどにインジェクションしてもらうのがベストでしょう。
インターフェイスに書かれているメソッドは公開しているものです。ですので利用しているかもしれないという事を考慮して絶対に削除しません。せいぜい@Deprecatedを指定して、「使うな」というのを指示する程度です。インターフェイスに書かれているメソッドは公開している以上、呼び出しても問題ないということを保障しなければなりません。
逆にインターフェイスに書かれているメソッドを保障する分、非インターフェイスのメソッドは例えpublicであっても直接利用することを許してはいけません。そのメソッドが使われていようと、使われていなかろうと、お構いなしで削除してOKとしています。削除されて困るなら直接利用するなという考え方ですね。
ですので、非インターフェイスのメソッドについては認知しているドメイン内で副作用がないと確認できれば、どんどん削除します。逆にインターフェイスのメソッドについては何が何でも維持します。仮に削除したいのであれば、空実装にして@Deprecatedを指定します。
でもこれって極当たり前じゃないかと思っています。JDK自体のコードも大体そんな感じです。
privateなメンバになればEclipseの機能で未使用であると警告を出す事ができます。沢山未使用なものがあれば、Eclipseの場合クリーンコマンドで一括削除する事もできます。未使用なので当然副作用なしで自動削除ができます。
そもそも自分の場合、コードのルールを厳しくして書いているので、最初から未使用コードに対するエラーが出てきます。なので殆どクリーンコマンドで一括削除なんてやったことがないというのが現実ですね。