紫だちたる雲の細くたなびきたる blog

春はあけぼの(をかし)

僕ならこうする

  • Eclipseはさっさとバージョンアップ。3.1の方がずっと評判いいんだから。

っていうかちゃんと継続的に情報収集してるの?って言いたい

バグがどのくらい出たかなんて単体テストでは意味をなさない。「ちゃんと動くのか?」「要件を満たしているのか」の方が100万倍重要。逆に結合テスト以降の工程ではバグが最初どのくらい出て、それがちゃんと減ってきているかどうかの確認も重要となってくるので、バグ票は必須だと思う

  • 詳細設計書は書かない。

ある程度まで掘り下げた基本設計書と画面仕様書があれば十分。プログラム自身*1JavaDocによるAPI仕様書を詳細設計書とする。だからソースコードのコメントが重要。今回の規約ではクラス変数のコメントがなぜかjavadocコメントではない。Eclipsejavadocコメントをバルーン表示してくれる機能があるので便利なんだが。

  • プロジェクトに新規参入(今回の僕みたいにだ)した人には一週間ベテランを付けてペアプログラミングさせる

ちゃんとベテランも成果物をあげられるうえ、新規参入者のプロジェクトへの習熟度が格段に早くあがる。つまりは生産性が大幅アップ。翌週には普通の分量の仕事を安心して任せられる筈。特に今回のように規約でガチガチのプロジェクトには有効な筈だ。

  • プログラムはみんなの物

共通部品といえども誰でも修正ができるようにする。せっかくCVSでバージョン管理してるんだから共有しない手はない

  • 規約は最小限に。でも絶対厳守。

共通部品と言えども例外は認めない(っていうかgetValue01なんてメソッドはダメでしょう!これをちゃんとした名前(get〇〇Codeみたいに)に変えるだけでどれだけ開発効率が上がる事か!)

うん、開発効率は今より数段上がるに違いない!

*1:ここでのプログラムとはソースコードを指している