https://tagayas.connpass.com/event/193881/ 内の 「新卒から見たチーム開発 ~ 未経験者がつまづくポイント ～」 で発表したスライドです

1. 新卒から見たチーム開発
~未経験者が躓くポイント~
株式会社インフィニットループ
大村 良多

2. 2 / 46
自己紹介
チーム開発について
新卒の私が躓いたポイント
・その1 - Git
・その2 - コーディング
もくじ

3. 3 / 46
自己紹介
・大村 良多
・株式会社インフィニットループ
・仙台高専機械科 → ２０２０年４月入社

4. 4 / 46
ILに入社したての頃……

5. 5 / 46
チーム開発？そんなに個人開発と違いなさそう……
Git？ 個人で使ったことあるし、だいじょうぶ……

6. 6 / 46
全然大丈夫じゃなかった

7. 7 / 46
慣れないチーム開発で苦戦する日々

8. 8 / 46
じゃあ個人開発とチーム開発って何が違うの？
……と少し考えてみる

9. 9 / 46
個人開発とチーム開発の違い
個人
・コードを読むのは自分だけ
・自分で仕様を決める
・コミュニケーションが不要
チーム
・ほかの人もコードを読む
・チームの仕様に基づく
・コミュニケーションが必要

10. 10 / 46
たくさん違いがあるので、
自分が躓いたところをピックアップして２つ紹介
これから新卒教育をする方、
エンジニアを目指す方の参考にしてほしい

11. 11 / 46
躓いたところ
その１ Gitの使い方

12. 12 / 46
・作業履歴が残るバージョン管理ツール
・個々人のローカルリポジトリで同時並行で作業ができる
・GitHub等のサービスを活用して作業をとりまとめることができる
・エンジニア界隈で広く使われている
躓いたところ その1 - Gitの使い方
Gitとは

13. 13 / 46
・masterブランチで一本進行
・コミットはセーブポイントくらいの認識
・当然コンフリクトも起こらない
入社する前のGitの使い方
躓いたところ その1 - Gitの使い方

14. 14 / 46
その結果、いくつかの点で躓いてしまった

15. 15 / 46
・何の操作をしているか分からなくなる
・コンフリクト解消に手間取る
・コミットを適当に積んでしまう

16. 16 / 46
Gitで躓いたところ - その１
何の操作をしているのか分からなくなる

17. 17 / 46
「あれ、今どこのブランチいるんだっけ？」
「マージしようとしたら変な差分が出てるけど、どこから切ったっけ？」
という事態が発生した
複数ブランチで進行するようになった
Git - 何の操作をしているかわからなくなる

18. 18 / 46
解決の方策
図を使って整理することが大切
→ブランチがどこから切られたものか、どこにマージするかをイメージする
→どのような操作をしたいかを
図にしてイメージする
here…...
Git - 何の操作をしているかわからなくなる

19. 19 / 46
Gitで躓いたところ - その２
コンフリクト解消に手間取る

20. 20 / 46
そもそもコンフリクト解消の経験値が無い
とはいえチーム開発していると、いろいろな場面でコンフリクトする
解消作業の経験が少ないので、どうやって解決すれば良いかわからない
（rebase? merge? フォースプッシュ？とは状態）
Gitこわれました！（こわれてない）
Git - コンフリクト解消に手間取る

21. 21 / 46
解決の方策
まずは相談
・分からないものは分からないので、周りの人に相談してみる
一人で悩まずとも、他の人に教えてもらえばすぐに解決するパターンが多い
経験を積んでいけば、自ずと解決できるようになる
Git - コンフリクト解消に手間取る

22. 22 / 46
Gitで躓いたところ その３
コミットを適当に積んでいた

23. 23 / 46
こういうコミットを積みがち
Git - コミットを適当に積んでいた
コミットメッセージが抽象的
コミット内での変更が大きすぎ

24. 24 / 46
何が悪いのか？
何を変更したのか、具体的な内容が分からない
他の人がレビューする際の妨げとなる
一つのコミットに変更が多すぎる
バグのあるコード、不要な機能などが入っていた場合に
大規模な手戻りが発生する可能性
Git - コミットを適当に積んでいた

