(文責:阿部)
分析モデルのクラスを実装し、先に作成した３つのシナリオのユースケースをCUIで実現することを目標にした。
みるみるをWEBアプリケーションとして開発するための前段階として、CUIで動くものを作ることにした。 シンプルなものを作ることにより、分析したモデルの問題点を早期に見つけることができる。 このようなプロトタイピングを行った結果、モデル部分が確実に動作することが保証されたので、 その後はWEBアプリケーション化に集中することができた。 開発の逆戻り、作り直しがほとんど起こらなかった
私たちは自らの学習も兼ねて、それぞれ１つのプロトタイプを作ることにした。 これにより、ひとりひとりがみるみるの一連の動作を把握することができる。 また、ソースコードの書き方に差があることを確認し、 書式を統一することにより、今後の共同開発をより円滑にすることを狙った。 ソースコードをそれぞれが必要に応じて各自のWEBページに掲載し、 過程も互いに閲覧できるようにした。
松澤氏の指導の下、ソースコードレビューを行った。それぞれのソースコードを比較して議論することにより、自分のソースコードの問題点や他の人の良い点を知ることができた。また、人が読んでわかりにくい点を指摘されることは大変貴重である。
人が読んでわかりやすいソースコードにすることに重点をおいて、できるだけ書式を統一した。 コメントをしっかりつけることや、まとまりごとにセパレーターを置くようにした。 これらの注意事項をまとめ、コード規約を作成した。（付録）
クラス名や変数名は日本語で書かれていたため、３人それぞれが独自に英語化し、バラバラになった。 例えば、担当者名という１つの変数でも、teacher、teacherName、lecturereなど様々な英語名をつけることができる。 共同開発するにあたっては、もちろん統一する必要がある。議論の際にも認識の違いによって混乱することがあり得る。 個別に実装を始める前にきちんと英語名も決めておくべきであった。
特に、議論になったものは「回答クラス」である。 回答クラスのオブジェクトは選択肢の内容１つとその選択肢を選んだ学生のリストを持っている。 たとえば、ある質問の選択肢が「YES」と「NO」ならば、 回答クラスのオブジェクトは「YES」で１つ、「NO」で１つ存在する。 普通に回答を英語化すればAnswerとなるが、このクラスの意味を考えると回答とするべきなのか選択肢とするべきなのかという疑問が起こった。 議論の結果、今まで回答クラスとしていたものは意味としては「回答するべき１つ」であり、このクラスのオブジェクトのリストが回答であるという結論に達した。 よって、回答クラスの英語名はAlternativeに統一された。