2024 コーディング研修

by ckazu

Slide 1

Slide 1 text

2024年新⼈研修コーディング研修 2024年4月25-26日

Slide 2

Slide 2 text

©2024 Aiming Inc. ガイダンス講義について 1 ● 座学と実習を交互に実施します。 ● エンジニア採⽤の⽅、エンジニア以外の職種の⽅が混ざっていますが、同じ内容を⼀緒におこないます。 ● ⼀⼈でがんばる研修ではありません。お互いにサポートしながら進めてください。 ● この講義中は、⽣成 AI は使⽤しないでください。 ○ ChatGPT, Copilot, Claude AI, Perplexity, ⾃分で構築した LLM の使⽤など

Slide 3

Slide 3 text

©2024 Aiming Inc. ⼀⽇⽬ ● ガイダンス ● Ruby の基礎 [休憩] ● チュートリアル課題 ● チュートリアル課題フィードバック [昼休み] ● コーディングに必要な知識について [休憩] ● 演習課題 I ガイダンスコーディング研修スケジュール 2 ⼆⽇⽬ ● 演習課題 I のピアレビューとフィードバック [休憩] ● 開発プロセスについてアジャイル開発, TDD, リファクタリング [昼休み] ● チーム開発 {ペア, モブ}プログラミングについて [休憩] ● 演習課題 III [休憩] ● 研修講評

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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

©2024 Aiming Inc. ある⾝分の低い男が、この男の他には誰もいない、ただ、塗装のはげた⼤きな円柱にキリギリスが⼀匹⽌まっている広い⾨の下で、ある⽇の⼣暮れ時に⾬が⽌むのを待っていた。ある⽇の暮⽅の事である。⼀⼈の下⼈が、羅⽣⾨の下で⾬やみを待っていた。広い⾨の下には、この男のほかに誰もいない。ただ、所々丹塗の剥げた、⼤きな円柱に、蟋蟀が⼀匹とまっている。 https://www.aozora.gr.jp/cards/000879/ﬁles/127_15260.html ガイダンス 11

Slide 13

Slide 13 text

Slide 14

Slide 14 text

©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 [質問] どうしたら読みやすくなるでしょうか

Slide 15

Slide 15 text

©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 例えば

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

©2024 Aiming Inc. ● リーダーという役割 ○ リーダーは役職ではなく、チームにおける役割 ● （リーダーとは別に）リーダーシップはいたるところにある ○ ex.) タスクを遂⾏する ■ 実装して終わりではなく、デザイナー/企画を巻き込んでゴールに向かう ○ ex.) PR をマージできるようにする ■ PR がなかなかマージされない ■ なぜマージされないのか、問題解決のために⾏動するガイダンスチーム開発におけるコーディング 29

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

©2024 Aiming Inc. なぜダウンタイムが発⽣するか ● 定期メンテナンス ○ システムを停⽌するメンテナンスが不要な設計の検討 ■ ex.) blue/green deployment ● 臨時メンテナンス ○ バグの少ない開発 ○ データ設定のミスが発⽣しない内部ツールやデータ管理システム ● システム障害 ○ 冗⻑設計 ○ 早期の障害検知ガイダンスコードの保守性, サービスの安定性 36

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

©2024 Aiming Inc. ● ちょっとしたコードで解決することもプログラミングはエンジニアだけのものではない ● 例えば、 ○ Google Apps Script で何か書いてみる ○ 書籍: 退屈なことはPythonにやらせよう ○ データ分析の SQL はプランナー、運営職が書くことも多い ○ ChatGPT, GitHub Copilot ex.) 運営のスタッフがコードを書いている事例ガイダンスコスト意識 48

Slide 50

Slide 50 text

©2024 Aiming Inc. ● 今後、試験は存在しません ○ 合格するための学習科⽬などの⽬標はありません ○ 答えのない問題を解いていくのが業務内容（課題解決） ○ ⾃分で⾝につける内容を取捨選択する必要がある ○ 何を学ぶかを選択するのも課題解決能⼒を磨くひとつ ● 急ぐ必要はない ○ ⼀つずつじっくりと ○ わからなくても時間をおいて何度も咀嚼するのがおすすめ ● 開発のすべてをできないと⼀⼈前ではないわけではない ○ すでに現場では⼀⼈前の社員として扱われます ○ できることからやっていきましょうガイダンス学習について 49

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

©2024 Aiming Inc. FizzBuzz を出⼒してみよう FizzBuzz というゲームプレイヤーは円状に座る。最初のプレイヤーは「1」と数字を発⾔する。次のプレイヤーは直前のプレイヤーの次の数字を発⾔していく。ただし、 3で割り切れる場合は「Fizz」 5で割り切れる場合は「Buzz」両者で割り切れる場合は「Fizz Buzz」を数の代わりに発⾔しなければならない。発⾔を間違えた者や、ためらった者は脱落となる。 http://ja.wikipedia.org/wiki/Fizz_Buzz Ruby の基礎課題 59

