ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

高慢と偏見(5) そして戦いがはじまる

»

 コードレビューという名の、三浦十字軍の暴走は続く。

 「......それから、210行めぐらいで部品マスタからデータ引っ張ってきてるけどね、ここで、PartsMasterGetterって使ってるね。これ何?」

 「部品マスタへのアクセスをまとめた共通ロジック?」富永さんは自信なさそうに答えた。

 「何それ? 私に聞いてるのかね?」

 「共通ロジックです」富永さんは言い直した。

 「なんでわざわざ共通ロジックにしてあるの? コードが追いにくいでしょう」

 ――いや、コードをわざわざ追わなくてもいいように、切り出してあるんだって。

 富永さんは助けを求めるように平良さんを見た。つられて何人かが同じ方向を見たが、平良さんは自分の爪の状態が最重要の関心事になったらしく、右手を熱心に観察していた。

 「それは、その......」富永さんは疲れ切ったように視線をさまよわせた。「......ぼくが来たときにはすでにあったので、使ってるだけで......」

 「あ、そう。それを何の疑問もなく使ってるわけだ」

 「......」

 「1つの画面の処理は、そこで完結するようにコーディングしようとか思わなかったのかね」

 ――いやいやいやいや、そりゃムダでしょう。そんなことしたら、スキーマが変わったときに、関連する全ソースを修正しなくちゃならなくなるって分かってますかい?

 「わざわざ別のクラスに分割しなくても、業務ロジックは書けるでしょう」

 ――そりゃ書けるけど、誰かが悩んだことを工数かけて何度もやるのは効率が悪いでしょう。お金払うのはあなたの会社なんですけどね。

 「だったらわざわざクラスなんか作らないように。クラスなんか作らなくてもロジック関数にすればいいんだから」

 ――だからロジック関数ってなんなのよ?

 「まったく、オブジェクト指向なんてものを無理やり使おうとするから、こういうことになるんだな」

 ――違う。そりゃ、問題が全然違うでしょう。

 「私は自分でクラスなんか作ったこともないよ。それでも20年やってきたし、エンドユーザーからの信頼も厚いんだ」

 ――ええ、そうでしょうね。エンドユーザーはソースまで見ないからね。

 「まあ、すでに作ってしまったものは仕方がないかな。もうこれで進んでる機能も多いだろうし。だがねひとこと言っておくとね」三浦マネージャのメガネがきらりと光った。「この業界で生き残りたかったら、私の経験に学んだ方がいい。このプロジェクトに参加できたことをきっと感謝するようになるから」

 もはや失笑するしかない。

 確かに三浦マネージャから学ぶものは多いかもしれない。アンチパターンの生き字引みたいなものなのだから。

 それにしても、「私の経験に学べ」という発言をどう捉えるべきなのだろう。

 「私の方針に従え」と取るべきなのか。

 「強制はしないが、私の方針に従った方が得だ」と取るべきなのか。

 Javaでクラスを作らないというのは、卵を割らずにオムレツを作れと言っているようなものだから、たぶん三浦マネージャの言う「クラス」というのは、さまざまな共通ロジックなどを指しているのだろう。三浦マネージャ方針に従うということは、今後、新たに共通ロジックを作成することは不可、という意味になる。

 その答えは、すぐに明らかになった。

 「以後、余計なクラスは作らないようにすること」三浦マネージャは明言した。「すでにできているクラスを使うのは仕方がないが、それも可能な限り避けること。Javaにはたくさんの標準クラスがすでにある。それを使えば、ほとんどの機能は作れるはずだからね」

 ――おいおい。マジかよ。

 すでにこのプロジェクトではさまざまな共通ロジックが作成されている。常にメンテナンスされて機能の最適化を図っているし、日々新しく作成され続けている。私もいくつか作ってきた。

 例えば、部品コードは16桁か20桁の英数字だけど、画面には既定のフォーマットでハイフン編集されて表示される。桁数とコードの先頭のn文字によってフォーマットが微妙に変わるので、このロジックは、PartsCodeViewHelperというクラスに、getViewCode()というメソッドとしてまとめて記述されている。部品コードの表示は画面系/帳票系機能のほとんどで必要なので、このViewHelperクラスの恩恵は大きい。同じようなHelperクラスやGetterクラスなどの「便利クラス」はかなりの数になっていて、画面によっては、それらを並べるだけでできてしまうものもある。今後、新しいプロジェクトで使用できると思われるものも多く、平良さんはそれらを1つのjarファイルにまとめようとしていた。

 つまり、このプロジェクトから生み出される財産だ。

 三浦マネージャは、そういう恩恵を捨てろと言っているわけだ。「長い経験」に基づいて。こっちはいい迷惑だ。

◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

 予定を大幅にオーバーして、 コードレビューは3時間後に終了した。

 全員が疲労困ぱいしていた。特に富永さんは、今にもぶっ倒れるんじゃないかと心配になるほど土気色の顔だ。なにしろ、平良さんが戦線離脱してしまったので、三浦マネージャからの集中砲火は富永さんが1人で浴びることになってしまったのだから。

 予定していたバッチ処理のレビューは、結局、延期になった。三浦マネージャはメンテナンス画面の、ほぼ全ソースについて、質問し、非難し、「長い経験」による改善案を提案(というより強制)し、これまで私たちが積み上げてきた小さな世界を否定することに終始することで、予定時間をすべて使ってしまったのだ。会議室に次の予約が入っていなければ、きっと何時間でも続けたに違いない。

 ゆっくりお茶でも飲みに行きたいところだったが、ムダにした3時間を取り戻さなければならない。私は自販機でミルクティーを買って開発室に戻ると、Eclipseを起動してため息をついた。

 一足先に戻っていたアツコさんが小声で話しかけてきた。

 「平良さんからメール来てるよ」

 「え?」

 私はメールを確認した。送信者は平良さん、あて先は私を含むメンバーの何人か。サブジェクトはない。

 変だと思ったのは、あて先が個別に指定されていることだった。メンバー間で連絡事項があるときは、専用のメーリングリストを使うのが普通なのに。

 本文を読むと理由が分かった。

 読んだら消してください。

 今日、来週の月曜日は通常の画面機能の作成を中止。作りかけのGetterクラス、Helperクラス、Checkerクラスの作成を完成させてください。

 三浦マネージャは今日は会議で戻りません。月曜日は出張です。

 短いメールだったが、平良さんの意図は明らかだった。平良さんは、三浦マネージャが使うことを(渋々)認めた「すでにできているクラス」を可能な限り作っておこうとしているわけだ。メールが送られたのは、少し時間のかかる機能を担当しているメンバーばかり。1日ぐらいの遅れはごまかせるということだ。全員の進ちょく状態を把握している平良さんならではの作戦だった。

 こうして私たちと三浦マネージャとの戦いがはじまった。大抵の争乱がそうであるように、この戦いの原因も実に下らないバカげたものだった。

 (続く)

 この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。

Comment(9)

コメント

statcicblue

毎回読む度に次回が楽しみになります。
自分のプロジェクトにこんなやつがいたら衝動的に殴って退職してしまいそうです。

Fufuhu

いっそ全部static main()内でつくってみたらとか言ってみる。

AC/DC

このクラス(共通ロジック)を作ってはいかん、というのは、
http://wonderfulsky.web.fc2.com/memo.html
の、2009年11月16日 オブジェクト指向についての、
「業務アプリケーションではクラスは使えればいい。へたにクラスを作るな。」
に由来するんだろうね、きっと。

yagami

いつも楽しく読ませていただいています。

プログラミングなんて学生時代にCとJavaそれからPascalを「習った」だけで
実際にソフトウェアの開発経験は全くありません。
オブジェクト指向も入門書で勉強した以上の知識が無く、私にはここで
マネージャーを非難することはできまんせん。

しかし、それでも思う事があります。
1.マネージャーが言っている事を何も知らない人(自分のように)が
  読んだ場合、おそらく素直に納得してしまう危険性
2.出てくる単語ややり方を自分の仕事で使われるものに置き換えた時、
  技術者としておかしな事を言っているということ
だけは分かりました。
1はもう説明する必要もなさそうです。2については、自分の仕事に近い表現をすれば
わざわざクラスを作ってまで使うな! = ネジは市販品以外に絶対に使うな!
といっているのと同じ事なんだと思います。
その製品の中で、作っておけば圧倒的に構造が簡単になる部品で、
かつそれが後々に作る製品にも転用ができる。

それをあえてせずに、今ある市販品だけで対応しろ!というのは
ささいな(それでいて影響は大きな)問題のために、全体をそれに合わせるという
無意味な労力を強いていると思います。


分野違いですが、非常にためになります。
自分がそうならないために。

Anubis

どうも。何気に更新が楽しみになっております。
実務ではVBAまでしか組まないが、面白さが解ってしまうのが怖い。

いましたよ。これのサーバエンジニア版の方。

結末がどうなるのか、気になってしまします。

Ted

わかりやすいアンチパターンが出てきましたねw
NIH (Not Invented Here) 症候群。

次かその次あたりでCMSが使えない/使わない、改修前のコードをすべてコメントで残せとか言う、20年余の経験に基づくwwご託宣が出てくるかと期待してしまいます。

自分も件のモデル氏と大して変わらない歳ですが、こんなこと言い出すエンジニア居たら干しますよホントにw

Fufuhu

>>Tedさん

新人としてこの業界に入る身からしてもこんな上司・先輩はごめんです。
コメントで残すくらいなら(趣味でしてるなら別として)
コードの一覧性を確保するためにもバージョン管理のソフトウェアを普通は使いますよね。

ソースコードの一覧性を言うのならコメントは最小限なほうがベターだと
思います。

omanuke

AC/DCさんのコメントリンク先 http://wonderfulsky.web.fc2.com/memo.html の人の言ってることはあながち間違ってませんよ。この人の言ってることを徹底してるのが関数型言語です。関数型言語のひとつの肝である副作用の除去はまさにこの人の言ってることかと。まぁ状態をDBにとかは場合によりけりですが。ステートマシンとしてのオブジェクト指向と関数型を組み合わせたものが現実解な気がします・・・

AC/DC

> 言ってることはあながち間違ってませんよ。

いやさ、それはあんまり問題じゃないのさ。正しいか正しくないかなんて、しょせん相対的なもんだからさ。「staticにすればインスタンス作らなくてOKOK」だって、例の人にとっちゃあ正しいんだろうから。

そうじゃなくて、例の人が有害だってのは、オブジェクト指向について無知でありながら(本人が認めてるからね)、
http://el.jibun.atmarkit.co.jp/densol/2010/08/post-8443.html#c38426547
みたいに、「のように基底クラスを使わない例が一般的です。」なんて断言しちゃってることなんだよ。
しかもそのあとで、「エンジニアコラムはSE,PL, インフラ、いろいろな立場の人が見ているわけで、わかりやすく親切にコラムを書いていただきたいものです。」なんて、どの口が言ってるんだああ、って叫びたくなるような妄言を吐いてるしね。

そういう内容にノーチェックな編集部さんもどうかと思うんだけど、リーベルGさんのコラムは、そういう危険性を明確に訴えかけてくれているって点で、すげえぜと思うんだよね。

コメントを投稿する