読者です 読者をやめる 読者になる 読者になる

Eclipseに見る開発サイクルの秘訣

【レポート】JavaOne 2006 - IBM General Session: Eclipseに見る開発サイクルの秘訣 (MYCOMジャーナル)
http://journal.mycom.co.jp/articles/2006/05/19/javaone1/

ちょっと前の記事だけど。Eclipseがいかにして高品質なプロダクトを安定的に長期にわたってリリースし続けているか、というセッションのレポート。このセッションはすごく参加してみたかった(英語が理解できるかは別として・・)。

以下、気になった点(というかほとんど全文だけど^^;)を抜粋。

開発の段階ではFitnessは徐々に低下していくが、安定化の段階でそれを適切なレベルまで引き上げてからリリースする。各マイルストーンでは常にこのリズムでFitnessが上下する。たとえマイルストーンといえども、Fitnessが低下したままでリリースすることが無いという点がポイントである。このリズムによって、製品の品質を常に一定以上の水準に保つことができる。
初期段階では少人数のチームによって細かなアップデートを重ね、ある程度の段階でプロジェクトチームによる週単位でのビルド工程に移る。そして最後にコミュニティ単位でのマイルストーンの開発に着手するという流れである。このときに重要なのは、成果物を自分達で使用し、常にフィードバックを得ることだという。
まず重要なのは繰り返し処理や成果物の提供、プロダクトのパッケージングなどを容易にし、同時にリファクタリングを実施、APIの安定性を高めることだという。

そして・・
次に重要なのが、常にパフォーマンスを維持することだと説く。そのためには開発サイクルにパフォーマンス・テストを導入し、常にパフォーマンスを把握できるようにする。適切な分析のためにパフォーマンスの視覚化ツールなどを使用するのが望ましい。

最後のパフォーマンスの話は、最近ものすごく痛感している。パフォーマンスって、ついつい後回しになってしまいがちですよね。仕事でモノ作ってると「とりあえず動くものを」っていう空気がものすごく出ちゃうんだけど、このまま進んでしまうと、「とりあえず動く->パフォーマンスでない->設計からやり直し」っていう最悪のパターンになりえる。てか、ちょっとウチがそうなってる(T_T)。同じようにテストとかドキュメンテーションも、やはり後回しにしてしまいがちな工程なんですが、コチラの場合は修正はたくさん入ったとしても設計からやりなおし、ってことはあまりない。つーわけで今後はモノを作るときは、どれくらいのパフォーマンスが必要か、ってことを設計段階から重視してくように心がけたい。プラス、デイリービルドのプロセス内で自動テストと同時に、自動パフォーマンステストなんかも組み込んで、かつうまくレポーティングできるような仕組みができればうれしい。で、それを実践してるのがEclipseなんだろーなー。