制作の流れ
計画を立てましょう。計画を立てると計画以上に良い方法が見つかります。
たとえ良い方法が見つからなくても計画通りに進めれば大丈夫です。
計画通りにいかなければその原因を特定して説明することが出来ます。
GitHubのissueとプルリクエストを中心に大まかな制作の流れを解説します。
現時点でわかるすべてをissue化する
制作するものがコーポレートウェブサイトだったとして、分割できない一区切り（例：buttonコンポーネントの作成、aboutページのコンテンツ部分）にタスクを分解しそのすべてをissueとして登録します。 issueには以下を記載するとよいでしょう。
- デザインデータへのリンクやキャプチャー
- このissueで盛り込んでほしい内容（例：hover、focusスタイルも忘れずに。href propsでアイコンを出し分けられるようにする。など）
- このissueでやらなくて良いこと（例：画像は支給待ちなのでダミーとする。他issueで対応中のためスクロールフェードインは実装しない。など）
issueにしたためる内容が精緻になるほど正しいものが早く実装されます。ただし、issueの精密さは通常、納品物ではないため制作プロセスの中での経費としての扱いになるでしょう。コストのトレードオフを意識して記載しましょう。
初期構築であれば大概記載すべき項目は同じなので、issueのテンプレートを作成しておくのも有効です。
issueをブランチ化し作業開始する
ブランチ名について規定はしませんが、筆者はissue-37など制作されたissue番号で作成するようにしています。
これは、シングルタスクでissue対応していきmainブランチへマージしていくことを前提としておけば、ブランチ名は特に重要ではなくなるからです。
またissue番号であれば、担当者にアサインしたタイミングでGitHub Actionsから自動的にブランチを作成するのが容易です。（これにより、mainブランチの更新などをローカルで行い忘れたために枝分けを間違えるなどの本質的ではないミスを防ぐことが可能です。）
さらにブランチ作成時にDraft状態のプルリクエスト（PR）までGitHub Actionsで作成しておくとコーディング後の作業がスムーズです。
issueブランチでは当然そのissueの内容しか作業しません。もし、追加で別作業をする必要がある場合は、
- 新たなissueを作成する（基本はこちら）
- 現在のissueの対応内容を加筆しプルリクエストでもレビュアーへ伝える
としてください。
参考リソース：issueからブランチとPRを作成するワークフロー
monoharada/auto_create_branch.yml
commitはわかりやすくシンプルに
プロジェクトやissueの大きさにもよってしまいますが、可能な範囲で「できるだけ細かい粒度のcommit」を作ります。
そうすることでcommitメッセージもより具体的になり、後日第三者が見ても、どの様な機能が追加されたのかがわかるようになります。
commitメッセージ
Commitizenを導入するか参考にしてprefixをつけてしまうのが最もカロリー低く良いcommitメッセージを作成できると思います。 また、将来commitを抽出しそうな目的を明示しておくことも有効です。
feat: style xxxxのhoverを調整したfix: component Headingのxxx propsの型に△△△を追加fix: page 品管チェックFB対応commitメッセージはどの様なことを行ったかを端的に表現しメッセージだけでおおよその対応内容がわかるようにすることが重要です。
commit前に自動的に静的テストを実施する
Lefthookやhuskyを使用しリモートへのcommit前に各種linterを実行します。 コードの基礎的な品質を一定に保つために必ず設定し、実行されていることを確認してください。
合わせて納品時に行うことを確認し、
- 実機ブラウザ
- キーボード操作
- アクセシビリティの機械テスト
を行いましょう。
プルリクエスト（PR）を作成する
issueに含まれるすべてのコーディングが完了し、自己チェックもできたらプルリクエストを作成します。
プルリクエストは「自分のコード」を「製品」または「みんなのコード」にするためのステップです。「自分のコード」のままではクライアントに納品するには不十分であることを理解しましょう。
プルリクエストでは、
- 対応領域
- 対応内容
- 確認したもの
を明記します。プルリクエスト作成者（レビュイー）がプルリクエスト内で「〇〇について迷っています」「△△はまだできていません。どの様にすればいいですか？」などの質問や未実装についてコメントすることは不適切です。 コードの責任はレビュアーではなくレビュイーにあります。未実装のままPRを出さない、迷ったとして今回どの様な理由でどの様にコーディングしたかを自信をもって明示します。
またレビュー負荷を下げるために一つのPRには可能な限り少ないファイル数でレビュー依頼するようにしましょう。そのためにはissueの切り出しの時点でどの様なファイル提出になるかも改めて想定する必要があるでしょう。
レビューの進め方
コードの内容を理解できること
レビュアー：何を行っているか理解できないコードについてはレビュイーに確認してください。
レビュイー：確認があったコードについて内容を返答します。
レビュアー：返答された内容を元にコメントを追加するか、よりわかりやすい実装方法を提供します。
レビュイー：レビュアーの返答を盛り込めるように努めます。
コードの品質を確保する
レビュアー：関数名やクラス名などが後日第三者が見ても理解可能で適切なものか判断します。
レビュイー：指摘された命名について、より分かりやすいものへ変更します。
ブラウザでの検証
レビュアーは許容範囲で構わないので、デザインの再現度、キーボード操作やスクリーンリーダーでの操作についてPRの対応箇所をチェックしましょう。
レビュアー：すぐに指摘できる不備はキャプチャとともに指摘します。この際にどのコードが問題であるかまでを指摘する必要はありません。
レビュイー：指摘された不備は今回のPRでの対応領域であれば修正します。そうでない場合は新たなissueを立てるかチーム全体へ共有します。
レビュアーはコードに問題がないことを確認したら承認し、レビュイーがコードをマージします。
PRがクローズされたら対となるissueもクローズします。
この繰り返しで制作を進めることをオススメします。