Upgrade to Pro — share decks privately, control downloads, hide ads and more …

2024 コーディング研修

ckazu
May 08, 2024

2024 コーディング研修

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

ckazu

May 08, 2024
Tweet

More Decks by ckazu

Other Decks in Programming

Transcript

  1. ©2024 Aiming Inc. ガイダンス 講義について 1 • 座学と実習を交互に実施します。 • エンジニア採⽤の⽅、エンジニア以外の職種の⽅が混ざって

    いますが、同じ内容を⼀緒におこないます。 • ⼀⼈でがんばる研修ではありません。 お互いにサポートしながら進めてください。 • この講義中は、⽣成 AI は使⽤しないでください。 ◦ ChatGPT, Copilot, Claude AI, Perplexity, ⾃分で構築した LLM の使⽤など
  2. ©2024 Aiming Inc. ⼀⽇⽬ • ガイダンス • Ruby の基礎 [休憩]

    • チュートリアル課題 • チュートリアル課題フィードバック [昼休み] • コーディングに必要な知識について [休憩] • 演習課題 I ガイダンス コーディング研修 スケジュール 2 ⼆⽇⽬ • 演習課題 I の ピアレビューとフィードバック [休憩] • 開発プロセスについて アジャイル開発, TDD, リファクタリング [昼休み] • チーム開発 {ペア, モブ}プログラミングについて [休憩] • 演習課題 III [休憩] • 研修講評
  3. ©2024 Aiming Inc. ガイダンス 講義のねらい 5 コーディングを中⼼として、Aiming の開発プロセスを知る エンジニア職の⽅ •

    Aiming が採⽤している開発⼿法の採⽤意図を知る • 演習を通じて、なぜこういった⽅針を⼤事にしているのかを 体験から理解する エンジニア以外の職種の⽅ • エンジニア業務への理解を深める • エンジニアの開発⼿法へのこだわりの理由を体験から知る
  4. ©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 [質問] どうしたら読みやすくなるでしょうか
  5. ©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 例えば
  6. ©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 例えば
  7. ©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード •

    メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 17
  8. ©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード •

    メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 18 どれも正解 
  9. ©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード •

    メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 19 どれも正解? ↓ ⽴場や状況 によって 変化する ?
  10. ©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード •

    メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 20 ← まずはここから
  11. ©2024 Aiming Inc. ガイダンス Aiming が⾝を置いている環境 21 • モバイルオンラインゲーム ◦

    競合増加 ◦ ⾼速な開発体制, 安定したサービスの提供, ゲームの⾯⽩さ • 開発規模の⼤きさ ◦ ex) とあるPJの開発規模 ◦ チーム開発, 開発の容易さ • アップデート開発 ◦ ⻑期間にわたって継続した機能追加が続く ◦ 開発の容易さ, 安定したサービスの提供
  12. ©2024 Aiming Inc. • モバイルオンラインゲーム ◦ 競合増加 ◦ ⾼速な開発体制, ゲームの⾯⽩さ,

    安定したサービスの提供 • 開発規模の⼤きさ ◦ ex) とあるPJの開発規模 ◦ チーム開発, 開発の容易さ • アップデート開発 ◦ ⻑期間にわたって継続した機能追加が続く ◦ 追加開発の容易さ, 安定したサービス提供 ガイダンス Aiming が⾝を置いている環境 22
  13. ©2024 Aiming Inc. • チーム開発 ◦ 開発容易性 • 安定性の⾼いサービス提供 ◦

    保守性 • アップデート開発 ◦ 拡張性 ガイダンス Aiming がやりたいこと 23
  14. ©2024 Aiming Inc. • チーム開発 ◦ 開発容易性 • 安定性の⾼いサービス提供 ◦

    保守性 • アップデート開発 ◦ 拡張性 ガイダンス Aiming がやりたいこと 24 開発しやすく、保守性が高く、拡張性にも優れた
 開発ができる体制

  15. ©2024 Aiming Inc. • ⽬指すところ ◦ Aiming に所属するエンジニアが誰でも理解できる コードを書くこと •

    なぜなら ◦ チーム開発で、 ◦ バグやエラーが少なく、 ◦ 機能追加が容易な 開発をしたいから ガイダンス Aiming が⽬指すコーディングの指針 25
  16. ©2024 Aiming Inc. • 組織には様々なキャリアの⼈がいる ◦ OSS コミッター ◦ ベテラン,

    中堅 ◦ ウェブ系など他業種からの転職 ◦ 情報系出⾝の新⼈ ◦ ゲーム学校出⾝の新⼈ ◦ グラフィックのスペシャリスト ◦ データベースのスペシャリスト etc. ガイダンス チーム開発におけるコーディング 27
  17. ©2024 Aiming Inc. • リーダーという役割 ◦ リーダーは役職ではなく、チームにおける役割 • (リーダーとは別に)リーダーシップはいたるところにある ◦

    ex.) タスクを遂⾏する ▪ 実装して終わりではなく、デザイナー/企画を巻き込ん でゴールに向かう ◦ ex.) PR をマージできるようにする ▪ PR がなかなかマージされない ▪ なぜマージされないのか、問題解決のために⾏動する ガイダンス チーム開発におけるコーディング 29
  18. ©2024 Aiming Inc. • チーム開発 • コードレビュー • ペアプログラミング •

    (OJT) ⾃分の書いたコードはいずれ誰かが⼿を加えるもの。 レビューをする⼈にも(意図的にしなかった⼈にも) そのコードへの責任がある。 ガイダンス チーム開発におけるコーディング 30 コードは個人のものではなく、チームのもの

  19. ©2024 Aiming Inc. ⼀つのタイトルでの売上はどれくらい? • 1ヶ⽉あたり • 1⽇あたり • 1時間あたり

    社内 KPI ツールで確認してみる ガイダンス コードの保守性, サービスの安定性 32
  20. ©2024 Aiming Inc. 臨時メンテナンスが発⽣したら... • 機会損失額 = ダウンタイム × 売上⾒込み/h

    • メンテナンスコスト = ダウンタイム × チーム⼈数 × ⼈件費/h • 問い合わせ、事後対応コスト ガイダンス コードの保守性, サービスの安定性 34
  21. ©2024 Aiming Inc. • ダウンタイム ◦ 売上への機会損失 ◦ ユーザの不満 ▪

    ゲーム離れへのリスク ▪ 問い合わせコスト ◦ 不具合発⽣時の補填対応 ▪ 対応コスト ▪ 補填コスト ガイダンス コードの保守性, サービスの安定性 35
  22. ©2024 Aiming Inc. なぜダウンタイムが発⽣するか • 定期メンテナンス ◦ システムを停⽌するメンテナンスが不要な設計の検討 ▪ ex.)

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

    blue/green deployment • 臨時メンテナンス ◦ バグの少ない開発 ◦ データ設定のミスが発⽣しない内部システム • システム障害 ◦ 冗⻑設計 ◦ 早期の障害検知 ガイダンス コードの保守性, サービスの安定性 37
  24. ©2024 Aiming Inc. • コードの保守性 ◦ 保守性 (maintainability) ▪ プログラムの継続動作

    ▪ プログラムの問題解消への容易さ ガイダンス コードの保守性, サービスの安定性 38
  25. ©2024 Aiming Inc. • コードの保守性 ◦ 保守性 (maintainability) ▪ プログラムの継続動作

    ▪ プログラムの問題解消への容易さ ガイダンス コードの保守性, サービスの安定性 39 サービス運用後も考慮した
 コーディング(設計)が大事

  26. ©2024 Aiming Inc. • コードの保守性 ◦ 保守性 (maintainability) ▪ プログラムの継続動作

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

  27. ©2024 Aiming Inc. • PJ のアップデート計画を決めるためには ◦ 将来(1年後までなど⻑期)のマイルストーン策定 ◦ 仕様の決定タイミング

    ◦ 協業先との合意タイミング ◦ 開発完了タイミング ◦ QA フェーズの確保 ◦ ストアの審査期間 ◦ メンテナンス⽇の決定 etc… ガイダンス 追加開発への拡張性 43
  28. ©2024 Aiming Inc. • アップデートを⾒越した開発は、実のところ難しい • 継続してサービスしているので状況次第で開発計画も変わり 得る • 経験が必要になる⾯は多分にある

    ガイダンス 追加開発への拡張性 46 サービス運用後も考慮した
 コーディング(設計)が大事
 とはいえ、いきなりは難しいので、まずは経験のある人に支えてもらいましょう。
 そのためのチーム開発です。
 再掲

  29. ©2024 Aiming Inc. • ⼈⼒で対応可能なことはたくさんある。まずは動くものを。 ただ、 • 積もり積もった⼈⼒対応は、いずれ莫⼤なコスト増になる ◦ ⼈件費

    ▪ ⼈員増, 残業, 深夜対応, 休⽇対応... ◦ ⼈的ミスによる損失 ▪ ⼿作業によるミスやチェックもれ, 疲労によるミス ガイダンス コスト意識 47
  30. ©2024 Aiming Inc. • ちょっとしたコードで解決することも プログラミングはエンジニアだけのものではない • 例えば、 ◦ Google

    Apps Script で何か書いてみる ◦ 書籍: 退屈なことはPythonにやらせよう ◦ データ分析の SQL はプランナー、運営職が書くことも多い ◦ ChatGPT, GitHub Copilot ex.) 運営のスタッフがコードを書いている事例 ガイダンス コスト意識 48
  31. ©2024 Aiming Inc. • 今後、試験は存在しません ◦ 合格するための学習科⽬などの⽬標はありません ◦ 答えのない問題を解いていくのが業務内容(課題解決) ◦

    ⾃分で⾝につける内容を取捨選択する必要がある ◦ 何を学ぶかを選択するのも課題解決能⼒を磨くひとつ • 急ぐ必要はない ◦ ⼀つずつじっくりと ◦ わからなくても時間をおいて何度も咀嚼するのがおすすめ • 開発のすべてをできないと⼀⼈前ではないわけではない ◦ すでに現場では⼀⼈前の社員として扱われます ◦ できることからやっていきましょう ガイダンス 学習について 49
  32. ©2024 Aiming Inc. どうやって学習するか • 就業時間内で⼗分学習できる ◦ ⼀⽇ 8 時間、約

    200 ⽇分の学びの機会がある ▪ 実装で考える、調査する ▪ コードレビューで知⾒を得る、質問する ▪ チームや社内の⼈に気軽に聞く ▪ 勉強会、輪読会を開催する(就業時間内で実施可能) ▪ 書籍購⼊(申請は上⻑に確認) ガイダンス 学習について 50
  33. ©2024 Aiming Inc. • 誰でも理解できるようなコーディングができるようになりま しょう • なぜなら ◦ チームで開発するから

    ◦ コードの保守性を⾼めたいから ◦ 安定したサービス運営をしたいから ガイダンス ガイダンスのまとめ 52
  34. ©2024 Aiming Inc. • 誰でも理解できるようなコーディングができるようになりま しょう • そのための武器をこれから⾝につけていきましょう ◦ 読みやすいコードの書き⽅

    ◦ ソフトウェア⼯学の基礎知識 ◦ チーム開発 について研修で理解を深めていきます。 ガイダンス ガイダンスのまとめ 53
  35. ©2024 Aiming Inc. • 誰でも理解できるようなコーディングができるようになりま しょう • ただし、研修ではすぐに役に⽴つ⼒は⾝につきません ◦ ⾃分で⼿を動かす

    ◦ ⾃分で考える ◦ なんでもやってみる  ことを継続すること重要です ガイダンス ガイダンスのまとめ 55
  36. ©2024 Aiming Inc. 研修では Ruby を使います 基礎⽂法を駆け⾜で確認します ※ この講義では Ruby

    を習得することが⽬的ではありません。 Ruby に関する問題はすぐに質問してください。 周囲の⼈にサポートを求めても構いません。 Ruby の基礎 Ruby の基礎 57
  37. ©2024 Aiming Inc. • 動的型付け⾔語 • リファレンスマニュアル ◦ https://docs.ruby-lang.org/ja/ •

    チュートリアル ◦ https://www.ruby-lang.org/ja/documentation/quickstart Ruby の基礎 Ruby の基礎 58
  38. ©2024 Aiming Inc. FizzBuzz を出⼒してみよう FizzBuzz というゲーム プレイヤーは円状に座る。 最初のプレイヤーは「1」と数字を発⾔する。 次のプレイヤーは直前のプレイヤーの次の数字を発⾔していく。

    ただし、 3で割り切れる場合は 「Fizz」 5で割り切れる場合は 「Buzz」 両者で割 り切れる場合は 「Fizz Buzz」 を数の代わりに発⾔しなければならない。 発⾔を間違えた者や、ためらった者は脱落となる。 http://ja.wikipedia.org/wiki/Fizz_Buzz Ruby の基礎 課題 59
  39. ©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
  40. ©2024 Aiming Inc. • ファイル名: tutorial/<your_name>/fizzbuzz.rb • main ブランチに push

    せず、トピックブランチを作成し Pull Request を作成してください ◦ ブランチ名: <⾃分のアカウント>/tutorial ▪ ex.) ckazu/tutorial ◦ git 研修を思い出して! Ruby の基礎 課題 61
  41. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • オブジェクト指向 ◦ SOLID 原則 ◦

    デザインパターン • ソフトウェアアーキテクチャ • テスト技法 • リファクタリング技法 • ⾔語やライブラリのリファレンス ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 65
  42. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • オブジェクト指向, SOLID 原則, デザインパターン •

    ソフトウェアアーキテクチャ • テスト技法 • リファクタリング これらをベーススキルとして、理解し使えるようになっていく。 学校の講義に出てくるだけのものではなく、エンジニアの業務上 で実際に使⽤するスキル。 ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 66
  43. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • ⾔語やライブラリのリファレンス これが⼀番の武器 ⾃分が使う技術の仕様(実装)を把握しておく • ex.)

    ⾔語仕様の理解 ⽂法だけではなく、すべての標準メソッドが把握できてい る、など • ex.) 使⽤ライブラリの実装把握 ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 67
  44. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • ⾔語やライブラリのリファレンス • ⼀次ソースに当たる癖をつけるためにも、リファレンスを⾒ に⾏くようにするのが良い •

    アップデートを追いリリースノートを読む習慣をつけるのも 良い • とりあえずググる、はしばらくやめてみるのがおすすめ ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 68
  45. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 2024 年の状況 • Copilot, ChatGPT などの⽣成系

    AI は有効活⽤する これまで、レビューや書籍などから得ていた知識を超特急で⾝に つけることができるようになった。 最短で実践で通⽤するコードや知識の習得が可能なのでツールと して有効活⽤する。 ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 69
  46. ©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 2024 年の状況 • Copilot, ChatGPT などの⽣成系

    AI は有効活⽤する ただし、セキュリティには⼗分気をつける。 ChatGPT など(に限らず検索やウェブサービスなどでも)に、業 務上の機密情報や特定可能な情報は決して⼊⼒しないこと。 新⼈だから許される、ということはありません。 ex) ChatGPT, Google 検索, DeepL など ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 70
  47. ©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 太字: 業務で使⽤されることのある⾔語
  48. ©2024 Aiming Inc. • クラス ◦ オブジェクトの設計図のようなもの ◦ 属性 (フィールド)

    と動作/機能 (メソッド) が定義される • オブジェクト ◦ クラスから⽣成されるインスタンス ▪ ex.)「⾞」という抽象的なクラスから「⾚い⾞」や「スポー ツカー」といった具体的なオブジェクトを⽣成 ◦ 実際のデータ(フィールドの値)と 動作/機能(メソッドの実⾏)をもつ ソフトウェア⼯学の知識 オブジェクト指向プログラミング 74
  49. ©2024 Aiming Inc. 3つの特性 • 継承 (inheritance) ◦ クラスの構造化。コードの再利⽤性の向上 •

    カプセル化 (encapsulation) ◦ 外部からのアクセスを制限。データの安全性の確保 • ポリモーフィズム(多態性: polymorphism) ◦ overload, override により、オブジェクトの型に基づいて 異なる振る舞い(メソッド実⾏)を可能に ソフトウェア⼯学の知識 オブジェクト指向プログラミング 75
  50. ©2024 Aiming Inc. オブジェクト指向プログラミングの利点 • 直感的 ◦ 現実を模倣することで、直感的な設計ができる • 再利⽤性

    ◦ ⼀度作ったクラスを複数のコードで利⽤できる • 拡張可⽤性 ◦ 追加実装の際、実装量や既存コードの変更を少なくできる ソフトウェア⼯学の知識 オブジェクト指向プログラミング 76
  51. ©2024 Aiming Inc. Gang of Four (GoF) の 23 パターン

    • ⽣成に関するパターン ◦ ex. Singleton, Factory Method • 構造に関するパターン ◦ ex. Facade, Proxy • 振る舞いに関するパターン ◦ ex. Observer, Strategy ソフトウェア⼯学の知識 デザインパターン 78 徐々に増やしていけば良い。 PJ やライブラリのコードを読んでいると、パター ンに出くわすことがよくあるので、一度ざっとさ らっておくと良い
  52. ©2024 Aiming Inc. • 新しい課題 ◦ クラウドサービス、モバイルアプリケーション、⼤規模 データ処理など、現代に即したパターンも ◦ ゲーム開発

    => https://gameprogrammingpatterns.com/ ex.) 依存性の注⼊ (DI: Dependency Injection) ◦ オブジェクトがその他のオブジェクトの 依存関係を⾃動で注⼊する ▪ ref. Spring Framework, Zenject(Extenject) など… ソフトウェア⼯学の知識 デザインパターン 79
  53. ©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
  54. ©2024 Aiming Inc. • 配属プロジェクトで採⽤されているアーキテクチャは? ◦ Unity のクライアント ◦ サーバサイド

    ◦ 開発⽤社内ウェブサービス ソフトウェア⼯学の知識 ソフトウェアアーキテクチャ 81
  55. ©2024 Aiming Inc. SOLID 原則 • 単⼀責任の原則 (S: Single Responsibility

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

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

    Principle) ◦ ⾼レベルのモジュールは低レベルのモジュールに依存すべきではな い。両者は抽象に依存すべき。 ▪ ⾼レベル: ビジネスルールを定義するモジュールなど ▪ 低レベル: データアクセスや、ユーティリティなど、具体的な実 装を提供するモジュール ソフトウェア⼯学の知識 ソフトウェア設計 85
  58. ©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) { // クエスト報酬としてアイテムを取得するロジック } }
  59. ©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); } }
  60. ©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 をモックに置き換えることで、統合テストやユニットテ ストが簡単になります。
  61. ©2024 Aiming Inc. ドメイン駆動設計 (DDD: Domain-Driven Design) • 現実の問題領域(ドメイン)を中⼼に、設計/開発を進めるアプロー チ

    ◦ 開発者はビジネスへの深い理解を元に現実世界の問題をモデリ ングする(ドメインモデル) ◦ 開発者と ビジネスのステークホルダーが協⼒ ソフトウェア⼯学の知識 ソフトウェア設計 89
  62. ©2024 Aiming Inc. ドメイン駆動設計のコンセプト • エンティティ (Entity) ⼀意の識別⼦を持つ、変化するドメインオブジェクト • 値オブジェクト

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

    (Keep it Simple, stupid.) • YAGNI (You Ain't Gonna Need It.) • 驚き最⼩の原則 • 確証性バイアス • 銀の弾丸 • 計測せよ • コードの臭い • ⾞輪の再発明 ソフトウェア⼯学の知識 過去の⼈類の知⾒を知る ソフトウェア開発の原理原則/ベストプラクティス/アンチパターン 91 • 正常性バイアス • ドッグフーディング • 早すぎる最適化 • プログラマの三⼤美徳 • マジックナンバー • ヤクの⽑刈り • ラバーダッキング • 割れ窓理論 … 1年後, 2年後くらいに改めて読んでみると腹落ちするかも
  64. ©2024 Aiming Inc. https://github.com/foo/bar/baz/exam1 にあるファイルを修正し、次ページの要件を満たしてください • 最初に exam1 フォルダに⾃分のアカウント名のフォルダを作 成し、雛形のファイルをコピーしてください

    • 成果物は GitHub のリポジトリに push してください • main ブランチに push せず、トピックブランチを作成し Pull Request を作成してください ◦ ブランチ名: <⾃分のアカウント>/exam1 ▪ ex.) ckazu/exam1 実習1 実習1 94
  65. ©2024 Aiming Inc. 1. レアリティ UR を追加してください 2. 10 回連続ガチャを定義してください

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

  66. ©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 実習1 97
  67. ©2024 Aiming Inc. • 他のメンバーの PR にレビューコメントを書いてください 各メンバーのコード、最低⼀箇所にコメントを残すこと ◦ 明らかな間違いの指摘

    ▪ バグ、仕様との差異など ◦ 別案の提案 ▪ 効率性、可読性などの観点から ◦ ⾃分が知らなかったところ ◦ 良いと思ったところ ◦ 質問 など 実習1 実習1のピアレビュー/講評 101
  68. ©2024 Aiming Inc. 仕様をそのまま実装することが、⾯⽩いゲーム(良いサービス) を作ることにつながるだろうか • 新しいゲーム要素を追加することで、全体の⾯⽩さが変化 • Try &

    Error が重要 ◦ 作っては評価して変更していくことの繰り返し ◦ 作った機能を作り直すことも厭わない ◦ そのサイクルを何度も回していくことで、ゴールに近づ いていく 開発プロセスについて ゲーム開発 104
  69. ©2024 Aiming Inc. 1999 Extreme Programming (Kent Beck) • 従来の開発⼿法へのアンチテーゼ

    • アジャイル開発⼿法の先駆け • XP におけるプラクティス • 共同: イテレーション、共通⾔語、共同作業、振り返り • 開発: TDD(テスト駆動開発: Test driven development ), ペア プロ, リファクタ, YAGNI, CI(continuous integration), コードの 共同化 • 管理者: 責任, 援護... • 顧客: ストーリー作成, 短期リリース... 開発プロセスについて XP 105
  70. ©2024 Aiming Inc. agile: 俊敏な、機敏な • 短い開発プロセスと顧客からのフィードバックの繰り返しに より、顧客の⽬的を達成 • 主なフレームワーク

    ◦ スクラム, カンバン, XP など • 注: これさえやっておけば良いという開発⼿法ではない 柔軟な対応をすることが重要 PJ やチームメンバー、開発フェーズに合わせたやり⽅を模索 し、改善することが必要 開発プロセスについて アジャイル開発 106
  71. ©2024 Aiming Inc. スクラム • プロダクトオーナー ◦ PJ のビジョン要件定義、優先順位の決定 •

    スクラムマスター ◦ チームがスクラムのプロセスにしたがって作業できる よう⽀援する • チーム ◦ 実際に開発を⾏う、⾃⼰管理型のチーム 開発プロセスについて アジャイル開発 108
  72. ©2024 Aiming Inc. スクラムにおけるイベント • スプリント(イテレーション) ◦ 開発期間の単位 • デイリースクラム(スタンドアップミーティング)

    ◦ ⽇々の進捗の共有 • スプリントレビュー ◦ スプリントの最後に⾏う製品デモ フィードバックを得る • レトロスペクティブ ◦ 振り返り。改善点は次のスプリントに反映させる 開発プロセスについて アジャイル開発 109
  73. ©2024 Aiming Inc. • イテレーションを回すことの重要性 ◦ フィードバックの収集 ◦ リスクの低減 ◦

    進⾏状況の明確化 ◦ モチベーション向上 • 不確実性コーン ◦ PJ 開始時には⾼い不確実性が、時間の経過とともに減 少していく ◦ 初期段階では未知な部分がとても⼤きい 開発プロセスについて アジャイル開発 110 小さなサイクルを回していくことでリスクを低減
  74. ©2024 Aiming Inc. TDD: Test-Driven Development テストファースト • まず最初にテストコードを書く(注: 網羅しないこと)

    ◦ テストを失敗させる (red) • テストを通る実装を最速で⾏う (green) • テストが成功する状態を保ちながら、リファクタリン グを⾏う 開発プロセスについて テスト駆動開発 112
  75. ©2024 Aiming Inc. BDD: Behavior Driven Development 振る舞い駆動開発 システムの振る舞いをテストコードで記述する •

    TDD: 単体テスト • 仕様のテスト • BDD: 結合(受け⼊れ)テスト • 要件やユースケースに近い部分のテスト 開発プロセスについて テスト駆動開発 114
  76. ©2024 Aiming Inc. いつやるか • 毎実装ごとにやる 機能追加のフェーズであれば、最初にリファクタリングを⾏う • コードに⼿を⼊れる前に⼿を⼊れやすくしておく •

    テストがなければ(不⼗分であれば)追加する => 実装から時間が経っていると、状況が変化している事が多い 開発プロセスについて リファクタリング 120
  77. ©2024 Aiming Inc. • メソッドの抽出/クラスの分割 • マジックナンバーの除去 • 配列やハッシュから、オブジェクトへの変更 •

    ポリモーフィズムの導⼊ • State/Strategy パターンへの変更 • 条件式のメソッド化 • 深いネストの解消 • フラグ処理の除去 など... 「何となくこっちが良さそう」、 ではなく、根拠を持ったリファクタリングを 開発プロセスについて リファクタリングの⼿法 121
  78. ©2024 Aiming Inc. Q. テストを書いたり、リファクタリングをしたりしていたら、開 発スピードは落ちないのか? A. 落ちない 最初は時間がかかる⾯は確かにある(慣れていない、チームのの コミュニケーション不⾜、ドメイン知識の不⾜など)。

    ただ、継続した開発を続ければ続けるほど効いてくる。 逆に、テストコードがなかったり、まずい設計を残してしまう と、後でつけを払うことになる(技術的負債) 開発プロセスについて 疑問: 開発スピードへの危惧 122
  79. ©2024 Aiming Inc. • ゲーム開発 ◦ ⾯⽩くするために、常にコードは変更される ◦ 短いサイクルで改善 ◦

    アジャイル開発の⼿法を取り⼊れる • コーディングにおけるトピック ◦ テスト⼤事 ◦ リファクタリング⼤事 ◦ どちらも、保守性、拡張性を担保するためのもの 開発プロセスについて まとめ 123
  80. ©2024 Aiming Inc. • 1 台の PC • 1 台の⼤きなディスプレイ

    • 1 種類の⼊⼒デバイス を使い、 • 2 ⼈の⼈間が 実装作業をおこなう ペアプログラミング ペアプログラミング 126
  81. ©2024 Aiming Inc. ドライバー • キーボードを触り、コーディングを進める係。 • これからやろうとしていることは逐⼀⼝に出して共有する。 • 勝⼿に実装しない。⽅向性はナビゲーターに委ねる。

    ナビゲーター • ドライバーは⽬の前のタイピングに意識を取られがちになる • 広い視野を持ち先読みをしてドライバーをナビゲートする • タイプミスなども指摘し無駄なはまり⽅をしないよう助ける ペアプログラミング ペアプログラミング 128
  82. ©2024 Aiming Inc. • ドライバーとナビゲーターは 10-15 分単位を⽬処に交代する • 想像以上に負荷が⾼いので、適度に休憩を挟むこと •

    チームにおいては、ドライバーとナビゲーターのペアは、⼀ ⽇ごとに変更する、などの⽅策を取るのが良い ペアプログラミング ペアプログラミング 129
  83. ©2024 Aiming Inc. • 実装時間の短縮 • 品質の向上 • スキル、知識の共有 •

    教育 • チームワークの向上 • コードの共有意識 ... ペアプログラミング ペアプログラミングの効果 130
  84. ©2024 Aiming Inc. 組み合わせが効果的になる例 • 専⾨家 x 専⾨家 ◦ もっとも複雑な作業を成功させる

    • 専⾨家 x ⼀般的なエンジニア ◦ ⼀般的なエンジニアのスキルアップ • 専⾨家 x 新⼈ ◦ トレーニング。⽐較的容易な課題の達成 • 新⼈ x 新⼈ ◦ 単純なタスクによって、双⽅のエンジニアが経験を積む ペアプログラミング ペアリング 132
  85. ©2024 Aiming Inc. • ペアプログラミング => 2 ⼈ • モブプログラミング

    => 3 ⼈以上 1 ⼈がドライバー(タイピスト) それ以外がナビゲーター(その他のモブ) モブプログラミング モブプログラミング 133
  86. ©2024 Aiming Inc. • ドライバーは 10-15 分単位で、他のナビゲーターと順に交代 していく • ペアプロよりも、よりやろうとしていることを共有していか

    なければうまくいかない ホワイトボードなどを活⽤する • ⼈数が多いので横道にそれすぎないよう注意する ファシリテーターが別にいると良いケースも • 否定的なことは⾔わない モブプログラミング モブプログラミング 134
  87. ©2024 Aiming Inc. • 期待する効果はペアプロと同様 ◦ 品質の向上 ◦ 知識の共有 ▪

    など • プログラミングだけではない場⾯にも ◦ コードのペアレビュー、モブレビュー ◦ 仕様の確認 ◦ エンジニア以外のチームでも ◦ … モブプログラミング モブプログラミング 135 その時のチームに合わせたやり方を模索しましょう

  88. ©2024 Aiming Inc. モブプログラミングで課題を実装してください • ドライバーの順番は今ここで抽選します • この演習でのルール ◦ 15

    分経過したら、速やかにドライバーを交代してください ◦ 作業途中であってもその時点の状態をコミットすることと します ◦ 切りの良いタイミングでのコミットもおこなってください 開発プロセスについて 演習3 137
  89. ©2024 Aiming Inc. • ドライバー ◦ 操作しようとしていること、悩んでいることを常に発話し てください ◦ ⾃分の考えで実装を進めてはいけません

    • ナビゲーター ◦ ドライバー以外は全員ナビゲーターです ◦ 気がついたことを積極的に発⾔してください ◦ ナビゲーターの道標がないとドライバーは作業できません • ホワイトボードも活⽤しましょう 開発プロセスについて 演習3 138
  90. ©2024 Aiming Inc. • ナビゲーターが個⼈の PC やスマホで勝⼿に調べないこと ◦ PC を操作できるのはドライバーだけです

    ◦ 調査したいことがあれば、指⽰をして全員で共有している 状態で調査します • この演習では⼿分けして作業するという⾏為は禁⽌します ※ 演習の⽬的は、より良い実装をすることよりも、チーム開発の 実感を得ることです。 相談しながら協⼒してチームで作業を進め、課題を解決してくだ さい。 開発プロセスについて 演習3 139
  91. ©2024 Aiming Inc. • 最初に 15 分間、課題について実装の進め⽅や設計⽅針などを 相談する時間を設けます。 • 15

    分間 x n ⼈ x 2 回 = h 時間で実装してください • タイムキーパーは講師が担当します • 随時休憩をはさみます • git を活⽤して、適宜 commit などしてください 開発プロセスについて 演習3 140
  92. ©2024 Aiming Inc. • プレミアムガチャを実装してください ◦ 排出物の情報は確率以外すべて出⼒すること • ノーマルガチャを実装してください •

    ドラゴン種族の排出確率が2倍になるドラゴンガチャを実装してく ださい。ノーマルガチャのテーブルをベースとします • 特定のキャラクターの排出確率が10倍になるピックアップガチャを 実装してください。ノーマルガチャのテーブルをベースとします ▪ ピックアップ: xxx, xxx, xxx 開発プロセスについて 演習3: 課題-1 142
  93. ©2024 Aiming Inc. • すべてのガチャで回数を指定して実⾏(最⼤10回)できるように してください 1-10 回以外はエラーとし、実⾏できないようにしてください • プレミアムガチャの10回連続実⾏では、最後の⼀回では

    SR, UR が必ず排出されるようにしてください 確率はプレミアムガチャに準じます ※ プレミアムドラゴンガチャは対象外です 開発プロセスについて 演習3: 課題-2 143
  94. ©2024 Aiming Inc. • 排出されたログをファイルに記録してください ◦ ⽇時 ◦ ガチャ種別 ◦

    排出物 ◦ (連続実⾏の場合)排出順 開発プロセスについて 演習3: 課題-3 144
  95. ©2024 Aiming Inc. • (テストコードが存在しない場合)テストコードを追加してくだ さい • 全ての要件を踏まえて、現在の実装のコード設計を議論してくだ さい ◦

    議論を元にコード設計を再度おこなって、リファクタリング に取り組んでください 開発プロセスについて 演習3: 発展課題 146