Hatena::ブログ(Diary)

達人プログラマーを目指して このページをアンテナに追加 RSSフィード Twitter

2010-12-11

SIerがExcel→Javaのコード自動生成をPGに押し付けるのは善か悪か?

以前Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指してにて

何でもかんでもとにかく自動生成させたがる。特にExcelなどの表から大量のクラスを自動生成させるなど。たいていそのようにして生成されたクラスはゴミで保守も大変なものになりがちです。

ということを書いたことに対して、会社の忘年会で上司や同僚の間で議論が盛り上がって興味深かったので、ここで自分の考えを再度整理させていただきたいと思います。(忘年会で1次会、2次会の間ずっとこういった話題で話が盛り上がるというのはかなり特殊な部署なのかなとは思います。「SIerのやり方はXXだ」一口に言っても、それは全体的な一般傾向を表しているのであって、実際はさまざまな人々がいることを忘れてはなりません。あくまでもそういう意味で捉えてください。)

それで、私の周りにはプログラミング好き、技術好きが多いのですが、それでも自動生成の善悪については意見が分かれるようです。誤解を恐れず一言で言うと、この業界の技術者には「SIer脳」の人と「アジャイル脳」の人がいるように思います。理想的には臨機応変に両者を柔軟に使い分けられるハイブリッド脳がよいのだろうけれども、多くの場合考え方がどちらかに偏っていることが多いのですね。それで、いままでの慣習や教育というのが大きいので、数から言うと前者に偏っている人の数が圧倒的に多くて、「アジャイル脳」の人はごく少数で異端者扱いということが普通のようです。(ちなみに私は完全に「アジャイル脳」に偏っていて、会社員としては問題ありかもしれません。)

私もそうですがアジャイル脳の人は本能的に設計とコーディングが切り離せないものであるという考え方に心底ほれ込んでいるのですね。(プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して)つまり、コーディングを単純な製造工程ではなくて、著作とかデザインといった創造的な作業であると捉えています。この考え方ではコードと設計は一体であり、どちらが先か後かというのは鶏と卵の議論と同様に意味をなしません。一方SIer脳の考え方では、たとえ繰り返し型開発の価値を認める人であっても、やはり設計(書)が先で、コードはそれに付随して半自動的に製造されるものであるという考え方が根強いようです。アジャイル脳の考え方からすると「DNAの連続性を考慮するとどうしても卵が先でなくてはならない」といった議論と同様におかしく思えてしまうのですが、やはり設計書が先行しなくてはならないという考え方に囚われています。そして、ExcelにせよUMLにせよそこから自動的にJavaなどのコードを自動生成することはユーザーの目に触れる設計書とコードとのトレーサビリティーが確保される上での有効な手段であると考えます。

たとえば、Excelのテーブル定義書からエンティティクラスを自動的に生成するツールをSIer脳の人は非常にありがたがります。*1でも、私はどうしてもそういったツールは好きになれないのであって、できることであれば使いたくないと考えてしまいます。好きになれない理由としては以下のようなことがあげられます。*2

たとえば、以下のようなコードだったら、Excel表と読みやすさはほとんどかわらないはずです。

public class User {
  
  @NotNull
  @Size(min=4, max=8)
  private String userName;

...

}

その上コードは実行可能だから設計の妥当性を簡単に試験できるし、リファクタリングによる設計変更もきわめて簡単にできます。さらに、継承アノテーションなどプログラミング言語本来の機能をいかんなく発揮することができます。どうしてもSEや顧客がコードを読みたくないのであれば、JavaコードからExcel表を生成することは容易に可能です。このようにアジャイル脳になっているとコードこそが多くの場合設計の最良の手段であり、これを中心にしてその他の文書は必要に応じて補助的に発生する副生成物であると考えます。

まずはコード上でじっくり設計を考えた後で、説明資料として後から必要に応じて要点をUMLで文書化するという流れの方が作業手順としてしっくり来ることが私の経験上ほとんどです。コードこそが設計の本質をもっとも正確かつ簡潔に表現できる手段なのであり、UMLはそのある側面を捉えやすくする方便としての一表現に過ぎないなどと言うと怒られてしまうでしょうか?

同様に、アジャイル脳は一般的にDDLからエンティティクラスをボトムアップで生成する*5ことを好まず、エンティティクラスからDDLを自動生成するトップダウンO/Rマッピングを好みます。この点でテーブル定義書や画面定義書からクラスを自動生成するのが望ましいと考えているSIer脳の考え方とはまったく正反対です。

なお、Excelからクラスを生成する場合、Excelを唯一のソースコードであると考えるのであれば、アジャイル脳的にもまだ許容できます。(mavenならExcelsrc/main/excel配下に格納して、生成したJavaコードをtarget配下に生成してSVN上でも共有しない)この場合、ExcelDSLの一種であると考えていることになります。ただ、バイナリファイルなので共有が難しいし、重いし、通常は不便で良い事無しだと思います。

もちろん、自動生成をすべての分野で否定しているわけではなく帳票作成とかビュー周りとかテストコードとか形式化が可能な分野であればよいと思うのですが、自動生成することによってドメインモデルのような最重要の領域において、コード上できちんと設計する自由を奪ってしまう*6のは私の理想とする世界の基準では悪であると思えてしまいます。

