2024 コーディング研修

Aiming 第一事業部における 2024 年度社内研修のうちの、コーディング研修の資料です

Transcript

1. 2024年新⼈研修 コーディング研修 2024年4月25-26日
2. ©2024 Aiming Inc. ガイダンス 講義について 1 • 座学と実習を交互に実施します。 • エンジニア採⽤の⽅、エンジニア以外の職種の⽅が混ざって いますが、同じ内容を⼀緒におこないます。 • ⼀⼈でがんばる研修ではありません。 お互いにサポートしながら進めてください。 • この講義中は、⽣成 AI は使⽤しないでください。 ◦ ChatGPT, Copilot, Claude AI, Perplexity, ⾃分で構築した LLM の使⽤など
3. ©2024 Aiming Inc. ⼀⽇⽬ • ガイダンス • Ruby の基礎 [休憩] • チュートリアル課題 • チュートリアル課題フィードバック [昼休み] • コーディングに必要な知識について [休憩] • 演習課題 I ガイダンス コーディング研修 スケジュール 2 ⼆⽇⽬ • 演習課題 I の ピアレビューとフィードバック [休憩] • 開発プロセスについて アジャイル開発, TDD, リファクタリング [昼休み] • チーム開発 {ペア, モブ}プログラミングについて [休憩] • 演習課題 III [休憩] • 研修講評
4. ©2024 Aiming Inc. ガイダンス ⼀⽇⽬ 3
5. ©2024 Aiming Inc. ガイダンス ガイダンス 4
6. ©2024 Aiming Inc. ガイダンス 講義のねらい 5 コーディングを中⼼として、Aiming の開発プロセスを知る エンジニア職の⽅ • Aiming が採⽤している開発⼿法の採⽤意図を知る • 演習を通じて、なぜこういった⽅針を⼤事にしているのかを 体験から理解する エンジニア以外の職種の⽅ • エンジニア業務への理解を深める • エンジニアの開発⼿法へのこだわりの理由を体験から知る
7. ©2024 Aiming Inc. ガイダンス 次の⽂章を読んで質問に答えてください 6
8. ©2024 Aiming Inc. ある⾝分の低い男が、この男の他には誰もいない、た だ、塗装のはげた⼤きな円柱にキリギリスが⼀匹⽌ まっている広い⾨の下で、ある⽇の⼣暮れ時に⾬が⽌ むのを待っていた。 ガイダンス 7
9. ©2024 Aiming Inc. ガイダンス この場所には何⼈いましたか 8
10. ©2024 Aiming Inc. ガイダンス 時刻はいつですか 9
11. ©2024 Aiming Inc. ガイダンス キリギリスはどこにいたでしょうか 10
12. ©2024 Aiming Inc. ある⾝分の低い男が、この男の他には誰もいない、た だ、塗装のはげた⼤きな円柱にキリギリスが⼀匹⽌ まっている広い⾨の下で、ある⽇の⼣暮れ時に⾬が⽌ むのを待っていた。  ある⽇の暮⽅の事である。⼀⼈の下⼈が、羅⽣⾨の 下で⾬やみを待っていた。  広い⾨の下には、この男のほかに誰もいない。た だ、所々丹塗の剥げた、⼤きな円柱に、蟋蟀が⼀匹と まっている。 https://www.aozora.gr.jp/cards/000879/files/127_15260.html ガイダンス 11
13. ©2024 Aiming Inc. ガイダンス 次のコードを⾒て印象を教えてください 12
14. ©2024 Aiming Inc. user = User.find(current_user_id) cards = user.inventory.items.unreceived.filter {|i| i.send_from == User.find(1234) }.map {|i| i.send_from&.cards }.flatten.select {|c| c.level == 999 }.map {|c| c.name } ガイダンス 13 [質問] どうしたら読みやすくなるでしょうか
15. ©2024 Aiming Inc. class User < ApplicationRecord has_many :items, class_name: 'Item', foreign_key: 'owner_id' def unreceived_items items.unreceived end end class Item < ApplicationRecord belongs_to :owner, class_name: 'User', foreign_key: 'owner_id' has_many :cards belongs_to :send_from, class_name: 'User', optional: true scope :from_sender, ->(sender_id) { where(send_from_id: sender_id) } scope :card_names_by_level, ->(level) { joins(:cards).where(cards: { level: level }).pluck(:name) } end class Card < ApplicationRecord belongs_to :item end ------ user = User.find(777) unreceived_items = user.unreceived_items.from_sender(1234) card_names = unreceived_items.card_names_by_level(999) ガイダンス 14 例えば
16. ©2024 Aiming Inc. class User < ApplicationRecord has_many :items, class_name: 'Item', foreign_key: 'owner_id' def unreceived_items items.unreceived end end class Item < ApplicationRecord belongs_to :owner, class_name: 'User', foreign_key: 'owner_id' has_many :cards belongs_to :send_from, class_name: 'User', optional: true scope :from_sender, ->(sender_id) { where(send_from_id: sender_id) } scope :card_names_by_level, ->(level) { joins(:cards).where(cards: { level: level }).pluck(:name) } end class Card < ApplicationRecord belongs_to :item end ------ user = User.find(777) unreceived_items = user.unreceived_items.from_sender(1234) card_names = unreceived_items.card_names_by_level(999) ガイダンス 15 例えば
17. ©2024 Aiming Inc. ガイダンス 「良いコード」とはなんだと思いますか 16
18. ©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード • メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 17
19. ©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード • メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 18 どれも正解 
20. ©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード • メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 19 どれも正解？ ↓ ⽴場や状況 によって 変化する ?
21. ©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード • メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 20 ← まずはここから
22. ©2024 Aiming Inc. ガイダンス Aiming が⾝を置いている環境 21 • モバイルオンラインゲーム ◦ 競合増加 ◦ ⾼速な開発体制, 安定したサービスの提供, ゲームの⾯⽩さ • 開発規模の⼤きさ ◦ ex) とあるPJの開発規模 ◦ チーム開発, 開発の容易さ • アップデート開発 ◦ ⻑期間にわたって継続した機能追加が続く ◦ 開発の容易さ, 安定したサービスの提供
23. ©2024 Aiming Inc. • モバイルオンラインゲーム ◦ 競合増加 ◦ ⾼速な開発体制, ゲームの⾯⽩さ, 安定したサービスの提供 • 開発規模の⼤きさ ◦ ex) とあるPJの開発規模 ◦ チーム開発, 開発の容易さ • アップデート開発 ◦ ⻑期間にわたって継続した機能追加が続く ◦ 追加開発の容易さ, 安定したサービス提供 ガイダンス Aiming が⾝を置いている環境 22
24. ©2024 Aiming Inc. • チーム開発 ◦ 開発容易性 • 安定性の⾼いサービス提供 ◦ 保守性 • アップデート開発 ◦ 拡張性 ガイダンス Aiming がやりたいこと 23
25. ©2024 Aiming Inc. • チーム開発 ◦ 開発容易性 • 安定性の⾼いサービス提供 ◦ 保守性 • アップデート開発 ◦ 拡張性 ガイダンス Aiming がやりたいこと 24 開発しやすく、保守性が高く、拡張性にも優れた
 開発ができる体制

