58. チーム開発を円滑にするコツを覚えよう

95IG7y3HHX7yl4/07_チーム開発/03_チーム開発を円滑にするコツを覚えよう/課題.md

@@ -0,0 +1,62 @@
+# 課題1（質問）
+## PR（プルリクエスト）は小さく提出することが良しとされる現場が多い傾向にあります。
+- [巨大なプルリクの弊害と対策](https://agilejourney.uzabase.com/entry/2023/07/31/103000)
+  - フィードバックを受け取るのが遅くなる
+
+- PRが小さいことのメリットはなにか
+
+1. 1時間以上かかるコードレビューは低品質になる
+> Making Software ―エビデンスが変えるソフトウェア開発という書籍の18章「Modern Code Review」では1時間を超えるコードレビューは品質が低下することを示す研究が紹介されています。[4]
+>
+> 加えて、シスコシステムズで行われた調査によると、1時間に500LOC(Line of Code)を超える速度でレビューを行うと、不具合の検出効率が低下することが分かったと報告しています。
+
+[Pull requestの理想的なサイズとその理由](https://shorturl.at/84Ii1)より
+
+- 小さいPRを作るときに気をつけることはなにか
+  1.  1つのPRに含まれる関心事をできるだけ減らすことで、レビューワーにも理解しやすいPRにする。
+  2. タスクに含まれている作業を洗い出しておく
+    タスクに含まれる作業を洗い出し、サブタスクを作成する。サブタスクごとにbranchを分けて実装し、PRにする。
+  3. リファクタ/変更/追加でPRを分ける
+    機能実装で、コードが汚いからリファクタリング仕様となったら、リファクタリングを行うbranchと、リファクタリングBranchを基にした機能実装を行うブランチを分ける。
+  4. git reset を活用する（PR作成前のみ）
+    探り探りのタスクでは、計画的に分散してPRを出すことは難しいので、実装後にコミットを巻き戻して、実装を確認して、実装を分離しPRにする。(整理する際はbranch切ってからやるのが良いかも)
+
+
+## 設計・実装に関する情報の置き場はたくさんあります。どのような情報をどこに置くべきでしょうか？
+
+### Notionなどのドキュメント
+- プロジェクト全体の概要
+- タスクの管理情報
+
+### README.md
+- プロジェクトの概要
+- 依存関係とインストール手順
+
+### プルリクエストの説明欄
+- 変更内容の概要
+- 確認手順
+- 関連するIssueやタスク
+
+### コミットメッセージ
+- 具体的な変更内容
+- (option)理由や背景
+
+### コードコメント
+- 複雑なロジックの説明
+- 関数やクラスの目的
+- 重要な注意点
+
+### 型定義
+- データ構造の説明
+
+[コードのコメントとしてできるだけ実装に近い箇所におく。](https://shorturl.at/pZNC4)
+
+# 課題2（実装）
+## GitHubのPRやIssueにテンプレートを設定する機能があります。実際に作ってみましょう！
+https://github.com/YamazakiYusuke/praha-challenge-ddd/blob/master/.github/PULL_REQUEST_TEMPLATE.md
+
+
+# 課題3
+## チーム開発を円滑にするために上記以外に効果のありそうな取り組みを考えてみて、ペアに共有してみて下さい
+- 定期的に技術的な課題や全体に影響する実装を共有する場として、Topic定例を行う。
+- 勉強会などで知識を共有する場を設ける