Terasoluna がゲロ吐くほど使いづらかった

Terasoluna という NTT データが提供するフレームワークがある。乱暴に言うと Spring と MyBatis のラッパーだ。

とある現場でこれを使って、ゲロ吐くほど使いづらかったので愚痴る。なお、現場ルールも相まって相当に使いづらかったので、Terasoluna 単体の仕様ではない話もちょっとする。

このフレームワークは元々規則で縛り上げる設計で、「設計書が書けたなら実装は誰がやっても同じようになるはずだ、いや、同じになるようにするのだ！」という設計思想が見える。似たようなクラスをイベント (ボタンの押下) ごとに作らせ、不必要なまでにしつこくインターフェースを継承させる。

これまで Struts1 系を仕事でやらされてきたのから比べると、Struts は自由度が高過ぎて、データの受け渡しを如何様にも書けてしまう。Terasoluna はそういった「一見すると結果は同じだけど実装は全然異なる」事態を引き起こさないよう、型やインターフェースやアノテーションでガチガチに規則を作り、異なるやり方をさせないようにしている。

これは大人数で開発する時に、方式を統一するのには向いているかもしれないが、開発工数はアホほど跳ね上がる。同じ画面を再表示する時に直前のデータを引き継ぐために、Form からビジネスロジッククラスに移し替えて結果を入れる ValueObject に再度移し替え、それをまた Form にぶち込む、てなことをしないといけない。そのまんま Form が持ってろよ！！

さらに、趣味で Rails を触っていたので、こうした「規則」を何度も明記する仕組みは最悪に苛立った。同じことを何度も書かないといけないということは、どこかで抜け漏れが発生するリスクが高まり、テスト工数と不具合件数が上がるのだ。

こうしたフレームワークの上に、現場ルールが乗っかって、さらに分かりにくくなる。

その現場ルールの代表的なものは、「何でも連番」だ。クラス名は台帳に追加した順で連番を降るので、連番から機能の塊も見えてこない。本気で「Controller1000 が初期表示で Controller1012 が検索処理」なんて作りになっていたりする。

台帳というのはみんなお馴染み Excel で、誰かが行追加したせいで連番の所々に欠番が発生していたりする。ほんとアボカド、バナナかと。

変数名もチーム規約に即していないと修正を命じられる。フォーム部品の種類と項目の種類 (数値なのか日付なのか、みたいな) をハンガリアン記法のように書かないといけない。画面表示に使わない一時的なローカル変数にまで適用されるらしく区別が付かなかった。

それに、コメントは設計書との乖離を防ぐため、設計書の文言をコピペしたものしか許容されない。

こうしてできあがるコードは、何をしたいのかコードからはまるで読み取れず、設計書からコピペしたコメントは実装の仕方と乖離する部分が多々あり嘘も含まれる。

なんというか、みんなして不便して、効果的でない施策を強制して開発工数を無駄にかけるようなルールしかない感じだった。

そんなワケで、自分が見た現場は実装工程3ヶ月目にして動作する画面が 0 という有様だった。メンバは若手が多く、「static おじさん」に通じるような独自の間違ったやり方を語る「有識者」が2人ほどいる、という、地獄みたいな現場だった。誰も間違いに気付かないし、より良くする方法も知らない。「なぜかこれを書かないと動かない」といった理由で残される無駄なコードが大半を占めていた。「なぜか書かないといけない」なんてコード、言語道断だろう。

こんな会社にいて人生を数年無駄にしてしまったので、今度転職します。