26. ©2024 Aiming Inc. • ⽬指すところ ◦ Aiming に所属するエンジニアが誰でも理解できる コードを書くこと • なぜなら ◦ チーム開発で、 ◦ バグやエラーが少なく、 ◦ 機能追加が容易な 開発をしたいから ガイダンス Aiming が⽬指すコーディングの指針 25
27. ©2024 Aiming Inc. ガイダンス チーム開発 26
28. ©2024 Aiming Inc. • 組織には様々なキャリアの⼈がいる ◦ OSS コミッター ◦ ベテラン, 中堅 ◦ ウェブ系など他業種からの転職 ◦ 情報系出⾝の新⼈ ◦ ゲーム学校出⾝の新⼈ ◦ グラフィックのスペシャリスト ◦ データベースのスペシャリスト etc. ガイダンス チーム開発におけるコーディング 27
29. ©2024 Aiming Inc. • 組織には様々なキャリアの⼈がいる チーム開発は⼀つの⽬標に向かって助け合いながらゴール に進んでいくもの 「設計は難しくても、コードは書ける」 「コーディングしていない部分でも、レビューで助けることがで きる」 できる役割を少しずつ増やしましょう ガイダンス チーム開発におけるコーディング 28
30. ©2024 Aiming Inc. • リーダーという役割 ◦ リーダーは役職ではなく、チームにおける役割 • （リーダーとは別に）リーダーシップはいたるところにある ◦ ex.) タスクを遂⾏する ▪ 実装して終わりではなく、デザイナー/企画を巻き込ん でゴールに向かう ◦ ex.) PR をマージできるようにする ▪ PR がなかなかマージされない ▪ なぜマージされないのか、問題解決のために⾏動する ガイダンス チーム開発におけるコーディング 29
31. ©2024 Aiming Inc. • チーム開発 • コードレビュー • ペアプログラミング • (OJT) ⾃分の書いたコードはいずれ誰かが⼿を加えるもの。 レビューをする⼈にも（意図的にしなかった⼈にも） そのコードへの責任がある。 ガイダンス チーム開発におけるコーディング 30 コードは個人のものではなく、チームのもの

32. ©2024 Aiming Inc. ガイダンス コードの保守性, サービスの安定性 31
33. ©2024 Aiming Inc. ⼀つのタイトルでの売上はどれくらい？ • 1ヶ⽉あたり • 1⽇あたり • 1時間あたり 社内 KPI ツールで確認してみる ガイダンス コードの保守性, サービスの安定性 32
34. ©2024 Aiming Inc. ガイダンス コードの保守性, サービスの安定性 33 非公開
35. ©2024 Aiming Inc. 臨時メンテナンスが発⽣したら... • 機会損失額 = ダウンタイム × 売上⾒込み/h • メンテナンスコスト = ダウンタイム × チーム⼈数 × ⼈件費/h • 問い合わせ、事後対応コスト ガイダンス コードの保守性, サービスの安定性 34
36. ©2024 Aiming Inc. • ダウンタイム ◦ 売上への機会損失 ◦ ユーザの不満 ▪ ゲーム離れへのリスク ▪ 問い合わせコスト ◦ 不具合発⽣時の補填対応 ▪ 対応コスト ▪ 補填コスト ガイダンス コードの保守性, サービスの安定性 35
37. ©2024 Aiming Inc. なぜダウンタイムが発⽣するか • 定期メンテナンス ◦ システムを停⽌するメンテナンスが不要な設計の検討 ▪ ex.) blue/green deployment • 臨時メンテナンス ◦ バグの少ない開発 ◦ データ設定のミスが発⽣しない内部ツールやデータ管理システム • システム障害 ◦ 冗⻑設計 ◦ 早期の障害検知 ガイダンス コードの保守性, サービスの安定性 36
38. ©2024 Aiming Inc. なぜダウンタイムが発⽣するか • 定期メンテナンス ◦ システムを停⽌するメンテナンスが不要な設計の検討 ▪ ex.) blue/green deployment • 臨時メンテナンス ◦ バグの少ない開発 ◦ データ設定のミスが発⽣しない内部システム • システム障害 ◦ 冗⻑設計 ◦ 早期の障害検知 ガイダンス コードの保守性, サービスの安定性 37
39. ©2024 Aiming Inc. • コードの保守性 ◦ 保守性 (maintainability) ▪ プログラムの継続動作 ▪ プログラムの問題解消への容易さ ガイダンス コードの保守性, サービスの安定性 38
40. ©2024 Aiming Inc. • コードの保守性 ◦ 保守性 (maintainability) ▪ プログラムの継続動作 ▪ プログラムの問題解消への容易さ ガイダンス コードの保守性, サービスの安定性 39 サービス運用後も考慮した
 コーディング（設計）が大事

41. ©2024 Aiming Inc. • コードの保守性 ◦ 保守性 (maintainability) ▪ プログラムの継続動作 ▪ プログラムの問題解消への容易さ ガイダンス コードの保守性, サービスの安定性 40 サービス運用後も考慮した
 コーディング（設計）が大事
 とはいえ、いきなりは難しいので、まずは経験のある人に支えてもらいましょう。
 そのためのチーム開発です。

