2012年06月30日

Eclipseのマニュアルを書くつもりが。。。

ずっとEclipseの使い方マニュアルを書こう書こうと思っていたのですが、結局かけずじまい。そうこうしているうちに新しい4.2 Junoがリリースされてしまいました。

うーん、私も作業が遅いなと思います。反省すべきです。
今年はより計画的に作業を進めたいと思う次第です。
posted by Kiruahさん at 14:11| Comment(0) | TrackBack(0) | 日記

2012年06月16日

JSP/JSFでの項目をフォーマッティングするタグをできる限りやめてみる

JSPやJSFの魅力の一つにカスタムタグがあります。タイトルはこのカスタムタグを否定しています。
カスタムタグを利用することで、モデル層・コントロール層でいちいち画面に表示する内容を整形する必要はありません。これらは全てどのように表示するかをビュー層に任せることができ、MVC構造上分かりやすい(責任境界が明確)と言えます。

例えば仕様変更によって、画面上の日付をyyyyMMddからyy/MM/ddに変更する必要が発生した場合、カスタムタグ(これぐらいならJSPの標準タグでできそうですが)を用いれば、ビュー層まではDateやTimestamp型で送られてきているため修正は不要です。結果、JSPのその出力タグのどのように表示するかを指定する属性を変更するのみで、修正は終了です。

ポイントは、修正はこれで終了である、という点です。

テストはというと、画面を実際に表示する必要があります。
さて、ここでこのカスタムタグが十分にテストされていることを前提としている場合でも、本当に問題がないのかを確認するには、JSPを表示してみる必要があります。これで実はMMの部分が月ではなく、分を指定していたとしても、たまたま12分までの間にテストをしていたら、修正ミスに気付けません。よって、テストでは12分以上をしっかりと確認する必要があります。
現状の開発では、Seleniumを使わず結局目視で確認しています。また、目視でもしっかりとしたテストケースをあげているケースもレアです。こういう場合は、しっかりと最小桁、最大桁のテストとして、00と12はテストする必要があります。仕様をしっかり確認し、分のところの00は0になるのか00のままなのか、分になっていないのかを確認する必要があります。

さて、seleniumを使っていたとしても、仕様変更のためにシナリオを変更してここまで確認するのは面倒です。seleniumはやっぱり目視での確認後に、デグレが発生していないかを確認するためのものとして現場では利用されているのでしょうか?

弊社では、seleniumすら利用しようという空気はないため、目視1ケースのみで終了となり、同時に回帰テストは二度と行われません。
よくあるのが、ここで結局ミスをしていたというのも多発しています。


カスタムタグが十分にテストされているケースであればまだ良しと言えます。このカスタムタグが弊社自作の場合で、かつ、十分なテストが実施されていない場合は、このカスタムタグをテストしているのか分からない状況になることもあります。


最近のWebアプリケーションの見栄えはとてもよく、例えば長い文字列を表示する場合は、"..."と省略形に自動的になり、マウスを近づけるとチップ形式で全文が表示されます。
業務アプリケーションにおいては、技術が時代に取り残されているのもあります(枯れたものを好んでいると理解しておきましょう)が、業務では一覧性が重要視されるために、文字列が省略されることなど滅多にありません。
つまり、表示したい内容はまさに、そのまま書式化されたものを単純に表示すれば事足ります。


カスタムタグにあるような、書式を自由に変換できるタグは一切利用せず、これらは全てビュー層の前、ビジネスロジックで実施すべきです。そして、ビュー層ではその値がそのまま表示されるかどうかだけを確認します。

こうすることによって、ビュー層とビジネスロジック層のテストを分離しやすくしたいと考えています。

・ビュー層
ビュー層では、ビジネスロジック層のモックがフル桁および、最小桁のデータを渡すようにしておきます。
これがレイアウト上崩れないことを確認するのみのテストとすることで完結させます。
よって、ビュー層のみの単体テストを実施します。

・ビジネスロジック層
こちらはビュー層に渡すデータを出力として、JUnitでアサートするテストとなります。
つまり、日付であれば、テストケースとして正しくビュー層に表示すべき内容を変換してから渡しているか網羅的にテストすることとなります。こうすることによって、単純な書式の変更や変換の不具合の確認は、ビュー層で確認するよりもはるかに回帰テストしやすいものにできます。
ビジネスロジック層はそれ単体のみの単体テストを実施します。

