Slide 1

Slide 1 text

土鍋のLT

Slide 2

Slide 2 text

自己紹介 • 土鍋です • 最近、組織運営の大変さを痛感してます • あと今週末忙しいなあと • 土曜に地元(さいたま)帰ってガルパンの映画みて庵野秀明展いって合間で 免許試験の勉強と大学の課題(重い)しつつ月曜には免許センターで試験 ゲーミング土鍋

Slide 3

Slide 3 text

チーム開発で気にかけてることはありますか? 個人で開発する文には別にGame.csに全処理書いたって構わない しかしチーム開発だとそうもいかない。 他人はそのコードを理解できるのか? そのコードに機能追加するときは? 汚いコードだと自分にも他人にもメリットがない

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

そこで一年生向けにコードを書く際の 注意点を話していきます 自分も全然できてないんでおこがましいんですがね… まあ意識するようになってくれたらいいなという感じ

Slide 6

Slide 6 text

コードを書く際に意識すること

Slide 7

Slide 7 text

このコードを見て 何を思うでしょうか?

Slide 8

Slide 8 text

MonoBehaviour使いすぎ メンバ変数をpublicにするな 同じ役割の処理はメソッドにまとめろ Update()に向いてない処理 拡張性がまったくない 疎結合にしろ

Slide 9

Slide 9 text

なんでもかんでもpublicにしない 特にメンバ変数はあんまりpublicにしてはいけない。 例えば敵のHPがなにかのミスで攻撃してないのに勝手に減ってしまうか も →privateにしてHPの変更はメソッドで行う。 どうしてもpublicにしてインスペクターから見たいなら 「 [SerializeField] private 」を使おう。

Slide 10

Slide 10 text

Updateは本当に必要なときに使う さっきの例でいうと敵が死んだ際の処理がUpdate内にif文で書かれていた これでは毎フレーム死んだかどうか調べている 敵が死ぬのは少なくともプレイヤーから攻撃を受けた際のみ →攻撃を受けた際の処理メソッドをつくり、 その中に死んだ際の処理追加

Slide 11

Slide 11 text

拡張性を高める&処理を見やすく 敵が死んだ際の処理は一つのメソッドにまとめる。 これによってどこになんの処理があるかが明確化 また、今後死んだ際の処理を追加する際にも書きやすい 例)経験値、アニメーション、エフェクトなどなど

Slide 12

Slide 12 text

これで少しはマシになった やったこと • publicの使用を減らす • Update()をむやみに使わない • 処理をメソッドにまとめる 他にも色々追加した • インスペクターから敵の最大HPを設定できるように • コンストラクタの利用 • summaryタグの使用(どんな処理か記述するコメント) ※これでもよくないところはまだあるかも

Slide 13

Slide 13 text

作品規模が拡大するほど重要になってくる 例えば以下のようなことをしたいとする • エラーを吐いてる場所を特定する • 既存の変数やメソッドを利用して機能拡張したい 大量のコードを見て処理を変更したり追加する必要がある 自分ならまだしも他人がそれを行うとして、読みにくいコードだとどうだろう? あるいはどっか変更したらどっかでエラー発生した!なんてなったら? →きれいにコードを書くことがどれほど重要か

Slide 14

Slide 14 text

コード書くたびにこれらのこと考えて書く? もちろんコード書くときに意識するのは重要だが 事前にやっておくほうがいいよね? そこで!

Slide 15

Slide 15 text

設計のお話

Slide 16

Slide 16 text

事前に設計を行っておくとのちのち苦労しない! チームメンバーそれぞれで自由に書くと、それぞれの書き癖などで理解を妨げる →ある程度、設計を行っておくことで • スムーズな理解 • 作業分担しやすくなる • 機能追加がしやすくなる • もちろんガチガチに固めると大変なのでほどほどに

Slide 17

Slide 17 text

UML(統一モデリング言語) • クラス図 • オブジェクト図 • コンポーネント図 • ユースケース図 • アクティビティ図 • シーケンス図 • パッケージ図 などなど (大学の授業でやるよ)

Slide 18

Slide 18 text

UML 今回はPlantUMLを利用して クラス図をかいてみた。 Vscodeで簡単にかける

Slide 19

Slide 19 text

クラス図 • クラス同士の関係(依存、継承、インターフェイスなど)、メソッドや メンバ変数などを図示 • それぞれのクラスの持つ機能を一目で分かる • 作業分担がしやすい • 仕様の統一が図れる

Slide 20

Slide 20 text

まとめ • 拡張性はあるか • 他の人がこのコードを見たときに一発で理解できるかどうか • 余計な処理をしていないか • 事前に設計しておくとのちのち苦労しない 今回言ってないけど • 疎結合あるか • 再利用性はあるか • 変数名メソッド名クラス名などは何をするのか明確に • SOLID原則 • 継承、インターフェイスも使っていきたい チーム開発や設計は就職してからもすると思うし、覚えておいて損はないはず

Slide 21

Slide 21 text

とりすーぷさんのブログやスライドが めっちゃ参考になる! • 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 今回説明しきれなかったこともたくさんあるのでぜひ読んでみてください

Slide 22

Slide 22 text

リーダブルコード • これは全プログラマーが読むべき • プログラマーの常識がたくさん詰まっている。 • でも一番いい勉強法は実際に開発すること

Slide 23

Slide 23 text

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