Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

ソースコードの自動生成の意義

ここ5~10年くらいのソフトウェア工学では、「ソースコードの自動生成」はだいたい悪手と言われているみたい(「どこに何を書いたらいいか分からない」という人のためのガイドとしては、雛形ソースの生成がとても有効だけど、それとは別物の、ロジックを含めた自動生成の話ね)。理由は、生成したコードに間違いがある場合の修正が大変とか、UMLをもとにModel-Drivenな生成をしても結局大した内容は生成できないとか。そんなんだったら、フレームワークを用意して、ホットスポットビジネスロジックだけ書いてもらう方がいいよ、ということみたい。

でも実は、「ソースコードの自動生成」には、技術的というより政治的な利点があるんではないかと思っている。もちろん、それがアプローチとしてイケてるかダサいかは別として、という話なんだけど……

例えば、自分の書いたビジネスロジックのコードが動かないと「フレームワークのバグだ!」って騒ぎ出す人、結構居るんですよ、理由はいろいろですけど。本当は自分のコードが悪いの分かってんだけど、それを修正する時間を稼ぐために、とりあえずフレームワークが悪いと騒いどいて、フレームワークの開発元(あるいはフレームワークの適用を決めた共通チーム)が調査したり見解書いたりしてる間に自分のコードを直そう、とかね。そういうことやらかす人に「このフレームワークのこの部分って、何やってるんですか?」って聞かれたとして、共通チームのチームリーダーが30秒間で説明できないような複雑な処理をやってる箇所があると、絶好の時間稼ぎポイントにされちゃうんだよね。

ビジネスロジックがマズいせいで上手く動いてないなら、共通チームはその理由をビジネスロジックの開発担当者の上司(作業指示者)に説明する必要があるわけ。フレームワークの上に載っかってるんだから、こう実装しないとダメなんですよ、とか。

ところが、いまベテラン管理職になってるくらいの人が若い頃は、「ライブラリ」の形でのソフトウェア再利用が持てはやされてて、フレームワークという考え方はあまり広まってなかったから、「フレームワーク?何それ?」ってなっちゃうことがある。GoFデザインパターンが出たのが1995年、フレームワークの考え方がエンタープライズ分野に入ってきたのが2000年代前半くらいだから、若めの管理職の人はそんなことないんだけどね。

「『関数の呼び出し方が悪い』というなら理解できるんだけど、『呼び出され方が悪い』って何それ?訳わかんないよ。共通的なクラスって、ライブラリのことでしょ?ライブラリ呼び出すどっかの引数がおかしかったんじゃないの?え、違う?何それ。」とかいう反応。「書いたロジックを上から順に読んできゃいいんじゃないの?え、それも違う?どういうこと?」とかね(この「上から順に読んでいく」以上のことができない人、世代関係なくかなり多いのよ。たぶん、ソース上の記述と実行時の動きを区別できないんだと思う)。

特に、そのやらかしさんの上司が、要点だけ話さないと理解できないソーシャルタイプの人だったりするとなおさら。「口で説明されても分からんから、エビデンスを表にまとめて、頭紙に見解書いて持ってこい!」とかね。

だからフレームワークの機能はできるだけ簡素にしといて、代わりに自動生成したコードで機能を補うわけ。フレームワークの機能が単純なら疑問を挟む余地が少なくなる。それに、ビジネスロジックの開発担当者にコードが見えてさえいれば、生成したコードが多少長くても「生成されたコードをちゃんと読まない奴が悪かった」っていうことを理由にできる(上司にしても共通チームにしてもプロマネにしても、そういう風に上に報告できる)からね。開発担当者が抗弁しても、上司やプロマネは「読まなきゃならんコードが多い?共通化とか再利用とかしとらんのはけしからん。え、フレームワーク?何それ。ああ、自動生成。それだったら分かる。理解しやすいようにチュートリアルは用意しといてくれよ」となることが多い。

フレームワークの導入支援をしてる共通チームって、人員が少ないうえに担当作業の影響範囲が広いから、こういうトラブルに巻き込まれるとプロジェクト全体の進捗にすごく悪いんだよね。その上、技術面での責任を負わされてることが多いから、責任をなすりつけられやすいし。

なお悪いのは、調査の結果フレームワークに非がないことが分かっても、「あのフレームワークは疑われたことがある」っていう事実とか、悪印象って消えないんですよね。だから、一度騒がれるとまた次に騒がれた時に「フレームワークが悪いんじゃ?」って思われてしまいやすくなるんです。そうすると、次にまた時間稼ぎがやりやすくなる悪循環に陥っちゃうんです。

でも、フレームワークに対してチーフプロマネなんかの偉い人が悪印象を持ってると、そのせいで使ってもらえなかったりするんです。だから、なおタチが悪い。だから、そういう時間稼ぎに使われたりされるのを防ぐことだけ考えれば、ソースコードの自動生成は結構有効なんだと思うんですよ。

もちろん、政治的な理由で技術的にまずい設計を採用すると後で痛い目を見る、ってのはよく言われることだけどね。

あとは、サポート期間の話とか。フレームワークの中のロジックは、基本的にフレームワークの開発元が面倒を見る必要がある。業務ロジック考える人たちは、フレームワークのことまで考えてられないからね。それに、フレームワークの亜種が多発すると、ノウハウの使い回しに支障が出る。

一方で、生成したソースの方にロジックがあれば、それはプロジェクトの持ち物(受託開発プロジェクトなら顧客の資産)なので、もちろんフレームワーク開発元もテストはするけれど、リリースしたあとはプロジェクトが面倒を見ればいい。システムによっては50年物のコードとかがあるんだけど、フレームワークの開発元が50年間面倒見るのはさすがに難しい。システムは50年生きるかもしれないけど、開発手法が50年生き続けることはないだろうからね。

フレームワーク自体をプロジェクトに譲渡する手もあるけど、もともとフレームワークの実装を隠蔽することで業務ロジック開発の負荷を下げていたわけだし、プロジェクトがわも頼る先がなくなるわけで、これは本当に最終手段かな。