俺は何だか過大評価されていることがあるようだし、偉そうなことを言う時もあるが、仕事に投入されるとあんまり役に立たない。
実のところ、オブジェクト指向というものを学び始めてから今までに、オブジェクト指向な仕事をしたことがないのだ。
反復型開発？ UML？ なにそれ？ なのである。
今は、C#でクラサバな仕事をしている。
層分けは…2層か？ UIとデータアクセス。
ビジネスロジックはUI層にべったり入り込んでいるし、エンティティクラスなんて無い。
1テーブル1クラスになっているから不便なところもあるかと思えば、あちこちのクラスからテーブルにアクセスしているから修正箇所が散らばっているところもある。
メソッドはほとんどstatic。
設計書は…一応、機能仕様書というものはあったが、フォーム上の各ボタンごとにクリック時のアクションを書いたようなもので、製造が終わってから納品用にユーザーズマニュアルを切り貼りして作られた代物だ。それ以外は無い。
設計書が無いから、テスト仕様書もロクなものがない。Subversionのコミット履歴をもとに、それっぽいものを書き起こしていたが、単純なテスト漏れが多く見つかった。
新卒で入った最初の会社の最初の仕事によく似ている。
思い起こせば、今よりは多少ましだったかもしれないが、五十歩百歩だ。
あれもVB.NETでクラサバアプリだったが、一応、3層構造を意識していたらしい。実態はお粗末なものだったが。
SQL周りは発注元が作った妙なライブラリを使うことになっていて、SQL文は外出しのXMLにしてあったけれど、プログラムをいじらずにXMLの修正だけで完結したためしは無かった。
そのライブラリはUnionに対応していなかったので、あちこちで醜いハックをした覚えがある。
フォームの中に、コピペで量産された8000行のコード（1000行×3段のif-else）を見たときは、縮める気さえ起こらずに、俺も黙々とコピペに励んだ。
別の会社で、Javaの仕事を2ヶ月ほどやったこともあった。
XMLで入力されるデータをRDBに入れる処理で、入ってくるXMLの構造が変わってもいいように、XML階層構造とDBの列名の対応テーブルとかいうよくわからないものを作らされた記憶がある。
その時の上司は「新卒で入ってくる新人はオブジェクト指向を知らない。オブジェクト指向でシステムを作ると新人に保守できない。だからオブジェクト指向は使えない」と言った。
その一言でその会社を見限った。
今、1年ほど継ぎ接ぎで作り続けてきたシステムを、一から作りなおせる機会に恵まれている。
一大転機である。
オブジェクト指向だとかアーキテクチャだとかO/Rマッピングだとか、そういったものを盛り込める機会である。
だが、俺にはそのための力が無い。
社内で唯一、そういうことをわかっていてアーキテクトと呼べそうな人は、俺のプロジェクトチームにはおらず、いつも忙しそうに動き回っている。
というか、プロジェクトチームは俺とリーダーの2人だけだ。先月初旬、別のプロジェクトに2人持って行かれた。
アーキテクトが欲しい。切実に。
もしくは、何かこう、「初心者でも安心！ 一人でもできる開発プロセス」みたいなのがないだろうか。