チーム開発におけるコードの書き方

私もチーム開発経験を一年弱積んだということで、一年生向けにどのようなことを意識してコードを書くかについてまとめてみました。

Transcript

1. 土鍋のLT
2. 自己紹介 • 土鍋です • 最近、組織運営の大変さを痛感してます • あと今週末忙しいなあと • 土曜に地元（さいたま）帰ってガルパンの映画みて庵野秀明展いって合間で 免許試験の勉強と大学の課題（重い）しつつ月曜には免許センターで試験 ゲーミング土鍋
3. チーム開発で気にかけてることはありますか？ 個人で開発する文には別にGame.csに全処理書いたって構わない しかしチーム開発だとそうもいかない。 他人はそのコードを理解できるのか？ そのコードに機能追加するときは？ 汚いコードだと自分にも他人にもメリットがない
4. チーム開発における コードの書き方
5. そこで一年生向けにコードを書く際の 注意点を話していきます 自分も全然できてないんでおこがましいんですがね… まあ意識するようになってくれたらいいなという感じ
6. コードを書く際に意識すること
7. このコードを見て 何を思うでしょうか？
8. MonoBehaviour使いすぎ メンバ変数をpublicにするな 同じ役割の処理はメソッドにまとめろ Update()に向いてない処理 拡張性がまったくない 疎結合にしろ
9. なんでもかんでもpublicにしない 特にメンバ変数はあんまりpublicにしてはいけない。 例えば敵のHPがなにかのミスで攻撃してないのに勝手に減ってしまうか も →privateにしてHPの変更はメソッドで行う。 どうしてもpublicにしてインスペクターから見たいなら 「 [SerializeField] private 」を使おう。
10. Updateは本当に必要なときに使う さっきの例でいうと敵が死んだ際の処理がUpdate内にif文で書かれていた これでは毎フレーム死んだかどうか調べている 敵が死ぬのは少なくともプレイヤーから攻撃を受けた際のみ →攻撃を受けた際の処理メソッドをつくり、 その中に死んだ際の処理追加
11. 拡張性を高める＆処理を見やすく 敵が死んだ際の処理は一つのメソッドにまとめる。 これによってどこになんの処理があるかが明確化 また、今後死んだ際の処理を追加する際にも書きやすい 例）経験値、アニメーション、エフェクトなどなど
12. これで少しはマシになった やったこと • publicの使用を減らす • Update()をむやみに使わない • 処理をメソッドにまとめる 他にも色々追加した • インスペクターから敵の最大HPを設定できるように • コンストラクタの利用 • summaryタグの使用（どんな処理か記述するコメント） ※これでもよくないところはまだあるかも
13. 作品規模が拡大するほど重要になってくる 例えば以下のようなことをしたいとする • エラーを吐いてる場所を特定する • 既存の変数やメソッドを利用して機能拡張したい 大量のコードを見て処理を変更したり追加する必要がある 自分ならまだしも他人がそれを行うとして、読みにくいコードだとどうだろう？ あるいはどっか変更したらどっかでエラー発生した！なんてなったら？ →きれいにコードを書くことがどれほど重要か
14. コード書くたびにこれらのこと考えて書く？ もちろんコード書くときに意識するのは重要だが 事前にやっておくほうがいいよね？ そこで！
15. 設計のお話
16. 事前に設計を行っておくとのちのち苦労しない！ チームメンバーそれぞれで自由に書くと、それぞれの書き癖などで理解を妨げる →ある程度、設計を行っておくことで • スムーズな理解 • 作業分担しやすくなる • 機能追加がしやすくなる • もちろんガチガチに固めると大変なのでほどほどに
17. UML（統一モデリング言語） • クラス図 • オブジェクト図 • コンポーネント図 • ユースケース図 • アクティビティ図 • シーケンス図 • パッケージ図 などなど （大学の授業でやるよ）
18. UML 今回はPlantUMLを利用して クラス図をかいてみた。 Vscodeで簡単にかける
19. クラス図 • クラス同士の関係（依存、継承、インターフェイスなど）、メソッドや メンバ変数などを図示 • それぞれのクラスの持つ機能を一目で分かる • 作業分担がしやすい • 仕様の統一が図れる
20. まとめ • 拡張性はあるか • 他の人がこのコードを見たときに一発で理解できるかどうか • 余計な処理をしていないか • 事前に設計しておくとのちのち苦労しない 今回言ってないけど • 疎結合あるか • 再利用性はあるか • 変数名メソッド名クラス名などは何をするのか明確に • SOLID原則 • 継承、インターフェイスも使っていきたい チーム開発や設計は就職してからもすると思うし、覚えておいて損はないはず
21. とりすーぷさんのブログやスライドが めっちゃ参考になる！ • Unity開発で使える設計の話＋Zenjectの紹介 https://www.slideshare.net/torisoup/unityzenject • Unityにおける「設計レベル」を定義してみた https://qiita.com/toRisouP/items/79b97c472e588bb91c52 • グローバルゲームジャムでクラス設計をやった話 https://qiita.com/toRisouP/items/824aff814849ae41efe7 • https://qiita.com/toRisouP/items/5b7814fda00cab120e39 • https://qiita.com/toRisouP/items/a868113c99179c585001 • https://qiita.com/toRisouP/items/6fdef63412db97970a11 今回説明しきれなかったこともたくさんあるのでぜひ読んでみてください
22. リーダブルコード • これは全プログラマーが読むべき • プログラマーの常識がたくさん詰まっている。 • でも一番いい勉強法は実際に開発すること
23. ご清聴ありがとうございました