42. ©2024 Aiming Inc. ガイダンス 追加開発への拡張性 41 開発ロードマップの公開 非公開
43. ©2024 Aiming Inc. オンラインサービスはアップデートが前提 バグの状況もユーザに告知する リリースし、サービスを提供している以上、問題点は明らかにし て改善しなければならない • <告知へのリンク> ガイダンス 追加開発への拡張性 42
44. ©2024 Aiming Inc. • PJ のアップデート計画を決めるためには ◦ 将来（１年後までなど⻑期）のマイルストーン策定 ◦ 仕様の決定タイミング ◦ 協業先との合意タイミング ◦ 開発完了タイミング ◦ QA フェーズの確保 ◦ ストアの審査期間 ◦ メンテナンス⽇の決定 etc… ガイダンス 追加開発への拡張性 43
45. ©2024 Aiming Inc. ガイダンス 追加開発への拡張性 44 非公開 • スケジュール表
46. ©2024 Aiming Inc. • アップデートを⾒越した開発は、実のところ難しい • 継続してサービスしているので状況次第で開発計画も変わり 得る • 経験が必要になる⾯は多分にある ガイダンス 追加開発への拡張性 45
47. ©2024 Aiming Inc. • アップデートを⾒越した開発は、実のところ難しい • 継続してサービスしているので状況次第で開発計画も変わり 得る • 経験が必要になる⾯は多分にある ガイダンス 追加開発への拡張性 46 サービス運用後も考慮した
 コーディング（設計）が大事
 とはいえ、いきなりは難しいので、まずは経験のある人に支えてもらいましょう。
 そのためのチーム開発です。
 再掲

