個人開発では得られにくい!実務を通して得たチーム開発の知見3つ
今回は実務で開発をする中で「個人開発だけでは学べなかった」と思う実務における開発ノウハウを3つ書きます。個人開発出身でチーム開発の経験が少なく、やっていけるのか不安に感じている方に参考になれば幸いです。
1. 設計段階でレビューを依頼する
実装前に設計・実装方針をチームメンバーにレビューしてもらいましょう。設計段階でレビューをもらうことで、実装後のレビュー時に設計上の問題が発覚するということを防げます。また、設計のレビューをしていた場合、共通認識があるため実装のレビューもスムーズに行えます。
自分は設計段階にレビューをもらうことで、実装の手戻りが発生することがかなり少なくなりました。より良い設計について議論するのはチームメンバーの設計力向上にも繋がるので積極的にやっていきたいところです。
2. プルリクエストの粒度は小さくする
レビューをしたものの、差分が多い故にミスに気づけなかったことはありませんか?自分は過去に巨大プルリクを作成してしまい、ミスに気づけず、問題を起こしてしまったことがあります。レビュー時にもその問題を弾けませんでした。
当時のレビュワーとしては悲鳴を上げる差分の量
この量の差分になると1行1行の変更に問題がないかの確認、テストケースの洗い出し・動作確認のレビューは実質不可能です。(目安は 300 以下)
なので、プルリクエストは小さく保ちましょう。例えば一つの機能を開発する際にロジックの実装、APIの用意とフロントエンドの実装があるとします。
その際は、ロジック (Model や Service)、API (Controller)、フロントエンド (View) の実装をそれぞれで分け、プルリクエストを作成してレビュー、マージをしていくのが堅実です。
3. 実装前に仕様の決定者と認識を合わせる
個人開発の場合、機能のあるべき姿を決める決定者は自分です。しかし仕事でエンジニアとして開発をする場合、機能の仕様を決定する役割を持つのは自分ではありません。大抵はプロダクトマネージャーになります。
コードを書く前には、必ずプロダクトマネージャーと仕様を確実にしましょう。以下は仕様を確認していなかった場合の悲惨な例です。
レビュワー「このケースの場合、Aという挙動になるのですが問題ないですか?」
実装者「問題ないです。A の方が便利だからです(主観)」
レビュワー「それは、〇〇(仕様の決定者)さんに確認とりましたか?」
実装者「確認していないので聞いてみます。」
プロダクトマネージャー「それは B でお願いします。なぜなら〇〇だからです」
実装者「分かりました。B となるよう実装し直します;;」
こうなると再実装、再レビューが必要になってしまいます。僕は個人開発の勢いでこれをやってしまったことがあり、深く反省をしました。組織において仕様の最終決定者はプロダクトマネージャーです。実装前には認識合わせをしましょう。
予め仕様をドキュメントにまとめると良いです。プロダクトマネージャーも忙しいので、仕様をまとめ、非同期でレビューをもらってディスカッションするのが良いでしょう。
最後に
こう振り返ると実務だからこそ学べたことは多いなと感じます。他にもあるのでまた気が向いたら第2弾を書きます。
記事が良いと思ったらサポートをお願いします!