Slide 61

Slide 61 text

©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 ﬁzzbuzz.rb で実⾏されること Ruby の基礎課題 60

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 2024 年の状況 ● Copilot, ChatGPT などの⽣成系 AI は有効活⽤するただし、セキュリティには⼗分気をつける。 ChatGPT など（に限らず検索やウェブサービスなどでも）に、業務上の機密情報や特定可能な情報は決して⼊⼒しないこと。新⼈だから許される、ということはありません。 ex) ChatGPT, Google 検索, DeepL などソフトウェア⼯学の知識ソフトウェア⼯学の知識 70

Slide 72

Slide 72 text

Slide 73

Slide 73 text

©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 太字: 業務で使⽤されることのある⾔語

Slide 74

Slide 74 text

Slide 75

Slide 75 text

©2024 Aiming Inc. ● クラス ○ オブジェクトの設計図のようなもの ○ 属性 (フィールド) と動作/機能 (メソッド) が定義される ● オブジェクト ○ クラスから⽣成されるインスタンス ■ ex.)「⾞」という抽象的なクラスから「⾚い⾞」や「スポーツカー」といった具体的なオブジェクトを⽣成 ○ 実際のデータ（フィールドの値）と動作/機能（メソッドの実⾏）をもつソフトウェア⼯学の知識オブジェクト指向プログラミング 74

Slide 76

Slide 76 text

©2024 Aiming Inc. ３つの特性 ● 継承 (inheritance) ○ クラスの構造化。コードの再利⽤性の向上 ● カプセル化 (encapsulation) ○ 外部からのアクセスを制限。データの安全性の確保 ● ポリモーフィズム（多態性: polymorphism） ○ overload, override により、オブジェクトの型に基づいて異なる振る舞い（メソッド実⾏）を可能にソフトウェア⼯学の知識オブジェクト指向プログラミング 75

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

©2024 Aiming Inc. Gang of Four (GoF) の 23 パターン ● ⽣成に関するパターン ○ ex. Singleton, Factory Method ● 構造に関するパターン ○ ex. Facade, Proxy ● 振る舞いに関するパターン ○ ex. Observer, Strategy ソフトウェア⼯学の知識デザインパターン 78 徐々に増やしていけば良い。 PJ やライブラリのコードを読んでいると、パターンに出くわすことがよくあるので、一度ざっとさらっておくと良い

Slide 80

Slide 80 text

©2024 Aiming Inc. ● 新しい課題 ○ クラウドサービス、モバイルアプリケーション、⼤規模データ処理など、現代に即したパターンも ○ ゲーム開発 => https://gameprogrammingpatterns.com/ ex.) 依存性の注⼊ (DI: Dependency Injection) ○ オブジェクトがその他のオブジェクトの依存関係を⾃動で注⼊する ■ ref. Spring Framework, Zenject(Extenject) など… ソフトウェア⼯学の知識デザインパターン 79

Slide 81

Slide 81 text

©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

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

©2024 Aiming Inc. SOLID 原則 ● 単⼀責任の原則 (S: Single Responsibility Principle) ○ あるクラスは⼀つの責任だけを持つべき ■ ex.) ログ記録とデータ処理を⼀つのクラスで⾏うのではなく、それぞれの責任を持つクラスを分ける ● 開放/閉鎖の原則 (O: Open/Closed Principle) ○ 拡張に対して開かれ、変更に対して閉じられているべき ■ ex.) 新しい機能を追加するために既存のコードを変更するのではなく、既存のコードに新しいコードを追加する形で拡張する ■ 注) 既存コードの実装を変更してはいけない、のではなく、そういう⾵に設計しましょうという話ソフトウェア⼯学の知識ソフトウェア設計 83

Slide 85

Slide 85 text

©2024 Aiming Inc. SOLID 原則 ● リスコフの置換原則 (L: Liskov Substitution Principle) ○ サブタイプは、そのスーパータイプと置換可能であるべき ■ ex.) 「⾶ぶ」メソッドをもつ「⿃」クラスのサブクラスとして「ペンギン」クラスは適当か？ ● 解決策1) 「⾶べる⿃」、「⾶べない⿃」の抽象クラスを使⽤ ● 解決策2) 「⾶べる」というインタフェースを使⽤ ● インターフェース分離の原則 (I: Interface Segregation Principle) ○ クライアントは不必要なインターフェースに依存すべきではない ■ ex.) ⼀つの汎⽤インターフェースよりも、特定のクライアントに必要なメソッドのみを提供する複数の特化したインターフェースを⽤意するソフトウェア⼯学の知識ソフトウェア設計 84

Slide 86

