向かうべき方向性の決定権

僕は前に話したとおり、請け負いで仕事をしている。しかも今は客先常駐だ。つうことはある意味派遣であり、先方の指示を直接受けざるをえない事も多い。そしてまた、ペアプロの様になっているし、それ自体は悪いと思っていないから、他人の意見を尊重する。
でもさ、「その実装は当たり場的で奇麗じゃない」と言われることが多い。
そんなのお前に判断できるんか、と小一時間問い詰めたい。本当に仕事無視なら、マジ喧嘩腰。こっちは全体の情況を考え、妥協すべきところは妥協して、なおかつ綺麗な実装を考え、また後に続くものが間違いを犯さぬよう慎重に、そして経験を踏まえて考えて決めた実装方法だ。
自分の実装は批判を受けても曲げようとせず、相手のコーディングには文句たらたら。いくらこっちが寛容に受け入れようとしてもそれじゃ破綻する。
絶対最終的にはやろうと思っていることに、select文の実装がある。
元々SelectDataBeanというのを作ってあって、それなりに意味のある実装なのだが、PostgreSQL、Oracle、SQLServerに対応し、なおかつ今回行ロックをすべくfor update機能を実装した。
当然三者で共通のSQLで行ロックできる訳ではなく、今回はSQLServerだけはselect xxx from yyy with (xxxlock) where 〜とかやらなきゃならなかった訳で。そうなると、factoryメソッドを使ってその部分は実装するという意見があり、「確かに」と納得。
が、ここで問題。彼が実装してくれたメソッドでは、distinctには対応しない。しかも彼が実装したのは、ぜんぜんかけ離れたpackageであって、依存関係があまりにも悲惨だ。更には、そのfactoryメソッドを呼び出すために、5行程度のおまじないを書かなければならないという。
そこで私の意見。こんなメタメタな、問題が多い機能結合なら、全てをfactoryに任せることとし、for updateをつけない普通のselect文もfactoryメソッドで定義、そしてdistinctもそこで実装。そしてパッケージはBIOSに類する層で定義する、最後におまじない行はそっち側でデフォルトとして処理する、それならOKという意見であった。
結局彼の意見が通され、そしてfor updateについてはdistinctは無効となるという、classのインターフェースを見ただけでは当然に間違えてしまうというモノが出来上がってしまった。
これこそ、後に続く者が間違えないよう、きちんと実装すべきであるし、意味のない制限は設けるべきではない。そしてfactoryメソッドで実装する必要のないものであっても、網羅性において実装したほうが素直ならば実装すべきだ。そして、その際にパッケージ位置が適当でなくなったならばちゃんとした位置に持っていくべきだ。その点では未だ彼とは合意できてない。