15.フレームワーク
会話の背景：
コーディングする前に、開発チーム全員にフレームワークとコーディング標準のことを話し、統一的なアプローチを全員に意識させることが必要である。
フレームワークとは、開発環境のフレームワークと実行システムのフレームワークの二つがある。本節ではMVCのStrutsまたORMのHibernateという二つの開発フレームワーク、それとJ2EEの実行システムのマルチレイヤーについて触れる。
登場人物：
近藤― SA
鈴木― PL
山田、田中―PG
会話：
鈴木：こんにちは。
いよいよコーディングに入ります。いつものように、コーディングと開発したシステムの質をあげるため、また生産性を高めるため、フレームワークを使います。今日は、このフレームワークの使い方および注意点に関して、チーム全員に認識してもらいたいと思います。
それでは、近藤さんに説明していただけます。近藤さん、お願いします。
近藤：そうですね。今回の開発ではわれわれは開発環境としてEclipseを使って、その上にMVCのStrutsフレームワーク、ORMのHibernateフレームワークを使います。また、開発されたシステムには、J2EEのマルチレイヤーアーキテクチャーを持つように設計していますので。その辺皆に議論をしてもらい、統一したアプローチで開発を行いたいですから、何か質問があるでしょうか？
田中：これまで、われわれはJSP/servlet/Beanで構成したシステムをいくつか開発しましたが、今回MVCのStrutsフレームワークと比べて、どのように違うでしょうか？
近藤：それはいい質問ですね。実はStrutsフレームワークでも、基本的にはJSP/Servlet/Beanによりシステムを開発するわけです。ただし、考えてみたら、ここまでの開発では、例えば、JSPからデータベースのアクセス、またJSPにもビジネスロジックを含んだことがたびたびあります。特に、JSP、Servelet、Bean各自の責任をはっきり強制的に分担させていませんから。
今回StrutsはActionという概念を導入し、servletクラスは直接書かずに、ビジネスの流れはActionで書くことにします。これで、JSPは画面ロジック、Actionはビジネスフロー、BeanはビジネスロジックというようにMVCのデザインパターンを強制的に実施させるため、一つのシステムを三つの側面に分割できると思います。
田中：なるほど。これは、例のMVCすなわちモデル、ビュー、コントローラーですね。
近藤：その通りです。それにより、今回の開発では、画面周りあるいは振る舞いのコーディングはほとんどJSPとActionを書きますが、データアクセスはBeanあるいはドメインクラスを書きます。
山田：ドメインクラスとは、ビジネスロジックもあり、データベースのアクセスもあり、ちょっと複雑みたいですね。
近藤：そうですね。ですから、今回われわれはORMのフレームワークHibernateを導入します。
山田：ORMでもHibernateでも初めて聞いたので、説明してもらえませんか？
近藤：もちろんです。
ORMとはObject Relational Mappingの省略で、名前のとおり、これはオブジェクトとリレーションナルのデータベースとのマッピングです。コーディングから見ると、ただのJDBCのラッパーに過ぎないとも言えます。
今回われわれが使おうとするHibernateツールはデータベースとオブジェクトの間をXMLにより、緊密に繋ぎますから、コーディングの立場から見ると、今度はビジネスロジックを書く時には、とにかくオブジェクトの世界でコーディングすればいい、データベースのスキーマにはあまり気にしなくてもいいです。
山田：それはいいですね。そうすると、テーブルからオブジェクトへのマッピングのコーディングを誰かにかいてもらうのでしょうか？
近藤：そのマッピングはHibernateがやってくれて、われわれはXMLだけを書けばいいと思います。それと、最近いろいろなツールが出てきますから、それらのツールを使えば、永続的なドメインクラスを自動生成したり、またデータベースが変更されるときにも連動できます。
山田：これは大変便利ですね。それならば、われわれのビジネスロジックを書く人は何を書くわけでしょう？
近藤：そうですね。一般論としては、この永続的なドメインクラスには、画面クラスや、コントローラークラスなどが直接アクセスしてはいけません。それで、ビジネスオブジェクトのクラスが登場します。実際的には、おそらくコントローラークラスと永続的なドメインクラス間にはビジネスロジックを含んだビジネスオブジェクトのクラスがあると思いますが、画面クラスと永続的なドメインクラスの間にもそれらを繋ぐためのビューオブジェクトのクラスがあると思います。
それこそ、できあがるシステムはJ2EEのマルチレイヤーのアーキテクチャーを持ちます。すなわち、プレゼンテーション層、ビジネスロジック層、データアクセス層になります。
山田：わかりました。そうしたら、早速書きましょう。
鈴木：そうですね。先ほど近藤さんが説明したフレームワークが二つあります。StrutsとHibernateです。皆さんにこれらのフレームワークを上手に使ってもらうため、今回のプロジェクトでは、わざわざもう一つ薄いレイヤーを用意しておきます。すなわち、StrutsとHibernateに対するスープークラス：kaiwaJSP,KaiwaAction,KaiwaActionForm,KaiwaViewClass,KaiwaBusinessClassなどを書いておきますから、皆のコーディングはこれらのスーパークラスから出発すればよいのです。
近藤：それと、各スーパークラスの使い方に関しても、例題のクラスを用意していますので、皆さん参考にしてください。
皆：どうもありがとうございます。
鈴木：それでは、今日のミーティングはここまでです。
１６．コーディング標準
会話の背景：
前回はフレームワークについて述べたが、それとともに今回はコーディング標準に関して述べる。コーディング標準は各ベンダーが出している。例えばサンマイクロシステム社が提唱したJavaのコーディング標準などがある。また国際的な標準もいろいろある。しかし、それらの標準のほとんどは全晩的に論じているので、初心者には大変だし、レビューも大変だ。それで、各社は大抵自分の都合で、各自のガイドラインを持ち、要点だけを強調することが多い。
登場人物：
鈴木― PL
田中、山田、前田― PG
会話：
鈴木：おはようございます。
前回はフレームワークの話をしましたが、現在はコーディングに入ったところです。今回は新人に入ってもらうし、コーディング標準のことをもう一同繰り返す必要があるのではないかと思いますから、今日はこの辺りについて意見交換しながら話しましょう。
前田：新人の前田です。よろしくお願いします。
コーディング標準にかんしては、学校ではサンマイクロシステム社のjavaコーディング標準を勉強しました。しかし、実際的なコーディングはしていないため、いろいろと教えてください。
鈴木：それはよかったです。うちの会社もサンのJavaコーディング標準をベースにして、コーディングのガイドラインを作りました。今は会社の内部ウェブサイトに置いていますので、皆さんぜひこのガイドラインに従ってコーディングしてください。山田君、田中君、自分の経験をはなしてもらえます？
山田：そうですね。私も経験不足ですが、この二、三年でJavano仕事をやって、いくつか覚えただけです。
一番印象深いのは確か命名規則です。チームワークなので、勝手に名前を付けてはいけないことは勉強しました。まずは、パッケージ名とファイル名ですね。これは会社のるーるがあります。たとえば、すべてのプロジェクトのパッケージは必ずcom,clientcomanpy-name.project-nameのようになっているとか。
その後は、クラス名とメソッド名です。これまではいろいろな言語を勉強したので、いくつかの命名方法を混在していました。いまのガイドラインによると、Javaの場合は、いくつかの名詞や動詞の綴り（つづり）だけでもいいです。ただし、クラス名だと必ず大文字で始まり、属性とメソッド名葉必ず小文字ではじめていくことが必須です。例えば、クラス名はKaiwaClassで、メソッド名はnihonKaiwaMethodのようになります。それと、定数名の場合はキャピタルとアンダーラインで綴ることしか許しません。
前田：命名するときに、日本語を使ってはいけませんか？
鈴木：そうです、日本語を使ってはいけません。全てのコーディング命名規則としては、英数字だけが許されています。その理由は、コンパイルした後に実行システムへ行こうしたり、また別のツールと結合したりするときに、２バイトのコードが入ると予想外のエラーが発生する恐れがありますから。
田中：私が一番経験したのはコメントでした。
最初コーディングするときにはコメントを書く習慣はなかったのですが、それではだめだとチームリーダーから言われました。クラスのコメントにはこのクラスの目的あるいは振る舞いの明確な説明を書きます。その後、やはりコーディング日付、作者、バージョンなどを書きます。
メソッドのコメントには目的、引数、リターン値、例外などを書く必要があります。最近はStrutsを使うときに、ANTでconfigファイルを自動的更新するため、各Actionクラスに特別な情報をコメントとして書くことが必要になりました。これはケースバイケースですが、それでも守らないといけないですね。
鈴木：実はコーディングではJavaでも、.NETでも、原則的にあまり変わらないと思います。すなわち、コーディングがわかりやすく、他人でも読めること。
コーディングのスタイルでも言えますが、原則的にいうと、一つのクラスは20から30ぐらいのメソッドで、一つのメソッドには30行以下などのルールがあります。またコードの行はひとまとまりのパラグラフとなるような4，5行を連続させ、その間には空行を一行いれて、読むときは日本語や中国語の詩のように読めると本当にうれしいですね。
前田：そですか。なかなか面白いですね。
鈴木：もう一つは、コードはパブリック（public)とプライベートインターフェースをはっきり分けないといけない。ここまでのコードを読むと、大部分のコードはほとんどパブリックなインターフェースしかなかったようですが、それではいけませんよ。
やはり、いくらわかりやすくでも、よそと関係ないコードは見せてはいけないので、それらのコードはプライベートなインターフェースにしてください。言い換えると、いいコーディングとは、パブリックなインターフェースをできるだけ少なくなるように書かないといけません。
田中：それと、コードを”掃除”することも大事だと思います。
まず、コードを綺麗にすることです。コードなかの空白、空行、タブ、それとif-then文やwhile文の括弧などをガイドラインで指定したように書かないといけません。
リリースする前に、あるいは各段階では、適当に自分のコードをチェックして、もう要らないコードをよそにだしてしまうことはよくありませんから、自分で掃除しなければなりません。コードはわれわれの製品なので、いつも必要なコードだけを綺麗に出荷することを大事に心かける必要があります。
鈴木：最後なんですが、単体テストはもちろんのことですが、単体テストしなくても、本人が書いたコードの自己テストが必要です。たとえばクラスごとに、パブリックなインターフェースに対するテストメソッドをつけることを習慣にすれば有用だと思います。それでは、今日のミーティングはここまでですが、コーディングに関する議論は続けてください。
没有评论:
发表评论