・ビュー層とビジネスロジック層の橋渡しを行うBean
これはフレームワークにもよりますが、正しくビュー層・ビジネスロジック層で利用されているか、確認しやすいよう、それぞれ分かりやすい命名規約を用いることを推奨します。

・結合テスト
こちらはレイアウトや表示内容に関する網羅的な結合テストは実施しません。あくまで機能に特化したテストを実施し、ビューとビジネスロジックで正しい業務処理が行われるかの確認を行います。
ページ遷移はやむをえないでしょうが、フル桁はどうか、フォーマットはどうかなどの確認は不要です。そのままビジネスロジック層のデータが出ているかを確認します。
(当然、各項目ごとに値を変えて、出すべき変数名を間違えていないかを確認するのは言うまでもありません。こればかりはJSPやJSFでは確認しようがないでしょう。)


まとめると、私は、ビジネスロジック層で画面に表示する全項目の書式変換を行うべきだと考えています。


これはメリット・デメリット両方あります。
メリットは、Seleniumのシナリオで網羅性はあまり考えなくて良いでしょうし、JUnit/TestNGを利用するのでJenkins/Hudsonでバックグラウンドでテストさせておくと良いでしょう。また、カスタムタグだけでは表現しきれないものは、工数見合いで結局ビジネスロジック層に実装することが多いため、ビジネスロジックに集約することでライブラリ化が容易になります。

デメリットは、JSPの修正だけであれば、JSPを置き直すだけでリコンパイルされるのですが、ビジネスロジックを修正する場合はアプリケーションサーバーのホットデプロイか、サーバーの再起動が必要なのが面倒でしょう。
もとから変更はサーバーを止めてしっかり検証するでしょうが、緊急対応には向かないかもしれません。
posted by Kiruahさん at 18:09| Comment(0) | TrackBack(0) | ノウハウ

2012年06月14日

これから始めるSubversionの使い方

弊社では、未だにSubversion(svn)を利用してソースやドキュメントのバージョン管理をしています。
まだ、ドキュメントをバージョン管理している案件はましなのですが、未だに全部を共有ファイルサーバー上で管理して、編集前にバックアップフォルダに日付を付けて移動。。。ということをやっている方々も多いです。

Subversionですら、浸透するまでに4年近くかかりました。本当はMercurialかGitにしたいのですが、TortoiseSVNから離れられない人が多いのと、新しいことを覚えたくない人と、分散バージョン管理を理解できない人のいずれかが多く、Subversionでうまいこと競合等を管理する必要があると考えていました。

「うまいことやる」ということは、よろしくない状況が発生しているということです。
具体的には以下の様なことが多発しています。

・複数人で開発していると誰かがソースを上書きしてコミットしてしまう(確認不足)
・エラーが発生したままでソースをコミットし、全員がエラー発生状態になる
・そして、エラーが発生していても本人はなかなか修正しない。。。
・動かない設定や自分ローカルで勝手に変更した設定をコミットする
・コミットとバックアップを勘違いしている
・複数人がtrunkで開発するので、どうしても仕方なく構成を変更したい場合、全員一時的にコミットさせ、構成変更後に全員チェックアウト/更新しなおし
あとは個人的な話ですが。
・svn:needs-lockがかかっていると、ちょっと面倒臭い。。。
・svn:needs-lockをかけていると、たまに削除も何もできないファイルがリポジトリサーバに取り残させる。。。
・結局ロックは奪えてしまうので、誰でも変更できる

リポジトリの管理やユーザー管理については、Windows限定ですが、VisualSVNという素晴らしいソフトウェアが無料で提供されており、大変重宝しています。


すでに構築されてしまっているsvnは仕方なしとして、これから新規に始める案件で、svnも新規に作れる案件ではこうしようと考えています。


1. ディレクトリ構成
従来までは以下の様な構成でした。
-+branches
+tags
+trunk

これをこのように変更します。

-+branches
+tags
+releases
+trunk
+groups
+users

・branches
個別の仕様変更ごとにディレクトリ名をつけてtrunkの内容をコピーします。
フォルダ名は案件にもよりますが、通常は以下のいずれかようになると考えています。
1) 日付-内容
2) 案件管理番号-内容
3) 案件管理番号-日付-内容
4) 顧客名/日付-内容
5) 顧客名/案件管理番号-内容
6) 顧客名/案件管理番号-日付-内容
(/はディレクトリをさらに作ることを意味しています。)

