GWT Maven Pluginでマルチプロジェクト

マルチプロジェクトでGWTを動作させたかったのだが、なかなかうまくいかなかった。 が、<compileSourcesArtifacts>を使用して初めて動作したので、備忘録の意味でも残しておく。

参照するプロジェクト(artifactID=gwt-sample)

参照されるプロジェクト(artifactID=gwt-module)

<!-- GWT Maven Plugin -->
<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>gwt-maven-plugin</artifactId>
 <version>2.3.0-1</version>
 <executions>
  <execution>
   <goals>
    <goal>compile</goal>
    <goal>test</goal>
    <goal>i18n</goal>
    <goal>generateAsync</goal>
   </goals>
  </execution>
 </executions>
 <configuration>
  <runTarget>Sample.html</runTarget>
  <hostedWebapp>${webappDirectory}</hostedWebapp>
  <i18nMessagesBundle>
   jp.tkym.labs.gwt.client.Messages;
  </i18nMessagesBundle>
  <!-- 参照するプロジェクトを指定します. -->
  <compileSourcesArtifacts>
   <!-- [group-id]:[artifactId]を指定します. -->
   <compileSourcesArtifact>
    jp.tkym.labs:gwt-module
   </compileSourcesArtifact>
  </compileSourcesArtifacts>
 </configuration>
</plugin>

module側にはsource.jarを生成するようpomを設定する

   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-source-plugin</artifactId>
    <executions>
     <execution>
      <id>attach-sources</id>
      <goals>
       <goal>jar</goal>
      </goals>
     </execution>
    </executions>
   </plugin>

誰がコーディングに工程を持ち込んだ？

　本当に使い勝手の良い製品には、説明はいらないはずである。つまり、マニュアルなんて必要なく使えるものがユーザビリティが高い製品と言える。カタログも必要ない。使って見れば勝手に流行る。それは、とても魅力のある製品であり、そこに説明が必要ないから。

　本当に作りやすい構造には、設計書なぞいらない。それ自体の構造が最適化されているため、改修もしやすく、構造自体が作り手にさらなる創造を与えるから。

　本当に美しいコードには、他に何も必要としない。それ自体が全てを語る。

　コードを書くとは、知性、感性、創造の活動と考える。本当のプログラマーのコーディングとは、設計、製造、テストという工程というものは存在しない。ただ感じ、考え、書いて、確かめるという、単純な創作活動だ。誰がコーディングに工程を持ち込んだ？

　ソフトウェア開発において品質専門組織というのが存在する会社があると思うが、そんな組織になんの価値がある？本当にお客さんに評判の料理を出すレストランでは、多分レシピの書き方にこだわっているレストランがあるとは思えない。素材、技術、調理法に重点をおいて、調理人が切磋琢磨しているはずで、マネージング力だけでおいしい料理が出来上がるとは思えない。日々の調理技術を磨き、湧きたつアイディアを何度も試作し、試行錯誤した結果、本当においしい料理ができあがるはずだ。そして本当の有能なマネージャはそうした思考試作を数多く経験した人間ではないか？

プログラミングの心得

　プログラムコーディングを行う上で、最も重要なポイントを以下の３点に絞られる。

1. 正確であること
2. 保守性が高いこと
3. 性能が高いこと

　他にも必要なポイントがあるのでは？という意見もあるかもしれないが、上記３点が揃った時点で、プログラムは非常に高い品質を維持し、非常に美しく仕上がる。

　さて、この３つポイントを議論するうえで最も重要なことは、それらの優先順位にある。

　まず、要求仕様に対して「1.正確であること」がプログラムとして必要最低限の要素であることは、議論の余地はないものであると考えられる。

　ここで、問題となるのは「2.保守性が高いこと」と「3.性能が高いこと」の優先順位である。この優先順位が逆転しており、プログラムソースが分かりにくいことを指摘すると、「このループ処理で複数の処理を行うことで性能が良くなるのです」と、当たり前のように答える開発者に度々出会ってきた。

　そんな開発者に対して、「プログラムソースはお手紙だ」という例えを聞かせることがある。

　プログラムを初めに開発するのはあなたかもしれないが、保守をするのは大抵その後輩、又は全くの他人になることは間違いない。そのため、他人が保守できないプログラムを作成した場合、例え性能が高くても、それはマスタベーションにしか過ぎないことになる。性能は常に改善できる状態にあるべきであり、その機会を決して途絶えさせてはいけない。

　保守をする人に分かりやすいメッセージ（プログラムソース）を伝える力こそが、プログラム開発者にとって必要な要素であると、私は考える。