48. ©2024 Aiming Inc. • ⼈⼒で対応可能なことはたくさんある。まずは動くものを。 ただ、 • 積もり積もった⼈⼒対応は、いずれ莫⼤なコスト増になる ◦ ⼈件費 ▪ ⼈員増, 残業, 深夜対応, 休⽇対応... ◦ ⼈的ミスによる損失 ▪ ⼿作業によるミスやチェックもれ, 疲労によるミス ガイダンス コスト意識 47
49. ©2024 Aiming Inc. • ちょっとしたコードで解決することも プログラミングはエンジニアだけのものではない • 例えば、 ◦ Google Apps Script で何か書いてみる ◦ 書籍: 退屈なことはPythonにやらせよう ◦ データ分析の SQL はプランナー、運営職が書くことも多い ◦ ChatGPT, GitHub Copilot ex.) 運営のスタッフがコードを書いている事例 ガイダンス コスト意識 48
50. ©2024 Aiming Inc. • 今後、試験は存在しません ◦ 合格するための学習科⽬などの⽬標はありません ◦ 答えのない問題を解いていくのが業務内容（課題解決） ◦ ⾃分で⾝につける内容を取捨選択する必要がある ◦ 何を学ぶかを選択するのも課題解決能⼒を磨くひとつ • 急ぐ必要はない ◦ ⼀つずつじっくりと ◦ わからなくても時間をおいて何度も咀嚼するのがおすすめ • 開発のすべてをできないと⼀⼈前ではないわけではない ◦ すでに現場では⼀⼈前の社員として扱われます ◦ できることからやっていきましょう ガイダンス 学習について 49
51. ©2024 Aiming Inc. どうやって学習するか • 就業時間内で⼗分学習できる ◦ ⼀⽇ 8 時間、約 200 ⽇分の学びの機会がある ▪ 実装で考える、調査する ▪ コードレビューで知⾒を得る、質問する ▪ チームや社内の⼈に気軽に聞く ▪ 勉強会、輪読会を開催する（就業時間内で実施可能） ▪ 書籍購⼊（申請は上⻑に確認） ガイダンス 学習について 50
52. ©2024 Aiming Inc. ガイダンス ガイダンスのまとめ 51
53. ©2024 Aiming Inc. • 誰でも理解できるようなコーディングができるようになりま しょう • なぜなら ◦ チームで開発するから ◦ コードの保守性を⾼めたいから ◦ 安定したサービス運営をしたいから ガイダンス ガイダンスのまとめ 52
54. ©2024 Aiming Inc. • 誰でも理解できるようなコーディングができるようになりま しょう • そのための武器をこれから⾝につけていきましょう ◦ 読みやすいコードの書き⽅ ◦ ソフトウェア⼯学の基礎知識 ◦ チーム開発 について研修で理解を深めていきます。 ガイダンス ガイダンスのまとめ 53
55. ©2024 Aiming Inc. ガイダンス ガイダンスおわり 54
56. ©2024 Aiming Inc. • 誰でも理解できるようなコーディングができるようになりま しょう • ただし、研修ではすぐに役に⽴つ⼒は⾝につきません ◦ ⾃分で⼿を動かす ◦ ⾃分で考える ◦ なんでもやってみる  ことを継続すること重要です ガイダンス ガイダンスのまとめ 55
57. ©2024 Aiming Inc. Ruby の基礎 Ruby の基礎 56
58. ©2024 Aiming Inc. 研修では Ruby を使います 基礎⽂法を駆け⾜で確認します ※ この講義では Ruby を習得することが⽬的ではありません。 Ruby に関する問題はすぐに質問してください。 周囲の⼈にサポートを求めても構いません。 Ruby の基礎 Ruby の基礎 57
59. ©2024 Aiming Inc. • 動的型付け⾔語 • リファレンスマニュアル ◦ https://docs.ruby-lang.org/ja/ • チュートリアル ◦ https://www.ruby-lang.org/ja/documentation/quickstart Ruby の基礎 Ruby の基礎 58
60. ©2024 Aiming Inc. FizzBuzz を出⼒してみよう FizzBuzz というゲーム プレイヤーは円状に座る。 最初のプレイヤーは「1」と数字を発⾔する。 次のプレイヤーは直前のプレイヤーの次の数字を発⾔していく。 ただし、 3で割り切れる場合は 「Fizz」 5で割り切れる場合は 「Buzz」 両者で割 り切れる場合は 「Fizz Buzz」 を数の代わりに発⾔しなければならない。 発⾔を間違えた者や、ためらった者は脱落となる。 http://ja.wikipedia.org/wiki/Fizz_Buzz Ruby の基礎 課題 59
61. ©2024 Aiming Inc. FizzBuzz を出⼒してみよう 出⼒例 1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz,13,14, FizzBuzz, 16, 17, Fizz, 19, Buzz… • ruby を使⽤すること • 出⼒は改⾏しても（しなくとも）良い • 答えは標準出⼒に出⼒する • 1 から 100 まで出⼒すること（100 より⼤きい数を出⼒で きるようにしても良い） • ruby fizzbuzz.rb で実⾏されること Ruby の基礎 課題 60
62. ©2024 Aiming Inc. • ファイル名: tutorial/<your_name>/fizzbuzz.rb • main ブランチに push せず、トピックブランチを作成し Pull Request を作成してください ◦ ブランチ名: <⾃分のアカウント>/tutorial ▪ ex.) ckazu/tutorial ◦ git 研修を思い出して！ Ruby の基礎 課題 61
63. ©2024 Aiming Inc. Ruby の基礎 提出課題のレビュー 62
64. ©2024 Aiming Inc. お昼休憩 63
65. ©2024 Aiming Inc. ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 64
66. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • オブジェクト指向 ◦ SOLID 原則 ◦ デザインパターン • ソフトウェアアーキテクチャ • テスト技法 • リファクタリング技法 • ⾔語やライブラリのリファレンス ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 65
67. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • オブジェクト指向, SOLID 原則, デザインパターン • ソフトウェアアーキテクチャ • テスト技法 • リファクタリング これらをベーススキルとして、理解し使えるようになっていく。 学校の講義に出てくるだけのものではなく、エンジニアの業務上 で実際に使⽤するスキル。 ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 66
68. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • ⾔語やライブラリのリファレンス これが⼀番の武器 ⾃分が使う技術の仕様（実装）を把握しておく • ex.) ⾔語仕様の理解 ⽂法だけではなく、すべての標準メソッドが把握できてい る、など • ex.) 使⽤ライブラリの実装把握 ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 67
69. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • ⾔語やライブラリのリファレンス • ⼀次ソースに当たる癖をつけるためにも、リファレンスを⾒ に⾏くようにするのが良い • アップデートを追いリリースノートを読む習慣をつけるのも 良い • とりあえずググる、はしばらくやめてみるのがおすすめ ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 68
70. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 2024 年の状況 • Copilot, ChatGPT などの⽣成系 AI は有効活⽤する これまで、レビューや書籍などから得ていた知識を超特急で⾝に つけることができるようになった。 最短で実践で通⽤するコードや知識の習得が可能なのでツールと して有効活⽤する。 ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 69
71. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 2024 年の状況 • Copilot, ChatGPT などの⽣成系 AI は有効活⽤する ただし、セキュリティには⼗分気をつける。 ChatGPT など（に限らず検索やウェブサービスなどでも）に、業 務上の機密情報や特定可能な情報は決して⼊⼒しないこと。 新⼈だから許される、ということはありません。 ex) ChatGPT, Google 検索, DeepL など ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 70
72. ©2024 Aiming Inc. ソフトウェア⼯学の知識 把握しておいてほしいトピック 71 本講義ではトピックを列挙するので、業務を通じて徐々に理解を 深めていってください。
73. ©2024 Aiming Inc. ⼿続き型⾔語 • C, Fortran, Pascal, BASIC, Assembly, Rust … オブジェクト指向プログラミング⾔語 <= ⼿続き的にも記述できる • Java, C++, C#, Ruby, Python, Swift, Objective-C … 論理型⾔語 • Prolog, Datalog, Mercury … 関数型⾔語 • Lisp, OCaml, Haskell, Scala, Elixir, Erlang, Clojure, F# … マルチパラダイム⾔語 • JavaScript, TypeScript, Python, Scala, Kotlin, Rust, Go … ソフトウェア⼯学の知識 プログラミング⾔語の種類 72 太字: 業務で使⽤されることのある⾔語
74. ©2024 Aiming Inc. 現実のものや概念を「オブジェクト」として、プログラミングに 反映させる⽅法論 ソフトウェア⼯学の知識 オブジェクト指向プログラミング 73
75. ©2024 Aiming Inc. • クラス ◦ オブジェクトの設計図のようなもの ◦ 属性 (フィールド) と動作/機能 (メソッド) が定義される • オブジェクト ◦ クラスから⽣成されるインスタンス ▪ ex.)「⾞」という抽象的なクラスから「⾚い⾞」や「スポー ツカー」といった具体的なオブジェクトを⽣成 ◦ 実際のデータ（フィールドの値）と 動作/機能（メソッドの実⾏）をもつ ソフトウェア⼯学の知識 オブジェクト指向プログラミング 74
76. ©2024 Aiming Inc. ３つの特性 • 継承 (inheritance) ◦ クラスの構造化。コードの再利⽤性の向上 • カプセル化 (encapsulation) ◦ 外部からのアクセスを制限。データの安全性の確保 • ポリモーフィズム（多態性: polymorphism） ◦ overload, override により、オブジェクトの型に基づいて 異なる振る舞い（メソッド実⾏）を可能に ソフトウェア⼯学の知識 オブジェクト指向プログラミング 75
77. ©2024 Aiming Inc. オブジェクト指向プログラミングの利点 • 直感的 ◦ 現実を模倣することで、直感的な設計ができる • 再利⽤性 ◦ ⼀度作ったクラスを複数のコードで利⽤できる • 拡張可⽤性 ◦ 追加実装の際、実装量や既存コードの変更を少なくできる ソフトウェア⼯学の知識 オブジェクト指向プログラミング 76
78. ©2024 Aiming Inc. プログラミングにおける⼀般的な問題に対する検証済みの解決策 • 効率的な開発 • コードの再利⽤ • 保守性の向上 ソフトウェア⼯学の知識 デザインパターン 77
79. ©2024 Aiming Inc. Gang of Four (GoF) の 23 パターン • ⽣成に関するパターン ◦ ex. Singleton, Factory Method • 構造に関するパターン ◦ ex. Facade, Proxy • 振る舞いに関するパターン ◦ ex. Observer, Strategy ソフトウェア⼯学の知識 デザインパターン 78 徐々に増やしていけば良い。 PJ やライブラリのコードを読んでいると、パター ンに出くわすことがよくあるので、一度ざっとさ らっておくと良い
80. ©2024 Aiming Inc. • 新しい課題 ◦ クラウドサービス、モバイルアプリケーション、⼤規模 データ処理など、現代に即したパターンも ◦ ゲーム開発 => https://gameprogrammingpatterns.com/ ex.) 依存性の注⼊ (DI: Dependency Injection) ◦ オブジェクトがその他のオブジェクトの 依存関係を⾃動で注⼊する ▪ ref. Spring Framework, Zenject(Extenject) など… ソフトウェア⼯学の知識 デザインパターン 79
81. ©2024 Aiming Inc. • MVC (Model-View-Controller) • MVP (Model-View-Presenter) • MVVM (Model-View-ViewModel) • Flux, Redux... • Layered Architecture, Onion Architecture, Clean Architecture… • Serverless Architecture, Microservices Architecture … etc. ソフトウェア⼯学の知識 ソフトウェアアーキテクチャ 80
82. ©2024 Aiming Inc. • 配属プロジェクトで採⽤されているアーキテクチャは？ ◦ Unity のクライアント ◦ サーバサイド ◦ 開発⽤社内ウェブサービス ソフトウェア⼯学の知識 ソフトウェアアーキテクチャ 81
83. ©2024 Aiming Inc. SOLID 原則 • オブジェクト指向設計のための５つの原則 • 可読性、再利⽤性、拡張性を向上させ、⾼い保守性や変更に 強いシステムを構築する ソフトウェア⼯学の知識 ソフトウェア設計 82
84. ©2024 Aiming Inc. SOLID 原則 • 単⼀責任の原則 (S: Single Responsibility Principle) ◦ あるクラスは⼀つの責任だけを持つべき ▪ ex.) ログ記録とデータ処理を⼀つのクラスで⾏うのではなく、 それぞれの責任を持つクラスを分ける • 開放/閉鎖の原則 (O: Open/Closed Principle) ◦ 拡張に対して開かれ、変更に対して閉じられているべき ▪ ex.) 新しい機能を追加するために既存のコードを変更するので はなく、既存のコードに新しいコードを追加する形で拡張する ▪ 注) 既存コードの実装を変更してはいけない、のではなく、そ ういう⾵に設計しましょうという話 ソフトウェア⼯学の知識 ソフトウェア設計 83
85. ©2024 Aiming Inc. SOLID 原則 • リスコフの置換原則 (L: Liskov Substitution Principle) ◦ サブタイプは、そのスーパータイプと置換可能であるべき ▪ ex.) 「⾶ぶ」メソッドをもつ「⿃」クラスのサブクラスとして 「ペンギン」クラスは適当か？ • 解決策1) 「⾶べる⿃」、「⾶べない⿃」の抽象クラスを使 ⽤ • 解決策2) 「⾶べる」というインタフェースを使⽤ • インターフェース分離の原則 (I: Interface Segregation Principle) ◦ クライアントは不必要なインターフェースに依存すべきではない ▪ ex.) ⼀つの汎⽤インターフェースよりも、特定のクライアント に必要なメソッドのみを提供する複数の特化したインター フェースを⽤意する ソフトウェア⼯学の知識 ソフトウェア設計 84
86. ©2024 Aiming Inc. SOLID 原則 • 依存性逆転の原則 (D: Dependency Inversion Principle) ◦ ⾼レベルのモジュールは低レベルのモジュールに依存すべきではな い。両者は抽象に依存すべき。 ▪ ⾼レベル: ビジネスルールを定義するモジュールなど ▪ 低レベル: データアクセスや、ユーティリティなど、具体的な実 装を提供するモジュール ソフトウェア⼯学の知識 ソフトウェア設計 85
87. ©2024 Aiming Inc. SOLID 原則 • 依存性逆転の原則 (D: Dependency Inversion Principle) ◦ ItemManager が具体的なアイテム取得処理に依存している ソフトウェア⼯学の知識 ソフトウェア設計 86 class ItemManager { public Item GetItemFromShop(int itemId) { // ショップからアイテムを取得するロジック } public Item GetItemFromDrop(int enemyId) { // 敵からアイテムをドロップするロジック } public Item GetItemFromQuestReward(int questId) { // クエスト報酬としてアイテムを取得するロジック } }
88. ©2024 Aiming Inc. SOLID 原則 • 依存性逆転の原則 (D: Dependency Inversion Principle) ◦ ItemManager は ItemSource というインタフェースに依存 ソフトウェア⼯学の知識 ソフトウェア設計 87 interface IItemSource { Item GetItem(int id); } class Shop : IItemSource { public Item GetItem(int itemId) { // ショップからアイテムを取得するロジック } } class EnemyDrop : IItemSource { public Item GetItem(int enemyId) { // 敵からアイテムをドロップするロジック } } class QuestReward : IItemSource { public Item GetItem(int questId) { // クエスト報酬としてアイテムを取得するロジック } } class ItemManager { private IItemSource itemSource; public ItemManager(IItemSource source) { this.itemSource = source; } public Item GetItem(int id) { return itemSource.GetItem(id); } }
89. ©2024 Aiming Inc. SOLID 原則 • 依存性逆転の原則 (D: Dependency Inversion Principle) ◦ ItemManager は ItemSource というインタフェースに依存 ソフトウェア⼯学の知識 ソフトウェア設計 88 interface IItemSource { Item GetItem(int id); } class Shop : IItemSource { public Item GetItem(int itemId) { // ショップからアイテムを取得するロジック } } class EnemyDrop : IItemSource { public Item GetItem(int enemyId) { // 敵からアイテムをドロップするロジック } } class QuestReward : IItemSource { public Item GetItem(int questId) { // クエスト報酬としてアイテムを取得するロジック } } class ItemManager { private IItemSource itemSource; public ItemManager(IItemSource source) { this.itemSource = source; } public Item GetItem(int id) { return itemSource.GetItem(id); } } • 柔軟性と拡張性の向上 ◦ 新しいアイテムソースを追加する場合、新たな IItemSource の実装を システムに追加するだけで、ItemManager の他の部分は変更不要 • 再利⽤性とテスト容易性の向上 ◦ IItemSource をモックに置き換えることで、統合テストやユニットテ ストが簡単になります。
90. ©2024 Aiming Inc. ドメイン駆動設計 (DDD: Domain-Driven Design) • 現実の問題領域（ドメイン）を中⼼に、設計/開発を進めるアプロー チ ◦ 開発者はビジネスへの深い理解を元に現実世界の問題をモデリ ングする（ドメインモデル） ◦ 開発者と ビジネスのステークホルダーが協⼒ ソフトウェア⼯学の知識 ソフトウェア設計 89
91. ©2024 Aiming Inc. ドメイン駆動設計のコンセプト • エンティティ (Entity) ⼀意の識別⼦を持つ、変化するドメインオブジェクト • 値オブジェクト (Value Object) 識別⼦を持たず、属性のみで定義される不変のオブジェクト • 集約 (Aggregate) ⼀つのエンティティを主とし、関連オブジェクトを⼀つの単位として扱う • リポジトリ (Repository) 集約の永続化と再構築を管理する • ドメインサービス (Domain Service) エンティティや値オブジェクトを超えるドメインロジックを提供 • ユビキタス⾔語 (Ubiquitous Language) 開発チームとステークホルダーが共有するプロジェクト固有の⾔語 ソフトウェア⼯学の知識 ソフトウェア設計 90
92. ©2024 Aiming Inc. • DRY (Don't Repeat Yourself.) • KISS (Keep it Simple, stupid.) • YAGNI (You Ain't Gonna Need It.) • 驚き最⼩の原則 • 確証性バイアス • 銀の弾丸 • 計測せよ • コードの臭い • ⾞輪の再発明 ソフトウェア⼯学の知識 過去の⼈類の知⾒を知る ソフトウェア開発の原理原則/ベストプラクティス/アンチパターン 91 • 正常性バイアス • ドッグフーディング • 早すぎる最適化 • プログラマの三⼤美徳 • マジックナンバー • ヤクの⽑刈り • ラバーダッキング • 割れ窓理論 … １年後, ２年後くらいに改めて読んでみると腹落ちするかも
93. ©2024 Aiming Inc. ソフトウェア⼯学の知識 過去の⼈類の知⾒を知る 92
94. ©2024 Aiming Inc. 実習1 実習１ 93
95. ©2024 Aiming Inc. https://github.com/foo/bar/baz/exam1 にあるファイルを修正し、次ページの要件を満たしてください • 最初に exam1 フォルダに⾃分のアカウント名のフォルダを作 成し、雛形のファイルをコピーしてください • 成果物は GitHub のリポジトリに push してください • main ブランチに push せず、トピックブランチを作成し Pull Request を作成してください ◦ ブランチ名: <⾃分のアカウント>/exam1 ▪ ex.) ckazu/exam1 実習1 実習１ 94
96. ©2024 Aiming Inc. 雛形コードの解説 実習1 実習１ 95
97. ©2024 Aiming Inc. 1. レアリティ UR を追加してください 2. 10 回連続ガチャを定義してください 3. ガチャはレアリティごとに異なった確率で抽選されるように してください C: 60%, UC: 30%, R: 7%, SR: 2%, UR: 1% 15:50 開始 実習1 実習１ 96 注:
 • git や Ruby の質問は随時してください
 • コミットの粒度もきちんと考えること

98. ©2024 Aiming Inc. 1. レアリティ UR を追加してください 2. 10 回連続ガチャを定義してください 3. ガチャはレアリティごとに異なった確率で抽選されるように してください C: 60%, UC: 30%, R: 7%, SR: 2%, UR: 1% 4. 10 回連続ガチャの 10 回⽬は必ず SR以上(SR: UR = 2: 1 の確 率) が抽選されるようにしてください 5. UR だけは特別な名前 [UR] XXXXXXXX を表⽰するようにしてく ださい 実習1 実習１ 97
99. ©2024 Aiming Inc. 発展課題 1. 今のままでは、各レアリティで1種類のカードしか扱えませ ん。複数のカードを扱えるように拡張してください。 2. （ここまでで実装していない場合）外部から設定データを読 み込む機構を実装してください。 実習1 実習１ 98
100. ©2024 Aiming Inc. 発展課題２ 1. 抽選確率が設定通りであろうことを検証する、確率集計ツー ルを作ってください。 ex.) 数万回試⾏した結果を集計して、設定確率との差異を表⽰ するなど。 ただし、本体のコードには⼿を⼊れず、新たにクラス実装を してください。 実習1 実習１ 99
101. ©2024 Aiming Inc. 開発プロセスについて ⼆⽇⽬ 100
102. ©2024 Aiming Inc. • 他のメンバーの PR にレビューコメントを書いてください 各メンバーのコード、最低⼀箇所にコメントを残すこと ◦ 明らかな間違いの指摘 ▪ バグ、仕様との差異など ◦ 別案の提案 ▪ 効率性、可読性などの観点から ◦ ⾃分が知らなかったところ ◦ 良いと思ったところ ◦ 質問 など 実習1 実習１のピアレビュー/講評 101
103. ©2024 Aiming Inc. 開発プロセスについて 開発プロセスについて 102
104. ©2024 Aiming Inc. 仕様をそのまま実装することが、⾯⽩いゲーム（良いサービス） を作ることにつながるだろうか 開発プロセスについて ゲーム開発 103
105. ©2024 Aiming Inc. 仕様をそのまま実装することが、⾯⽩いゲーム（良いサービス） を作ることにつながるだろうか • 新しいゲーム要素を追加することで、全体の⾯⽩さが変化 • Try & Error が重要 ◦ 作っては評価して変更していくことの繰り返し ◦ 作った機能を作り直すことも厭わない ◦ そのサイクルを何度も回していくことで、ゴールに近づ いていく 開発プロセスについて ゲーム開発 104
106. ©2024 Aiming Inc. 1999 Extreme Programming (Kent Beck) • 従来の開発⼿法へのアンチテーゼ • アジャイル開発⼿法の先駆け • XP におけるプラクティス • 共同: イテレーション、共通⾔語、共同作業、振り返り • 開発: TDD（テスト駆動開発: Test driven development ）, ペア プロ, リファクタ, YAGNI, CI(continuous integration), コードの 共同化 • 管理者: 責任, 援護... • 顧客: ストーリー作成, 短期リリース... 開発プロセスについて XP 105
107. ©2024 Aiming Inc. agile: 俊敏な、機敏な • 短い開発プロセスと顧客からのフィードバックの繰り返しに より、顧客の⽬的を達成 • 主なフレームワーク ◦ スクラム, カンバン, XP など • 注: これさえやっておけば良いという開発⼿法ではない 柔軟な対応をすることが重要 PJ やチームメンバー、開発フェーズに合わせたやり⽅を模索 し、改善することが必要 開発プロセスについて アジャイル開発 106
108. ©2024 Aiming Inc. アジャイルマニフェスト https://agilemanifesto.org/iso/ja/manifesto.html 開発プロセスについて アジャイル開発 107
109. ©2024 Aiming Inc. スクラム • プロダクトオーナー ◦ PJ のビジョン要件定義、優先順位の決定 • スクラムマスター ◦ チームがスクラムのプロセスにしたがって作業できる よう⽀援する • チーム ◦ 実際に開発を⾏う、⾃⼰管理型のチーム 開発プロセスについて アジャイル開発 108
110. ©2024 Aiming Inc. スクラムにおけるイベント • スプリント（イテレーション） ◦ 開発期間の単位 • デイリースクラム（スタンドアップミーティング） ◦ ⽇々の進捗の共有 • スプリントレビュー ◦ スプリントの最後に⾏う製品デモ フィードバックを得る • レトロスペクティブ ◦ 振り返り。改善点は次のスプリントに反映させる 開発プロセスについて アジャイル開発 109
111. ©2024 Aiming Inc. • イテレーションを回すことの重要性 ◦ フィードバックの収集 ◦ リスクの低減 ◦ 進⾏状況の明確化 ◦ モチベーション向上 • 不確実性コーン ◦ PJ 開始時には⾼い不確実性が、時間の経過とともに減 少していく ◦ 初期段階では未知な部分がとても⼤きい 開発プロセスについて アジャイル開発 110 小さなサイクルを回していくことでリスクを低減
112. ©2024 Aiming Inc. 開発プロセスについて アジャイル開発 111
113. ©2024 Aiming Inc. TDD: Test-Driven Development テストファースト • まず最初にテストコードを書く（注: 網羅しないこと） ◦ テストを失敗させる (red) • テストを通る実装を最速で⾏う (green) • テストが成功する状態を保ちながら、リファクタリン グを⾏う 開発プロセスについて テスト駆動開発 112
114. ©2024 Aiming Inc. 最初にテストコードを書くことの利点 • テストコードは仕様である リファクタリングをすることの利点 • 「きれいな」コードにする テストコードがあることの利点 • リファクタリングが容易である • 保守性が確保できる 開発プロセスについて テスト駆動開発 113
115. ©2024 Aiming Inc. BDD: Behavior Driven Development 振る舞い駆動開発 システムの振る舞いをテストコードで記述する • TDD: 単体テスト • 仕様のテスト • BDD: 結合（受け⼊れ）テスト • 要件やユースケースに近い部分のテスト 開発プロセスについて テスト駆動開発 114
116. ©2024 Aiming Inc. 「TDD と⻩⾦の回転」 https://speakerdeck.com/twada/tdd-live-in-50-minutes 開発プロセスについて テスト駆動開発 115
117. ©2024 Aiming Inc. • 端的に⾔えば、コードや設計をきれいにする • 機能やインタフェースを変更せずに、内部実装を改善する 開発プロセスについて リファクタリング 116
118. ©2024 Aiming Inc. なぜやるか • 保守性や拡張性の担保が⽬的 開発プロセスについて リファクタリング 117
119. ©2024 Aiming Inc. いつやるか • 毎実装ごとにやる TDD の⽂脈で⾔えば、 毎回の実装の最初と最後にリファクタリングのフェーズがある 開発プロセスについて リファクタリング 118
120. ©2024 Aiming Inc. いつやるか • 毎実装ごとにやる TDD の⽂脈で⾔えば、 毎回の実装の最初と最後にリファクタリングのフェーズがある 機能追加の実装作業であれば、最初にリファクタリングを⾏うの を勧めます 開発プロセスについて リファクタリング 119
121. ©2024 Aiming Inc. いつやるか • 毎実装ごとにやる 機能追加のフェーズであれば、最初にリファクタリングを⾏う • コードに⼿を⼊れる前に⼿を⼊れやすくしておく • テストがなければ（不⼗分であれば）追加する => 実装から時間が経っていると、状況が変化している事が多い 開発プロセスについて リファクタリング 120
122. ©2024 Aiming Inc. • メソッドの抽出/クラスの分割 • マジックナンバーの除去 • 配列やハッシュから、オブジェクトへの変更 • ポリモーフィズムの導⼊ • State/Strategy パターンへの変更 • 条件式のメソッド化 • 深いネストの解消 • フラグ処理の除去 など... 「何となくこっちが良さそう」、 ではなく、根拠を持ったリファクタリングを 開発プロセスについて リファクタリングの⼿法 121
123. ©2024 Aiming Inc. Q. テストを書いたり、リファクタリングをしたりしていたら、開 発スピードは落ちないのか？ A. 落ちない 最初は時間がかかる⾯は確かにある（慣れていない、チームのの コミュニケーション不⾜、ドメイン知識の不⾜など）。 ただ、継続した開発を続ければ続けるほど効いてくる。 逆に、テストコードがなかったり、まずい設計を残してしまう と、後でつけを払うことになる（技術的負債） 開発プロセスについて 疑問: 開発スピードへの危惧 122
124. ©2024 Aiming Inc. • ゲーム開発 ◦ ⾯⽩くするために、常にコードは変更される ◦ 短いサイクルで改善 ◦ アジャイル開発の⼿法を取り⼊れる • コーディングにおけるトピック ◦ テスト⼤事 ◦ リファクタリング⼤事 ◦ どちらも、保守性、拡張性を担保するためのもの 開発プロセスについて まとめ 123
125. ©2024 Aiming Inc. 開発プロセスについて 演習2 124
126. ©2024 Aiming Inc. FizzBuzz を TDD で実装してみましょう テストフレームワーク https://github.com/seattlerb/minitest 開発プロセスについて 演習2: introduction 125
127. ©2024 Aiming Inc. • 1 台の PC • 1 台の⼤きなディスプレイ • 1 種類の⼊⼒デバイス を使い、 • 2 ⼈の⼈間が 実装作業をおこなう ペアプログラミング ペアプログラミング 126
128. ©2024 Aiming Inc. • ⼀⼈がドライバー • もう⼀⼈がナビゲーター として、作業する お互い、考えていることを⼝に出しながら作業する。 意思疎通がなされて、作業の共通認識ができていること。 ペアプログラミング ペアプログラミング 127
129. ©2024 Aiming Inc. ドライバー • キーボードを触り、コーディングを進める係。 • これからやろうとしていることは逐⼀⼝に出して共有する。 • 勝⼿に実装しない。⽅向性はナビゲーターに委ねる。 ナビゲーター • ドライバーは⽬の前のタイピングに意識を取られがちになる • 広い視野を持ち先読みをしてドライバーをナビゲートする • タイプミスなども指摘し無駄なはまり⽅をしないよう助ける ペアプログラミング ペアプログラミング 128
130. ©2024 Aiming Inc. • ドライバーとナビゲーターは 10-15 分単位を⽬処に交代する • 想像以上に負荷が⾼いので、適度に休憩を挟むこと • チームにおいては、ドライバーとナビゲーターのペアは、⼀ ⽇ごとに変更する、などの⽅策を取るのが良い ペアプログラミング ペアプログラミング 129
131. ©2024 Aiming Inc. • 実装時間の短縮 • 品質の向上 • スキル、知識の共有 • 教育 • チームワークの向上 • コードの共有意識 ... ペアプログラミング ペアプログラミングの効果 130
132. ©2024 Aiming Inc. • 必ずしも全員がペア作業を好むわけではない • 性格上、ペア作業に向かない⼈もいる • 共同作業をするための理解を得るのが難しいケースがある ペアプログラミング ペアプログラミングの弱点 131
133. ©2024 Aiming Inc. 組み合わせが効果的になる例 • 専⾨家 x 専⾨家 ◦ もっとも複雑な作業を成功させる • 専⾨家 x ⼀般的なエンジニア ◦ ⼀般的なエンジニアのスキルアップ • 専⾨家 x 新⼈ ◦ トレーニング。⽐較的容易な課題の達成 • 新⼈ x 新⼈ ◦ 単純なタスクによって、双⽅のエンジニアが経験を積む ペアプログラミング ペアリング 132
134. ©2024 Aiming Inc. • ペアプログラミング => 2 ⼈ • モブプログラミング => 3 ⼈以上 1 ⼈がドライバー（タイピスト） それ以外がナビゲーター（その他のモブ） モブプログラミング モブプログラミング 133
135. ©2024 Aiming Inc. • ドライバーは 10-15 分単位で、他のナビゲーターと順に交代 していく • ペアプロよりも、よりやろうとしていることを共有していか なければうまくいかない ホワイトボードなどを活⽤する • ⼈数が多いので横道にそれすぎないよう注意する ファシリテーターが別にいると良いケースも • 否定的なことは⾔わない モブプログラミング モブプログラミング 134
136. ©2024 Aiming Inc. • 期待する効果はペアプロと同様 ◦ 品質の向上 ◦ 知識の共有 ▪ など • プログラミングだけではない場⾯にも ◦ コードのペアレビュー、モブレビュー ◦ 仕様の確認 ◦ エンジニア以外のチームでも ◦ … モブプログラミング モブプログラミング 135 その時のチームに合わせたやり方を模索しましょう

137. ©2024 Aiming Inc. 開発プロセスについて 演習3 136
138. ©2024 Aiming Inc. モブプログラミングで課題を実装してください • ドライバーの順番は今ここで抽選します • この演習でのルール ◦ 15 分経過したら、速やかにドライバーを交代してください ◦ 作業途中であってもその時点の状態をコミットすることと します ◦ 切りの良いタイミングでのコミットもおこなってください 開発プロセスについて 演習3 137
139. ©2024 Aiming Inc. • ドライバー ◦ 操作しようとしていること、悩んでいることを常に発話し てください ◦ ⾃分の考えで実装を進めてはいけません • ナビゲーター ◦ ドライバー以外は全員ナビゲーターです ◦ 気がついたことを積極的に発⾔してください ◦ ナビゲーターの道標がないとドライバーは作業できません • ホワイトボードも活⽤しましょう 開発プロセスについて 演習3 138
140. ©2024 Aiming Inc. • ナビゲーターが個⼈の PC やスマホで勝⼿に調べないこと ◦ PC を操作できるのはドライバーだけです ◦ 調査したいことがあれば、指⽰をして全員で共有している 状態で調査します • この演習では⼿分けして作業するという⾏為は禁⽌します ※ 演習の⽬的は、より良い実装をすることよりも、チーム開発の 実感を得ることです。 相談しながら協⼒してチームで作業を進め、課題を解決してくだ さい。 開発プロセスについて 演習3 139
141. ©2024 Aiming Inc. • 最初に 15 分間、課題について実装の進め⽅や設計⽅針などを 相談する時間を設けます。 • 15 分間 x n ⼈ x 2 回 = h 時間で実装してください • タイムキーパーは講師が担当します • 随時休憩をはさみます • git を活⽤して、適宜 commit などしてください 開発プロセスについて 演習3 140
142. ©2024 Aiming Inc. /exam3/master_data にガチャの抽選テーブルのデータが格納さ れています。 このデータをもとに、いくつかの種類のガチャを実装してくださ い。 演習２の実装は⼀旦忘れて、今回の仕様に合わせたより良い設計 を検討してください。 開発プロセスについて 演習3: 課題 141
143. ©2024 Aiming Inc. • プレミアムガチャを実装してください ◦ 排出物の情報は確率以外すべて出⼒すること • ノーマルガチャを実装してください • ドラゴン種族の排出確率が2倍になるドラゴンガチャを実装してく ださい。ノーマルガチャのテーブルをベースとします • 特定のキャラクターの排出確率が10倍になるピックアップガチャを 実装してください。ノーマルガチャのテーブルをベースとします ▪ ピックアップ: xxx, xxx, xxx 開発プロセスについて 演習3: 課題-1 142
144. ©2024 Aiming Inc. • すべてのガチャで回数を指定して実⾏（最⼤10回）できるように してください 1-10 回以外はエラーとし、実⾏できないようにしてください • プレミアムガチャの10回連続実⾏では、最後の⼀回では SR, UR が必ず排出されるようにしてください 確率はプレミアムガチャに準じます ※ プレミアムドラゴンガチャは対象外です 開発プロセスについて 演習3: 課題-2 143
145. ©2024 Aiming Inc. • 排出されたログをファイルに記録してください ◦ ⽇時 ◦ ガチャ種別 ◦ 排出物 ◦ （連続実⾏の場合）排出順 開発プロセスについて 演習3: 課題-3 144
146. ©2024 Aiming Inc. • ボックスガチャを実装してください ◦ ボックスガチャの排出状況は内部メモリで管理せず、外部に永 続化して管理すること 開発プロセスについて 演習3: 発展課題 145
147. ©2024 Aiming Inc. • （テストコードが存在しない場合）テストコードを追加してくだ さい • 全ての要件を踏まえて、現在の実装のコード設計を議論してくだ さい ◦ 議論を元にコード設計を再度おこなって、リファクタリング に取り組んでください 開発プロセスについて 演習3: 発展課題 146
148. ©2024 Aiming Inc. 参考⽂献 147
149. ©2024 Aiming Inc. コーディング研修 完 148