そろそろ終了ということで

Teedaを導入しての始めての開発ということで、このブログでもMLでも支援受けまくっていたけど、ようやく収束してきた。
今回は、Eclipse+Subclipse+Teedaのすべてがお初。間で、いくつか書いたけど、とりあえずここでもう一回まとめてみる。

設計１。全画面を流れとしてみていない。テストで言えば単体テストしかしていないというところかな。とりあえずリンクだけでも書いてストーリーとしてレビューとかしていないんで、画面に必要な項目がないのに気づかない。レビューの中心を画面で行うのなら、遷移は実装後ではなく、設計段階でHTMLレベルで仮にでもしておかないと、使用したときの雰囲気が出ない。
設計２。帳票も同じ。PDFやCSVをあらかじめ作って(暫定なら、OpenOfficeか最新のWindowsOfficeで変換できる)遷移させて確認する。このときに遷移をどうしているのか見れば、設計に無理(値が引き継げるかどうかなど)がないか事前にわかる。
実装１。Eclipseの使い方、Subclipseの使い方について、ケーススタディ事前あるいは、特異事象発生時にする。マニュアルや周知でよいと思われがちだが、メンバーのスキルが低い場合、書いててもスルーされる傾向にある。実際に目で見て体験させない限り底上げにならない。
実装２。インフラにかかわるコードと業務にかかわるコードの違いを共有する。思ったように動かないからといって、安易にcommitを入れたり、try..catchを入れてしまわない。frameworkの場合、どこでも何でもかけるという発想は悪と認識させる。
実装３。たとえ設計時に見落としていても、コードが数千ステップにもなるのなら(まして、その中に業務機能が複数入っているのなら)、検知して分割できるようなレビュー等の体制を作っておく。作り捨てならいいんだけどね。
テスト１。これは、今回実施できなくって苦しんだ反省。その機能を実行したときにどんな入力を与えたら、どんな結果になるかをいくつかのケースであらかじめ作っておくこと。たぶんこれはレビュー対象になるから、設計段階でやっておくべき。で、できれば、それをjunit化しておけば、確認がすごく楽になる。
テスト２。テスト結果は印刷レビュー可能なものが望ましい。どこまで加工が必要かまた、利用できるかどうかを事前に十分に確認する。

製造以外にもあるけど、それは、範囲外ということで除外（が、実際はここがでかい）。

後、できれば、全体を一巡するようなプロトを実施して、あらかじめ複数人で認識を共有できいればいいかな。
まぁ、次も使ってもらえるのならもう少しましになるかな。

設計でもいかにしてプログラムに落とすかを中心に考える傾向が強い。結果、ロジックとかを考える。
でも、昨今くらいに短期間で結果を出そうとしたら、インプットとアウトプットを先に考えないと結果が正しいかジャッジできないのよね。ロジックなんて、お客様の話を聞いて書き下したものでしかないし。
だから、実際の値とかを元に、入力パターンを示して、結果を示せば、ロジックなんぞ、後の人が考えてくれる（間違ってても気づく)んだけどね。

jUnitとかを使ったTDD系のスタイルはまさにこの方法だと思うんだけど・・・PGレベルでだけやってても受け入れられないなぁ。

反省点は多いけど、Eclipse+Subclipse+Teedaを採用したことで、

エディタに比べ、エラー確認、名前の変更など格段に楽になった。
共有ファイルを変更する必要がなくなり、各自独自にデバッグなどできるようになった。
JavaとSQLが分離しており、また、実行時に実際に流したものに近いSQLが出力されるため、確認＆変更が非常に楽になった。
最初は頻繁に再起動していたが、なれてくると、Tomcatの再起動を忘れてしまうほどさくさく開発できる。

とツール採用のメリットも多々ある。というよりか、この仕組み以外だったら、たぶん、いまだに収拾してなかったと思う、本当に感謝です。

ツールで言えば

拠点が分かれていて、オンラインで接続不能の場合の同期の取り方。

が、今後の課題かな。まぁ、これは、ツールを変えるより、運用をどうするかだろうなぁ。