#Book [[📒アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知]] ## 2-1 実装方針 - [[📚2-1 実装方針]] ## 2-2 ブランチ戦略 - 一旦、skipする ## 2-3 コミット - [[🖇️AngularJS's commit message convention日本語訳]] - 💭これは、参考にしたいかも - コミット履歴を書き換える方法 - [[🗃️git]]コマンドの紹介 - 直前のコミットを修正 `git commit --amend` - rebaseで履歴を書き換える`git rebase -i` - 任意のコミットに修正を追加 `git commit --fixup=<commit>` - 物語のようにコミットを並べる ## 2-4 コードレビュー - [[🗃️コードレビュー]]の目的 - **ソースコードを書いた人の持ち物からチームの共同所有物にする**(筆者の考え) - バグを見つけたいのであれば、[[🗃️テストコード]]を書く - 書きにくならば、開発した人が動作確認を行うべき - 限られた人がコードレビューをする - メリット - 責任の所在が明確 - コードレビューの指摘が通りやすい - 意見が分かれても言い争いになりにくい - 諸刃の刃 - 教育や、学習の機会として活用していくと良い - [[🖇️10分間で説明できないコードならリファクタリングを始めよう]] - デリバリーを短くしていくには、手が空いているメンバーが、レビューするとよい - wip 制限 - レビューをスムーズにするために、linterや、 formatterを入れるとよい - pr にコメントを入れてくれるツールがある - danger js - Reviewdog - —allow emptyを使って空のコミットを積んで、実装着手と同時にPRを作るとよい - 一回のコードレビューで、コメントが沢山着く時は、コードレビューの分量を見直すとよい - 小さな単位で分けられないか検討 - 同期的にレビューを実施する - コードレビューでコメントが思いつかないとき - コメントをするべき観点がわからない人は以下に当てはまる - 昔ながらのコードベースでどこに何を書くのか決まっている - 良い設計へと改善していく習慣が個人やチームにない - 本人が動くプログラムを書くことで精一杯で良い設計を考える余裕がない - 本人に設計を継続的に改善していくための技術的なスキルがない - 💭これ自分に当てはまるのかも - モヤモヤを共有することで、議論のきっかけになるかも。十分に貢献といえる。 ### 2-5 協業作業 - スウォーミング - 一つの事柄や課題に対して、関係者全員で「群れ」のように取り組むこと - 一つの優先すべき開発に集中できているか？ - 個人の成果よりもチームな成果を最大化することを重視できているか？ - どこかで単独作業に切り替えたほうが、効率良くなることもあるので、こだわりすぎず判断することが大切 - 💭これは前にモブにこだわりすぎてあった気がする。 [[🗃️タイムボックス付きの探求]]は、その例だと思う。 - ペアプログラミング - 進め方 - 作業のゴールを確認する - ペアプロを一区切りする時点での「ありたい状態を話す」 - 💭この発想はなかったかも - 作業単位と順番を確認する - ドライバーとナビゲーターの役割を決め、開発を開始する - 役割を10-15分で交代する - ナビゲーターの役割 - ドライバーと認識が合っていることを返事で伝える - ドライバーの知らないことを調べて教える - ドライバーの悩んでいる事項を一緒に考える - ドライバーの発言に引っかかることがあれば質問する - 💭細かいけど、どれも大事 - ペアプロの注意点 - 定期的に交代する - 休憩をきちんと取る - 目的を明確化する - 相手に耳を傾ける - モブプログラミング - 進め方 - 役割は10分程度で交換する - 人数は3〜5人くらいにする - ナビゲーターの役割が曖昧にならないようにする - ペアプログラミングの効果と影響 - 工数は2倍にならない、15%程度の増加にとどまる - ペアプログラミングにやって、かから時間が安定する - 方針確認で、問題をあらい出せる - どちらかがわかることがおおい - 2人とも知らない時は、すぐ他の人に聞ける - 調べる時は手分けして効率があがる - [[🖇️モブプロの聖地 Hunter Industries で学んだこと - kawaguti’s diary]] ## 2-6 テスト - テストの観点 - 検証 - 正しい動作になっているのか確認すること - 要求事項が満たされていること - 手段 - 単体テスト - 結合テスト - 妥当性確認 - 要件が満たされていることを客観的な証拠で確認すること - 手段 - ユースケーステスト - ユーザビリティテスト - 探索的テスト - 利用者の状況に依存する部分が多い - 自動化には不向き - [[🗃️自動テスト]] - テストファースト - 実装よりも先にテストを書くこと - [[🗃️テスト駆動開発]] - [[🗃️テストコード]] を書いて、実行、失敗させる→テストの成功を保ちつつ、リファクタリングを行うのサイクルを繰り返す - [[🗃️テストコード]] を読みやすくする技術 - テーブル駆動テスト - テストの条件と期待する結果の組み合わせを複数種類用意したテーブルを用意し、テーブルに記載されたデータを使ってテストを行う - テストデータとロジックが分離される - ミューテーションテスト - [[🗃️テストコード]] の確認項目が十分網羅されているか、テストの品質を評価する手法 - ソースコードの一部を改変して、意図的に不具合を導入させた上で自動テストを実行し、失敗するのか確認する