開発の進め方 - Sunkenship1995/GLUT GitHub Wiki
開発の進め方
何か追加したい機能がある、もしくは修正したいバグがある場合...
- 内容を issue に起こす
- 対応内容を検討し、レビューを行う
- コードを修正し、issue の番号に関連付けてコミットする
- コードの内容および修正が十分かレビューする
- OK なら issue を close して終了。ダメなら 3 もしくは 2 からやり直し
(あくまでうちのチームがこんな感じというだけなので参考程度に...)
内容を issue に起こす
- 書くべき項目としてはこんな感じ(機能の場合)
- 説明
ざっくりとした内容 - 要件
本 issue で達成すべき事柄。何を行うのか?ということを明確に。 - 終了条件
本 issue を終了するための条件。「要件がすべて満たされること」ってパターンが多い? - 成果物
修正したコードのコミットへのリンクやレビューの議事録の格納場所など
- 説明
- 不具合の場合は、現象、再現手順、原因、対策...など
対応内容を検討し、レビューを行う
ここをしっかりやっておくと手戻りが少なくなっていい感じ。
- 機能
- 要求機能DR
なにがやりたいのか?(=要求)/ それにはどういう機能が必要か?(=機能) - 設計DR
具体的にどうやって実現するか?
- 要求機能DR
- 不具合
- 調査DR
不具合の原因はなにか? / どうやって対処するか?(これ結構大事!)
- 調査DR
コードを修正し、issue の番号に関連付けてコミットする
コミットするときのメッセージは大事!
書き方はチームのやり方に合わせる。
例)refs #12345 Mod SelectionPane.java OKボタン押下時に null チェック追加
個人的には当人が後からみて内容がわかる程度には書いておいたほうがいいと思う。
(マージが必要になったときに楽)
コードの内容および修正が十分かレビューする
いわゆるコードレビュー。
修正したコードを他人に見てもらい、問題がないか確認してもらう。
他の人の環境でちゃんと動くかの確認をしてもらう場合も。
(自分の環境では動いても、他の人の環境では...ということは往々にしてある)
また本来の開発の場合、このあと、機能テストや第三者テストの方法検討と実施を行う。
単体テストやテストコードによるユニットテストは、コーディングの中で行うことが多い。