しかしながら、何が善で何が悪かということはさまざまな要素によって決まるものであり、一概に決めつけることはできないでしょう。戦前であれば他国の領土を侵略することが善であったのと同じように多数派の意見が正義であると考えられるものです。そういう意味において、現在の多くのSIでは自動生成は有効なツールであると考えられれているのだと思います。また、アジャイルなどというのは現実の仕事の進め方にマッチしないとんでもなく悪い考え方とされてしまいます。そもそも製造業のメタファーからPGが自発的に設計を考えるということを許容しない文化が非常に深く浸透しています。私としてはこうした状況は残念に思いますが、それが多くの場合、現在の業界の現実なのだと思います。

*1:こうした傾向になるもう一つの理由として会社でFWやツールを作る部署と実際に業務システム開発を担当する部署が明確に分かれているというのも原因のひとつとして考えられます。業務と切り離されていると有能なプログラマーの才能がツールなどに費やされることになります。確かに、そういったツールの開発は楽しいので。

*2:もちろん、アジャイルRailsだってscaffoldingの自動生成機能などはありますが、それは開発初期の成果物のベースを作るものであって、設計書とコードをずっと同期するというSIer脳的発想とはまったく異なるものです。

*3:もちろんそうした設計がすべて悪と決め付けているわけではありません。ただし、そのような付加価値の低いシステムのスクラッチ開発は今後少なくなると思います。

*4:最近の傾向としてはRooのようにアノテーションなどソースコード中のメタ情報を元にバイトコードに機能を織り込むような考え方が流行かもしれません。これだとDRYの原理が保たれますので。

*5Hibernate Toolsではこうした方向の生成をリバースエンジニアリングと呼んでいます。Javaコードが設計の中心であるという思想が表れたものと言えると思います。同僚に言ったらテーブル定義書を中心に考えてそれはフォワードエンジニアリングでしょと言われたことがあります。なにが世界の中心か、大きな思想のギャップを感じました。

*6:多くの業務システムではレガシースキーマの存在を考慮しないといけないため、テーブル設計がまず最初にありきという制約がある場合が多いという事実はもちろんあります。

miyohidemiyohide 2010/12/12 10:13 こんにちは。はじめてコメントします。
私もExcelでソースを自動生成するようなツールを使ってますが、エントリにありますようにExcelはバイナリで、重い、おまけによく分からない理由で開けなくなるので自動生成の元ネタとしてはイケテナイと感じています。この理由から個人的には自動生成は悪ではなく、Excelからの自動生成が悪だと考えています(単にExcelが嫌いってことになりそうですが^^;)。
SIer的は発想では、コーディングから設計書への後戻りは「ありえない」ので、設計書であるExcelからソースコードを生成するのはコスト0だからお得というソロバンをはじいています。ただ、現実にはコーディングから設計への戻りは発生し、SIerもそれに気がついているのですが、一度手に入れたお得なコスト計算は手放したくないということで見えないふりをしています。
なので、いわゆる上流工程で一部の隙もない設計ができればSIer的な発想は実現できるのでしょうけど、一部の隙もない設計ができるようなレベルに行き着くにはもっと時間がかかるかなと感じています。

長文失礼しました。

ryoasairyoasai 2010/12/12 12:27 miyohideさん、コメントありがとうございます。
>この理由から個人的には自動生成は悪ではなく、Excelからの自動生成が悪だと考えています(単にExcelが嫌いってことになりそうですが^^;)。
そうですね、私の言いたかったこともそういうことで、自動生成全般を否定してつもりでは決してないので、その点明確にしていただき、ありがとうございました。

rising3rising3 2010/12/12 21:48 こんばんは、先日はどうも。少しコメントさせて頂きます。
「Excel→Javaのコード自動生成は善か悪か?」というテーマで議論しても建設的な話ができないかと思います。
仕事の進め方(たとえば、何でお客さんと合意ととりながら仕事を進めていくか等)や仕事を進める中での制約等をいろいろ踏まえて検討した結果、Excelからソースコードを自動生成するという答えが導かれたのであれば、私は賛同するし、何も考えてなくて周りでもやっているし単に自動生成がしてみたいからくらいの理由で採用したなら私は賛同しません。たぶん意見がわかれたポイントはその辺で、なぜインプットの情報にExcelを選んで自動生成するようにしたかを理解してからじゃないと自動生成というテーマについて良いディスカッションができないなーと(まぁ酒の席だから仕方ないのかなw)
すくなくもとryoasaiさんがExcelが大嫌いということだけは再認識しました(^^;)

ryoasairyoasai 2010/12/13 00:20 コメントありがとうございます。
>「Excel→Javaのコード自動生成は善か悪か?」というテーマで議論しても建設的な話ができないかと思います。
そうですね。一般論として上記の命題の真偽を決めるということはまったくナンセンスなことのように思いました。
OOPが不慣れな開発者という前提でWFで開発を進めなくてはならない場合など最良の手段ということがあるでしょう。
タイトルを「SIerがExcel→Javaの自動生成を押し付けるのが善か悪か」とした方が命題のコンテキストが明確化されてよいと思いました。

ryoasairyoasai 2010/12/13 00:27 タイトルを修正しました。