2010年11月15日

Wave Summit Development Practices

先週は Wave Protocol Summit が開催されたそうです。 いくつかの アナウンスプレゼンテーション がありました。 Wave のアーキテクチャやプロトコル、リアルタイム向けのエディタに関する説明がスライドおよびビデオで見られます。

その中に開発プロセス一般に適用できそうなスライドがありましたので、ちょっと日本語に訳してみます。 Lennard de Rijk による Development Practices From Idea to Patch です。


開発の進め方 - アイデアを形にするまで

議論すべきは「変えようとする気持ち」です。 これが正しいと言うわけではなく、私たちが実際にやっていることです。

目次

  • 大きな変更の際にはドキュメントを書く
  • Eclipse に取り込む
  • ソースコードのスタイル
  • 不可分で過不足のない、小さな単位のコミット
  • コミットする前にコードレビュー
  • 継続的なビルドおよびテスト
  • 依存関係に取り組む

設計ドキュメント

いつ?:

大きな変更や新機能を考えるとき

なぜ?:
  • コミュニティの他の人たちと何をどうやって進めるか話し合うため
  • 大量のコードを書き上げる前に、方針ついて合意するため
  • 後でドキュメントが古くなってしまうことは気にしない
どうやって?:
  • 対象となること
  • 要求
  • 設計
  • 対案

Eclipse に取り込む

デモビデオ

  • チェックアウト
  • Eclipse で「新規プロジェクト」
  • Eclipse のプロジェクト設定
  • Eclipse で Ant
  • Eclipse で起動
  • Hosted mode?

コーディングスタイル

  • クラスをまたいでも読みやすいように
  • レビューしやすいように
  • パッチがより詳細なものになるように (全てが同じスタイルで記述されているとき)
  • メンテナンスしやすいように
  • Eclipse のフォーマッタがある

小さな量でのコミット

  • それぞれのリビジョンが意味のあるものにする
  • 間違えを分離しやすく
  • レビュアーにやさしく
    • レビュアーがコミットを分割するようにお願いするかもしれません
  • 早いうちに、そして頻繁にコミットする

コードレビュー

  • コードの品質を向上
    • メンテナンスしやすく、変更しやすくする
  • レビュアーはコードの妥当性を確認する
    • 正しい問題を解決しているか
    • 以前に書かれているものでないか
    • 自然な表現であるか
    • そしてある意味で、コーディングスタイルに忠実であるか
  • ソースコードのそれぞれの行が、ふたりの目に触れる
    • コードに内在する知識が共有される
  • http://codereview.waveprotocol.org

継続的なビルドとテスト

  • 最近の破損箇所を分離するため

  • ここで動作

    http://google2.osuosl.org:9090/

  • 壊れている場合はそれ以上コミットしない。修正のみ。

依存性に取り組む

  • オープンソースを扱う。サードパーティのもの。
    • 車輪の再発明をしない
  • WiaB は Apache 2.0 ライセンス。 (訳注: WiaB は Wave in a Box の略)
    • ライセンスを表示してくれさえすれば、どこで使おうと自由
  • 新しい依存性が必要になったら
  • 可能であれば適切なリリースを使う
  • バージョンとソースおよび使い方を表明するために README ファイルを取り込む
  • ソースファイルを含めるようにする

感想

個人的にはこのセンテンスが印象的でした。

Don't worry about the doc becoming out of date afterwards

スライド本文ではなく発表者用のノートに書いてある "Not telling you it is right, just what we are doing." を表しているんじゃないかな、と思います。

「素早く開発するために仕様書を書かない」という会社もあるみたいですが、基本的には規模の問題なので、いろいろですね。

コメントを投稿