Slide 86 text

©2024 Aiming Inc. SOLID 原則 ● 依存性逆転の原則 (D: Dependency Inversion Principle) ○ ⾼レベルのモジュールは低レベルのモジュールに依存すべきではない。両者は抽象に依存すべき。 ■ ⾼レベル: ビジネスルールを定義するモジュールなど ■ 低レベル: データアクセスや、ユーティリティなど、具体的な実装を提供するモジュールソフトウェア⼯学の知識ソフトウェア設計 85

Slide 87

Slide 87 text

©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) { // クエスト報酬としてアイテムを取得するロジック } }

Slide 88

Slide 88 text

©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); } }

Slide 89

Slide 89 text

©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 をモックに置き換えることで、統合テストやユニットテストが簡単になります。

Slide 90

Slide 90 text

Slide 91

Slide 91 text

©2024 Aiming Inc. ドメイン駆動設計のコンセプト ● エンティティ (Entity) ⼀意の識別⼦を持つ、変化するドメインオブジェクト ● 値オブジェクト (Value Object) 識別⼦を持たず、属性のみで定義される不変のオブジェクト ● 集約 (Aggregate) ⼀つのエンティティを主とし、関連オブジェクトを⼀つの単位として扱う ● リポジトリ (Repository) 集約の永続化と再構築を管理する ● ドメインサービス (Domain Service) エンティティや値オブジェクトを超えるドメインロジックを提供 ● ユビキタス⾔語 (Ubiquitous Language) 開発チームとステークホルダーが共有するプロジェクト固有の⾔語ソフトウェア⼯学の知識ソフトウェア設計 90

Slide 92

Slide 92 text

©2024 Aiming Inc. • DRY (Don't Repeat Yourself.) • KISS (Keep it Simple, stupid.) • YAGNI (You Ain't Gonna Need It.) • 驚き最⼩の原則 • 確証性バイアス • 銀の弾丸 • 計測せよ • コードの臭い • ⾞輪の再発明ソフトウェア⼯学の知識過去の⼈類の知⾒を知るソフトウェア開発の原理原則/ベストプラクティス/アンチパターン 91 • 正常性バイアス • ドッグフーディング • 早すぎる最適化 • プログラマの三⼤美徳 • マジックナンバー • ヤクの⽑刈り • ラバーダッキング • 割れ窓理論 … １年後, ２年後くらいに改めて読んでみると腹落ちするかも

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

©2024 Aiming Inc. https://github.com/foo/bar/baz/exam1 にあるファイルを修正し、次ページの要件を満たしてください ● 最初に exam1 フォルダに⾃分のアカウント名のフォルダを作成し、雛形のファイルをコピーしてください ● 成果物は GitHub のリポジトリに push してください ● main ブランチに push せず、トピックブランチを作成し Pull Request を作成してください ○ ブランチ名: <⾃分のアカウント>/exam1 ■ ex.) ckazu/exam1 実習1 実習１ 94

Slide 96

Slide 96 text

Slide 97

Slide 97 text

©2024 Aiming Inc. 1. レアリティ UR を追加してください 2. 10 回連続ガチャを定義してください 3. ガチャはレアリティごとに異なった確率で抽選されるようにしてください C: 60%, UC: 30%, R: 7%, SR: 2%, UR: 1% 15:50 開始実習1 実習１ 96 注:  ● git や Ruby の質問は随時してください  ● コミットの粒度もきちんと考えること 

Slide 98

Slide 98 text

©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

Slide 99

Slide 99 text

Slide 100

Slide 100 text

Slide 101

Slide 101 text

Slide 102

Slide 102 text

Slide 103

Slide 103 text

Slide 104

Slide 104 text

Slide 105

Slide 105 text

©2024 Aiming Inc. 仕様をそのまま実装することが、⾯⽩いゲーム（良いサービス）を作ることにつながるだろうか ● 新しいゲーム要素を追加することで、全体の⾯⽩さが変化 ● Try & Error が重要 ○ 作っては評価して変更していくことの繰り返し ○ 作った機能を作り直すことも厭わない ○ そのサイクルを何度も回していくことで、ゴールに近づいていく開発プロセスについてゲーム開発 104

Slide 106

Slide 106 text

©2024 Aiming Inc. 1999 Extreme Programming (Kent Beck) ● 従来の開発⼿法へのアンチテーゼ ● アジャイル開発⼿法の先駆け ● XP におけるプラクティス ● 共同: イテレーション、共通⾔語、共同作業、振り返り ● 開発: TDD（テスト駆動開発: Test driven development ）, ペアプロ, リファクタ, YAGNI, CI(continuous integration), コードの共同化 ● 管理者: 責任, 援護... ● 顧客: ストーリー作成, 短期リリース... 開発プロセスについて XP 105

Slide 107

Slide 107 text