25. 25 / 46
コミットは粒度を適切に保つことが大切
・コミットメッセージが具体的だと、自分も他の人も幸せ
・粒度が適切であれば、バグの特定等も容易に
Git - コミットを適当に積んでいた
・コミットメッセージの形式を統一する
・きちんと機能単位でコミットを積む

26. 26 / 46
Gitまとめ
初心者は……
・混乱してきたら、図にして整理
・調べても分からないことは、操作する前に相談
・他の人のことを考えてコミットを積もう
教える側は……
・フォーマットなどを明文化しておく
・相談しやすい雰囲気づくり

27. 27 / 46
躓いたところ
その2 コードの書き方

28. 28 / 46
個人の頃は……
・可読性を意識せずに書いていた
・インデントも適当
・書き方に統一性がない
・コメントが無い
とりあえずで実装していくことが開発速度につながっていた
躓いたところ その2 - コードの書き方

29. 29 / 46
しかしチーム開発では……
・既存のコードを読んだ上で実装していく
・保守にかかるコストを抑えることが大事
読みやすいコードは全体の開発スピードをあげる
ことを知った
躓いたところ その2 - コードの書き方

30. 30 / 46
可読性を良いコードを書くため
どのようなところを意識するようになったか

31. 31 / 46
・命名規則
・書き方の統一性
・コメント

32. 32 / 46
コードの書き方で意識しているところ その1
命名規則

33. 33 / 46
個人で開発していた頃は……
・関数名、変数名を場当たり的につけていた
(array_a , array_bなど)
コードの書き方 - 命名規則
チーム開発で適当に命名していると……
・コードを読むときの妨げになる
・追加実装しづらくなる

34. 34 / 46
・命名は具体的に。機能に即した命名を意識する
→何をする関数か、どんな値を持つ変数か、立ち止まって考えてみる
・コード規約がはっきりしているとやりやすい
→例)DBから特定のテーブルの情報を取得する関数があったとして……
全件取得ならgetAll~、それ以外はget~とする、など
コードの書き方 - 命名規則

35. 35 / 46
コードの書き方 - 命名規則

36. 36 / 46
コードの書き方で意識しているところ その2
書き方の統一性

37. 37 / 46
同じ処理でも複数の書き方ができる場面はよくある
コードの書き方 - 統一性

38. 38 / 46
同じ処理をしているように見えるけど、
違う書き方をしているということは意味がある？
と、コードを読む側は思えてしまう
コードの書き方 - 統一性

39. 39 / 46
書き方はできるだけ統一する
・効率よくコードが読める
・レビューで指摘される箇所、やりとりも減る
コードの書き方 - 統一性

40. 40 / 46
コードの書き方で意識しているところ その3
コメント

41. 41 / 46
可読性を上げるためには、コメントで補足することが一番簡単
コードの書き方 - コメント
しかし、闇雲に書いていても見づらいコードになってしまう

42. 42 / 46
必ずコメントを入れる、というポイントを決めておく
コードの書き方 - コメント
・関数やクラスを作ったら、
引数・戻り値の、型や論理名をコメントで補足する
処理内容や結果として期待することを書く
・複雑な処理には、
一連の処理でしたいこと、
その結果として期待していることを残しておく

43. 43 / 46
コードの書き方 - コメント

44. 44 / 46
コードの書き方
まとめ
初心者は……
・自分がレビューして読みやすいコードを意識する
・コメントを入れるポイントを決める
・リーダブルコードを読む
教える側は……
・コード規約を整備する
・Gitフックなどで
自動整形が実行される環境を整備しておく

45. 45 / 46
まとめ ~チーム開発で意識していること~
コミュニケーションが大事
５分悩んで分からないことは聞いてみる。
他の人のことを考えてコードを書く
読みやすいコードを書くことは、未来のチーム全体に貢献できる

46. 46 / 46
ご清聴ありがとうございました