納品前にインタフェースが変わるようなリファクタリングをしないでくだされ

カッとなったので書く。ただの愚痴です。

public static CalcResult execute(int i1, int i2, Param1 p1, Param2 p2){
   ...
}

みたいなJavaのコードがあった。そこそこ汎用的に使えるようにつくろうとしているライブラリだが、引数の数が多いし、そもそもParam1とParam2が分かれているのがなんか変だよねという話になり、リファクタリングして次のようにしたらしい。

public static CalcResult execute(int i1, int i2, Param1 p1){
   ...
}

Param1の中にParam2を入れただけ。急ごしらえだったようでこのメソッドを呼ぶ手前でp1.setParam2(p2)みたいなことをする必要があるとのこと。まあこれはこれでよかった。カッとなったのはこの後。

当然、このクラスメソッドには利用者がいる。といってもせいぜい1,2箇所なので修正しようと思えばすぐできる。

すぐできるんだけど、私はすでにそのライブラリを利用するプログラムソースの納品作業を終えていて、できれば弄りたくなかったので、「引数が4つだったもともとのやつもオーバーロードして残しておいてもらえませんか。@Deprecatedとかつけといてください。」みたいなことをお願いした。

「えーめんどくせえｗｗｗ」という反応だった。それはこっちのセリフである。納品前に破壊的な変更をしないでほしい。

結局のところ、オーバーロードの意味が伝わらなかったのか、はたまた@Deprecatedが何のことか分からなかったのか、変数4つのメソッドは作られることなく納品されていった。私のコードも、修正前のライブラリのjarを一緒にzipで固めて納品した。

納品と言っても社内の成果報告的なやつだし、結果的に私の最初に作った納品物は修正の影響を受けずに済んだので騒ぎ立てるのはオーバーなんだけど、私は大変もにょもにょしている。このきもちはなんだろう。