2000年から2010年にかけて僕はとある大きな会社でJava技術に関しての重鎮の一人だった。組み込み系なので「Javaの重鎮＝Javaの処理系を作れたり速くて省メモリなプログラムを作れたりする」であり、オブジェクト指向べったりということにはならず、僕らは結局洗脳されていなかった。そもそもJavaの処理系は全てが全てオブジェクト指向で書かれているわけではなかった(でもクラスライブラリの実装はJavaの各クラスが何なのかを正しく理解するのにとても役立った)。
C++と比べて比較的遅いJavaで、当時の組込みプロセッサで十分な速度を出そうとすると、オブジェクト指向をピュアに推進するわけにはいかなかったというのも理由のひとつだった。
そんなわけで僕がいた世界ではJavaエンジニアはスーパースターではなかった。世界のJavaの潮流からは微妙にズレているし、オブジェクト指向設計も全然やってないと思われていた。その代わりC++エンジニアは正義を振りかざしていたと思う。
Androidが少し盛り上がり始めた2010年頃、社内でちょっとAndroidアプリを作る必要が出てきた。僕は重鎮扱いされていたのでそのようなアプリを作る仕事にはアサインされず、元C++のエンジニアがその任を担うこととなった。1カ月後にできてきた設計書を見て僕は頭を抱えた。簡単なアプリ、Activityが何個あって、Activityに属さないものをどう管理するか、SQLiteDatabaseとSharedPreferencesに何のデータをどう格納してそのライフサイクルはどうするのか、そういうことが書かれているべきはずのところには、巨大なクラス図しかなかった。個人的には10くらいのクラスがあれば十分なところに、20個を超えるクラスが存在していて、僕から見ると無駄に継承が使われていたし1箇所でしか使われないような。個人的にはそういうのは最初に動作可能なプロダクトが作れるまでが遅くなるし、なにかあったときの修正のオーバーヘッドがでかいから、もっと単純なクラス構成にしたほうがいいと注文を出したが、彼らは「これがオブジェクト指向的に正しいんですよ」という主張をしていた。僕は正しいオブジェクト指向を実践することが正義だとは全く思えなかったが空気が反論を許さなかった。
でも結果的に彼らが作りはじめたらプロダクトはバグだらけとなり社内的にも問題になって、全部のコードレビューを僕らがやることになった。そのときにクラス構成は悪いと思いつつ少し単純にした。
彼らはUMLのクラス図を書くことが設計だと考えていたから、設計した内容はクラス図で表せる必要があり、だからこそ個別のデータ構造や役割をすべて別個にクラスに分割していたのだと当時は思っていた。最初にクラス図を書くから、箱をお絵かきツールで一個追加するだけで、(設計書上は)クラスが作れてしまうし、それによって自分の考えを表現できたように思えてしまう。だから箱をいっぱい書いてしまう。当時はそう思っていたけど、単純にあれは洗脳だったのかもしれない。
僕がJavaのVMとかクラスライブラリ、つまり誰かに使われるプラットフォームを作ってきた側の人間だったからかもしれないけど、それがプラットフォームであってもなくても、何かの機能を実現するモノがあったとして、それの内部の設計がオブジェクト指向だろうがどうだろうが、そんなことはどうでもよく、外部から見て使いやすいインタフェースを備えているかが重要だっただった。それを差し置いて内部がきれいなオブジェクト指向設計になっているかどうかなんて割とどうでもよかったしこれからもそうだ。
いま、新しい宗教に洗脳されている人を見たとしても
それが悪だとか、自分が洗脳されていないとか言い切ることはできない。
これはそうかもしれない。でもやっぱりTDD 純粋主義者は悪だと思うし、逆にテストを全然しない連中も死ねばいいのにと思ってしまう。
TDD(テスト駆動開発)純粋主義者は最悪である。彼らの心の弱さは、様々なワークフローの存在を処理することはできな
