先週は Wave Protocol Summit が開催されたそうです。 いくつかの アナウンス と プレゼンテーション がありました。 Wave のアーキテクチャやプロトコル、リアルタイム向けのエディタに関する説明がスライドおよびビデオで見られます。
その中に開発プロセス一般に適用できそうなスライドがありましたので、ちょっと日本語に訳してみます。 Lennard de Rijk による Development Practices From Idea to Patch です。
開発の進め方 - アイデアを形にするまで
議論すべきは「変えようとする気持ち」です。 これが正しいと言うわけではなく、私たちが実際にやっていることです。
目次
- 大きな変更の際にはドキュメントを書く
- Eclipse に取り込む
- ソースコードのスタイル
- 不可分で過不足のない、小さな単位のコミット
- コミットする前にコードレビュー
- 継続的なビルドおよびテスト
- 依存関係に取り組む
設計ドキュメント
| いつ？: | 大きな変更や新機能を考えるとき |
|---|---|
| なぜ？: |
|
| どうやって？: |
|
Eclipse に取り込む
- チェックアウト
- Eclipse で「新規プロジェクト」
- Eclipse のプロジェクト設定
- Eclipse で Ant
- Eclipse で起動
- Hosted mode?
コーディングスタイル
- クラスをまたいでも読みやすいように
- レビューしやすいように
- パッチがより詳細なものになるように (全てが同じスタイルで記述されているとき)
- メンテナンスしやすいように
- Eclipse のフォーマッタがある
小さな量でのコミット
- それぞれのリビジョンが意味のあるものにする
- 間違えを分離しやすく
- レビュアーにやさしく
- レビュアーがコミットを分割するようにお願いするかもしれません
- 早いうちに、そして頻繁にコミットする
- あなたの仕事を公にすることを怖がらないで
- Programmer Insecurity and the Genius Myth - Ben Collins-Sussman & Brian Fritzpatrick
コードレビュー
- コードの品質を向上
- メンテナンスしやすく、変更しやすくする
- レビュアーはコードの妥当性を確認する
- 正しい問題を解決しているか
- 以前に書かれているものでないか
- 自然な表現であるか
- そしてある意味で、コーディングスタイルに忠実であるか
- ソースコードのそれぞれの行が、ふたりの目に触れる
- コードに内在する知識が共有される
- http://codereview.waveprotocol.org
継続的なビルドとテスト
最近の破損箇所を分離するため
ここで動作
壊れている場合はそれ以上コミットしない。修正のみ。
依存性に取り組む
- オープンソースを扱う。サードパーティのもの。
- 車輪の再発明をしない
- 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." を表しているんじゃないかな、と思います。
「素早く開発するために仕様書を書かない」という会社もあるみたいですが、基本的には規模の問題なので、いろいろですね。
0 件のコメント:
コメントを投稿