ja_JP: cont_工程

工程

以下の手順を原則とします。

❌ 禁止事項

• issue なしの commit
  • それに対する因果定義と変更設計がないため、その区間の要求や思想がブラックボックスになる可能性があります。
• issue に 直接ソースコードを書くこと
  • 言葉にできないことを実装すると、その区間の要求や思想がブラックボックスになる危険性があり、さらにレビューがしにくくなる可能性があります。
  • また、これは「文章」として読み返すことを前提としており、ソースコードは人間から見て直接的に定義・設計を表すものではないため、文章上に配置することは無意味です。
  • しかし、ソースコード内で「定義されたもの」など、文章ではイメージすることが不可能な場合はその限りではありません。

⭕ 積極的にすること

• ソースコードを見て発見したことを、しっかりメモする
• わかりにくい振る舞いなどは、図に書き起こして明確にする

機能追加・改善

1. 要求投稿

• 要求の大きさはあまり関係ありません。次の因果定義で要求を詳しく分割するためです。
• 要求投稿の内容に質問がありましたら、要求投稿を行った人に直接質問してください。
• 要求投稿の内容が不適切 もしくは このプロジェクトに対して不適当だと思った場合は、発議をしてください。
• もし要求投稿を取り下げる場合は、その issue を閉じてください。

2. 因果定義

• 対応する issue のコメントに投稿してください。
• 必要な仕様を挙げるだけでじゅうぶんです。細かな実装を書く必要はありません。
• 現在の状態と対比させて書くことで、より分かりやすく書き表すことができます。

3. 第1回レビュー

• 因果定義を行った人以外が行います。
• ここでは、因果定義が妥当であるかどうか、をチェックします。
• チェック項目
  • 要求に対して、その仕様は適切であるか?
  • 要求に対して、取りこぼしたと思われる あるいは 必要ではないと思われる 仕様はないか?

4. 箇所追跡

• 対応する issue のコメントに投稿してください。
• 「ここだけであろう」という思い込みは排除し、検索機能などを用いて確実に実装する箇所を洗い出してください。
• ファイル単位で十分です。細かな関数を書く必要はありません。

5. 第2回レビュー

• 箇所追跡を行った人も含めて行います。
• ここでは、箇所追跡が妥当であるかどうか、をチェックします。
• チェック項目
  • 仕様に対して、取りこぼしたと思われる あるいは 必要ではないと思われる 箇所はないか?

6. 変更設計

• 対応する issue のコメントに投稿してください。
• この文章はプログラムを実装する直前の段階のため、文は一意性を持つ必要があります。

7. 第3回レビュー

• 変更設計を行った人も含めて行います。
• ここでは、変更設計が妥当であるかどうか、をチェックします。
• チェック項目
  • 仕様に対して、その設計は適切であるか?
  • 文の一意性は確保できているか?

8. 実装

• コーディング規約に沿って、実装を行います。

9. commit

• commit 時には、resolve #(対応するissueの番号) を必ず含めて、issue を閉じてください。
• commit すると、自動的にテストが実行されます。

以上です。