©2024 Aiming Inc. agile: 俊敏な、機敏な ● 短い開発プロセスと顧客からのフィードバックの繰り返しにより、顧客の⽬的を達成 ● 主なフレームワーク ○ スクラム, カンバン, XP など ● 注: これさえやっておけば良いという開発⼿法ではない柔軟な対応をすることが重要 PJ やチームメンバー、開発フェーズに合わせたやり⽅を模索し、改善することが必要開発プロセスについてアジャイル開発 106

Slide 108

Slide 108 text

Slide 109

Slide 109 text

Slide 110

Slide 110 text

Slide 111

Slide 111 text

Slide 112

Slide 112 text

Slide 113

Slide 113 text

Slide 114

Slide 114 text

Slide 115

Slide 115 text

Slide 116

Slide 116 text

Slide 117

Slide 117 text

Slide 118

Slide 118 text

Slide 119

Slide 119 text

Slide 120

Slide 120 text

Slide 121

Slide 121 text

Slide 122

Slide 122 text

©2024 Aiming Inc. ● メソッドの抽出/クラスの分割 ● マジックナンバーの除去 ● 配列やハッシュから、オブジェクトへの変更 ● ポリモーフィズムの導⼊ ● State/Strategy パターンへの変更 ● 条件式のメソッド化 ● 深いネストの解消 ● フラグ処理の除去など... 「何となくこっちが良さそう」、ではなく、根拠を持ったリファクタリングを開発プロセスについてリファクタリングの⼿法 121

Slide 123

Slide 123 text

©2024 Aiming Inc. Q. テストを書いたり、リファクタリングをしたりしていたら、開発スピードは落ちないのか？ A. 落ちない最初は時間がかかる⾯は確かにある（慣れていない、チームののコミュニケーション不⾜、ドメイン知識の不⾜など）。ただ、継続した開発を続ければ続けるほど効いてくる。逆に、テストコードがなかったり、まずい設計を残してしまうと、後でつけを払うことになる（技術的負債）開発プロセスについて疑問: 開発スピードへの危惧 122

Slide 124

Slide 124 text

Slide 125

Slide 125 text

Slide 126

Slide 126 text

Slide 127

Slide 127 text

Slide 128

Slide 128 text

Slide 129

Slide 129 text

©2024 Aiming Inc. ドライバー ● キーボードを触り、コーディングを進める係。 ● これからやろうとしていることは逐⼀⼝に出して共有する。 ● 勝⼿に実装しない。⽅向性はナビゲーターに委ねる。ナビゲーター ● ドライバーは⽬の前のタイピングに意識を取られがちになる ● 広い視野を持ち先読みをしてドライバーをナビゲートする ● タイプミスなども指摘し無駄なはまり⽅をしないよう助けるペアプログラミングペアプログラミング 128

Slide 130

Slide 130 text

Slide 131

Slide 131 text

Slide 132

Slide 132 text

Slide 133

Slide 133 text

Slide 134

Slide 134 text

Slide 135

Slide 135 text

Slide 136

Slide 136 text

Slide 137

Slide 137 text

Slide 138

Slide 138 text

Slide 139

Slide 139 text

Slide 140

Slide 140 text

©2024 Aiming Inc. ● ナビゲーターが個⼈の PC やスマホで勝⼿に調べないこと ○ PC を操作できるのはドライバーだけです ○ 調査したいことがあれば、指⽰をして全員で共有している状態で調査します ● この演習では⼿分けして作業するという⾏為は禁⽌します ※ 演習の⽬的は、より良い実装をすることよりも、チーム開発の実感を得ることです。相談しながら協⼒してチームで作業を進め、課題を解決してください。開発プロセスについて演習3 139

Slide 141

Slide 141 text

Slide 142

Slide 142 text

Slide 143

Slide 143 text

©2024 Aiming Inc. ● プレミアムガチャを実装してください ○ 排出物の情報は確率以外すべて出⼒すること ● ノーマルガチャを実装してください ● ドラゴン種族の排出確率が2倍になるドラゴンガチャを実装してください。ノーマルガチャのテーブルをベースとします ● 特定のキャラクターの排出確率が10倍になるピックアップガチャを実装してください。ノーマルガチャのテーブルをベースとします ■ ピックアップ: xxx, xxx, xxx 開発プロセスについて演習3: 課題-1 142

Slide 144

Slide 144 text

©2024 Aiming Inc. ● すべてのガチャで回数を指定して実⾏（最⼤10回）できるようにしてください 1-10 回以外はエラーとし、実⾏できないようにしてください ● プレミアムガチャの10回連続実⾏では、最後の⼀回では SR, UR が必ず排出されるようにしてください確率はプレミアムガチャに準じます ※ プレミアムドラゴンガチャは対象外です開発プロセスについて演習3: 課題-2 143