ダメなコードをリファクタリングでダメなコードに・・・

他人のコードをコーディングガイドに合わせて書き直すのがこんなにストレスが溜まるものだとは・・・
例えば、こんな例
画面の「日付」と「時刻」がタグになっているが、データベースに登録する前に「日時」として組み合わせた上で登録したいという状況で、Controllerで画面から受け取ったEntityクラスの「日付」と「時刻」を直接参照して組み合わせた上で、「日時」としてEntityクラスに直接代入してから、EntityをServiceクラスに渡していた。
なぜにEntityクラスのメンバ変数がpublicで、Controllerから直接アクセスしているの？と、確認してみたら、「コーディング規約で、setter/getterとか使わずに直接代入することになっています」とかおっしゃる・・・
このお仕事のまあ、テクニカルリーダー的な人に、クラスのメンバに直接参照・代入とかおかしくありませんかと尋ねたところ、「Entityクラスは単なるデータの入れ物だから、直接アクセスでいいのです。」
え～？そもそも、Entityクラスの中の編集を他のクラスで行うこと自体おかしいでしょう？日付を参照した時にEntityが日付と時刻を編集した日付型を返せばいいのでは？と言ったところ、「こういうのは業務ロジックだから、Serviceクラスに書きます。Entityクラスはデータクラスなのでメソッドは書きません」とか・・・えええ～？
そんなことしたら、同じ画面から、ファイルを作成する機能があるのだけど、そっちのServiceにも同じ内容を書かないとダメじゃないですか。あとで、修正が入った時に、片方だけ直したりとかバグになりますよ？と伝えたら、「同じ画面の機能なので、Serviceクラスは一つにしてください。そして、この部分を関数にします」・・・えええええええ～？
他のSE・プログラマ達に確認してみると、「これが普通でしょう？何かおかしい？」みたいな・・・
いや、おかしいでしょう？それとも私がおかしいの？
そして、この標準に合わせて、コードをリファクタリングしないといけないのです。ダメなコードからダメなコードに変換するので、もう手が進まない進まない・・・というか気持ち悪くて吐きそう・・・
「現場で役立つシステム設計の原則」を推薦するまでもなく、ダメな状況のような気がする・・・

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
技術評論社
増田 亨

Amazonアソシエイト by