・tags
プロジェクト内マイルストーン単位でディレクトリ名をつけてtrunkの内容をコピーします。
フォルダ名は案件にもよりますが、こちらも通常は以下のいずれかようになると考えています。
1) 日付-内容(理由)
2) マイルストーン名-内容(理由)
3) マイルストーン名-日付-内容(理由)

・releases
通常は顧客には複数の環境が用意されています。例えば、顧客検証用、顧客受入用、顧客内ベンダー開発機、リリース検証機、本番機、災対機(待機系)。さらには自社の開発環境、テスト環境(単体/結合/総合等)があります。
それぞれ、どのパッチをどこまで適用するか異なる場合があります。それが順次段階を経て適用されるのであれば良いのですが、これまで数回、緊急のためにすぐにリリース検証機で簡単な検証後、本番に適用し、数日後に他のサーバーに適用ということがありました。
そして、運が悪いことに顧客都合によってそのスケジュールが延びることもあります。これらをどこまで適用したか管理するためにExcel管理台帳とか、共有フォルダにおいていたりしましたが、これをsvnのreleasesにディレクトリ単位で管理したいと考えています。

同時に、パッケージやそのカスタマイズ結果など、複数の顧客を管理する必要がある場合にも利用します。

具体的には以下のディレクトリ構成を採用します。

releases/顧客名/No-環境名
Noは適用順序を示します。二桁で統一します。(1なら01とする)

・trunk
trunkはこれまで通りの利用方法に近いです。安定版の最新を入れる形になります。
が、こちらもディレクトリ構成を分ける方が良いでしょう。

1) trunk/stable
2) trunk/develop
3) trunk/チーム名/
4) trunk/顧客名/

などです。

・groups
こちらは用意するかどうかは案件の規模によります。
大きい場合はグループごとにディレクトリを分けます。

groups/グループ名/

このグループの下は、グループ単位で成果物を取りまとめる場合に利用します。
つまり、グループ管理者が一度ここにユーザーの成果物をとりまとめ、問題がなければtrunkにマージします。

・users
こちらは開発者単位でディレクトリを作成します。

users/ユーザー名/
ユーザーが自由にコミットしてよいディレクトリとなります。

groupがある場合はユーザーはgroupにのみマージできます。また、groupがない場合はtrunkのdevelopにのみ、ユーザーはソースをマージできます。


2. ユーザー
ユーザーとグループの管理をきっちりと行います。
一般ユーザーはusers/配下の自分のディレクトリにしかコミットできません。よって、チェックアウトもそこから行います。案件に参画したタイミングで、trunkの必要な情報を自分でコピーします。
また、場合によってはgroupsに自分のコミット分をマージできます。groupsがある場合は一度groupsにコミットし、trunkの反映はそのグループの管理者のみが行えます。逆にgroupsがない場合はユーザーはtrunk/developにマージできますが、trunk/stableへのマージは案件のライブラリ管理者がチェック後、行います。


3. ライブラリアンをたてる
ライブラリアンしか、ユーザーの管理、グループの管理が行えません。通常最大でも3名とします。
さらにグループ毎に1名をグループのサブライブラリアンとし、trunk/developにコミットする権限を有します。
ですが、trunk/developからtrunk/stableやbranches、tagsにはライブラリアンしか変更できません。


4. 個別要件(ブランチやタグ)の管理
ライブラリアンは案件上ブランチやタグに直接コミットできるユーザーを指定し、個別機能の修正を許可することができます。


5. needs-lockは使わない
ロック機能は使わないこととします。また、ライブラリアンも直接stableを変更せず、自分のユーザーディレクトリの中で変更後、trunk側にマージすることとします。


6. ライブラリアンはtrunk/stableを変更した場合、ユーザーは任意のタイミングでtrunk/stableをマージできる


7. できる限り、グループの管理者、ライブラリアンが修正結果の連絡を受け取りマージする。つまり、ユーザーには本体のtrunk等には変更権限を与えない


まだまだやり方や構成については検討の余地があると思います。それは管理がまだ面倒そうだというところです。
ですが、これでかなり管理者の自由度が上がるのではないかと考えています。
もう少しドキュメント化したり、実際にやってみてブラッシュアップしたいと考えています。
posted by Kiruahさん at 20:00| Comment(0) | TrackBack(0) | ノウハウ