Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2024 コーディング研修
Search
ckazu
May 08, 2024
Programming
2
1.3k
2024 コーディング研修
Aiming 第一事業部における 2024 年度社内研修のうちの、コーディング研修の資料です
ckazu
May 08, 2024
Tweet
Share
More Decks by ckazu
See All by ckazu
磯野家で学ぶ Prolog
ckazu
0
15
Introduction fasttext
ckazu
0
6
Query selecterの話
ckazu
0
9
仮想電子工作のすすめ
ckazu
0
12
ウェブエンジニアのための色の話
ckazu
0
8
これさえ読めば知ったかできるかもしれない人工知能の歴史と機械学習の今
ckazu
0
5
Shinjuku.html5.lunch #11
ckazu
0
13
typo の傾向と対策
ckazu
0
12
ずぶの素人がRails開発できるようになるために必要な5つのこと
ckazu
0
18
Other Decks in Programming
See All in Programming
CPython 인터프리터 구조 파헤치기 - PyCon Korea 24
kennethanceyer
0
250
VR HMDとしてのVision Pro+ゲーム開発について
yasei_no_otoko
0
110
C#/.NETのこれまでのふりかえり
tomokusaba
1
170
現場で役立つモデリング 超入門
masuda220
PRO
13
3k
Modern Angular: Renovation for Your Applications
manfredsteyer
PRO
0
220
僕がつくった48個のWebサービス達
yusukebe
18
17k
Pinia Colada が実現するスマートな非同期処理
naokihaba
2
170
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ - Kaigi on Rails 2024
falcon8823
6
2.4k
CSC509 Lecture 09
javiergs
PRO
0
120
『ドメイン駆動設計をはじめよう』のモデリングアプローチ
masuda220
PRO
8
460
Amazon Neptuneで始めてみるグラフDB-OpenSearchによるグラフの全文検索-
satoshi256kbyte
4
340
Webの技術スタックで マルチプラットフォームアプリ開発を可能にするElixirDesktopの紹介
thehaigo
2
1k
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.6k
Scaling GitHub
holman
458
140k
How GitHub (no longer) Works
holman
311
140k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Building Applications with DynamoDB
mza
90
6.1k
What's new in Ruby 2.0
geeforr
343
31k
Done Done
chrislema
181
16k
Ruby is Unlike a Banana
tanoku
96
11k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Gamification - CAS2011
davidbonilla
80
5k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
Transcript
2024年新⼈研修 コーディング研修 2024年4月25-26日
©2024 Aiming Inc. ガイダンス 講義について 1 • 座学と実習を交互に実施します。 • エンジニア採⽤の⽅、エンジニア以外の職種の⽅が混ざって
いますが、同じ内容を⼀緒におこないます。 • ⼀⼈でがんばる研修ではありません。 お互いにサポートしながら進めてください。 • この講義中は、⽣成 AI は使⽤しないでください。 ◦ ChatGPT, Copilot, Claude AI, Perplexity, ⾃分で構築した LLM の使⽤など
©2024 Aiming Inc. ⼀⽇⽬ • ガイダンス • Ruby の基礎 [休憩]
• チュートリアル課題 • チュートリアル課題フィードバック [昼休み] • コーディングに必要な知識について [休憩] • 演習課題 I ガイダンス コーディング研修 スケジュール 2 ⼆⽇⽬ • 演習課題 I の ピアレビューとフィードバック [休憩] • 開発プロセスについて アジャイル開発, TDD, リファクタリング [昼休み] • チーム開発 {ペア, モブ}プログラミングについて [休憩] • 演習課題 III [休憩] • 研修講評
©2024 Aiming Inc. ガイダンス ⼀⽇⽬ 3
©2024 Aiming Inc. ガイダンス ガイダンス 4
©2024 Aiming Inc. ガイダンス 講義のねらい 5 コーディングを中⼼として、Aiming の開発プロセスを知る エンジニア職の⽅ •
Aiming が採⽤している開発⼿法の採⽤意図を知る • 演習を通じて、なぜこういった⽅針を⼤事にしているのかを 体験から理解する エンジニア以外の職種の⽅ • エンジニア業務への理解を深める • エンジニアの開発⼿法へのこだわりの理由を体験から知る
©2024 Aiming Inc. ガイダンス 次の⽂章を読んで質問に答えてください 6
©2024 Aiming Inc. ある⾝分の低い男が、この男の他には誰もいない、た だ、塗装のはげた⼤きな円柱にキリギリスが⼀匹⽌ まっている広い⾨の下で、ある⽇の⼣暮れ時に⾬が⽌ むのを待っていた。 ガイダンス 7
©2024 Aiming Inc. ガイダンス この場所には何⼈いましたか 8
©2024 Aiming Inc. ガイダンス 時刻はいつですか 9
©2024 Aiming Inc. ガイダンス キリギリスはどこにいたでしょうか 10
©2024 Aiming Inc. ある⾝分の低い男が、この男の他には誰もいない、た だ、塗装のはげた⼤きな円柱にキリギリスが⼀匹⽌ まっている広い⾨の下で、ある⽇の⼣暮れ時に⾬が⽌ むのを待っていた。 ある⽇の暮⽅の事である。⼀⼈の下⼈が、羅⽣⾨の 下で⾬やみを待っていた。 広い⾨の下には、この男のほかに誰もいない。た
だ、所々丹塗の剥げた、⼤きな円柱に、蟋蟀が⼀匹と まっている。 https://www.aozora.gr.jp/cards/000879/files/127_15260.html ガイダンス 11
©2024 Aiming Inc. ガイダンス 次のコードを⾒て印象を教えてください 12
©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 [質問] どうしたら読みやすくなるでしょうか
©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 例えば
©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 例えば
©2024 Aiming Inc. ガイダンス 「良いコード」とはなんだと思いますか 16
©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード •
メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 17
©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード •
メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 18 どれも正解
©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード •
メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 19 どれも正解? ↓ ⽴場や状況 によって 変化する ?
©2024 Aiming Inc. • 処理速度が速いコード • 短いコード • わかりやすいコード •
メモリ使⽤量が少ないコード • 計算量が少ないコード • SOLID 原則を⼗分に考慮した設計がされているコード • シンプルな⼿続き型のスクリプト etc... ガイダンス 「良いコード」とはなんだと思いますか 20 ← まずはここから
©2024 Aiming Inc. ガイダンス Aiming が⾝を置いている環境 21 • モバイルオンラインゲーム ◦
競合増加 ◦ ⾼速な開発体制, 安定したサービスの提供, ゲームの⾯⽩さ • 開発規模の⼤きさ ◦ ex) とあるPJの開発規模 ◦ チーム開発, 開発の容易さ • アップデート開発 ◦ ⻑期間にわたって継続した機能追加が続く ◦ 開発の容易さ, 安定したサービスの提供
©2024 Aiming Inc. • モバイルオンラインゲーム ◦ 競合増加 ◦ ⾼速な開発体制, ゲームの⾯⽩さ,
安定したサービスの提供 • 開発規模の⼤きさ ◦ ex) とあるPJの開発規模 ◦ チーム開発, 開発の容易さ • アップデート開発 ◦ ⻑期間にわたって継続した機能追加が続く ◦ 追加開発の容易さ, 安定したサービス提供 ガイダンス Aiming が⾝を置いている環境 22
©2024 Aiming Inc. • チーム開発 ◦ 開発容易性 • 安定性の⾼いサービス提供 ◦
保守性 • アップデート開発 ◦ 拡張性 ガイダンス Aiming がやりたいこと 23
©2024 Aiming Inc. • チーム開発 ◦ 開発容易性 • 安定性の⾼いサービス提供 ◦
保守性 • アップデート開発 ◦ 拡張性 ガイダンス Aiming がやりたいこと 24 開発しやすく、保守性が高く、拡張性にも優れた 開発ができる体制
©2024 Aiming Inc. • ⽬指すところ ◦ Aiming に所属するエンジニアが誰でも理解できる コードを書くこと •
なぜなら ◦ チーム開発で、 ◦ バグやエラーが少なく、 ◦ 機能追加が容易な 開発をしたいから ガイダンス Aiming が⽬指すコーディングの指針 25
©2024 Aiming Inc. ガイダンス チーム開発 26
©2024 Aiming Inc. • 組織には様々なキャリアの⼈がいる ◦ OSS コミッター ◦ ベテラン,
中堅 ◦ ウェブ系など他業種からの転職 ◦ 情報系出⾝の新⼈ ◦ ゲーム学校出⾝の新⼈ ◦ グラフィックのスペシャリスト ◦ データベースのスペシャリスト etc. ガイダンス チーム開発におけるコーディング 27
©2024 Aiming Inc. • 組織には様々なキャリアの⼈がいる チーム開発は⼀つの⽬標に向かって助け合いながらゴール に進んでいくもの 「設計は難しくても、コードは書ける」 「コーディングしていない部分でも、レビューで助けることがで きる」
できる役割を少しずつ増やしましょう ガイダンス チーム開発におけるコーディング 28
©2024 Aiming Inc. • リーダーという役割 ◦ リーダーは役職ではなく、チームにおける役割 • (リーダーとは別に)リーダーシップはいたるところにある ◦
ex.) タスクを遂⾏する ▪ 実装して終わりではなく、デザイナー/企画を巻き込ん でゴールに向かう ◦ ex.) PR をマージできるようにする ▪ PR がなかなかマージされない ▪ なぜマージされないのか、問題解決のために⾏動する ガイダンス チーム開発におけるコーディング 29
©2024 Aiming Inc. • チーム開発 • コードレビュー • ペアプログラミング •
(OJT) ⾃分の書いたコードはいずれ誰かが⼿を加えるもの。 レビューをする⼈にも(意図的にしなかった⼈にも) そのコードへの責任がある。 ガイダンス チーム開発におけるコーディング 30 コードは個人のものではなく、チームのもの
©2024 Aiming Inc. ガイダンス コードの保守性, サービスの安定性 31
©2024 Aiming Inc. ⼀つのタイトルでの売上はどれくらい? • 1ヶ⽉あたり • 1⽇あたり • 1時間あたり
社内 KPI ツールで確認してみる ガイダンス コードの保守性, サービスの安定性 32
©2024 Aiming Inc. ガイダンス コードの保守性, サービスの安定性 33 非公開
©2024 Aiming Inc. 臨時メンテナンスが発⽣したら... • 機会損失額 = ダウンタイム × 売上⾒込み/h
• メンテナンスコスト = ダウンタイム × チーム⼈数 × ⼈件費/h • 問い合わせ、事後対応コスト ガイダンス コードの保守性, サービスの安定性 34
©2024 Aiming Inc. • ダウンタイム ◦ 売上への機会損失 ◦ ユーザの不満 ▪
ゲーム離れへのリスク ▪ 問い合わせコスト ◦ 不具合発⽣時の補填対応 ▪ 対応コスト ▪ 補填コスト ガイダンス コードの保守性, サービスの安定性 35
©2024 Aiming Inc. なぜダウンタイムが発⽣するか • 定期メンテナンス ◦ システムを停⽌するメンテナンスが不要な設計の検討 ▪ ex.)
blue/green deployment • 臨時メンテナンス ◦ バグの少ない開発 ◦ データ設定のミスが発⽣しない内部ツールやデータ管理システム • システム障害 ◦ 冗⻑設計 ◦ 早期の障害検知 ガイダンス コードの保守性, サービスの安定性 36
©2024 Aiming Inc. なぜダウンタイムが発⽣するか • 定期メンテナンス ◦ システムを停⽌するメンテナンスが不要な設計の検討 ▪ ex.)
blue/green deployment • 臨時メンテナンス ◦ バグの少ない開発 ◦ データ設定のミスが発⽣しない内部システム • システム障害 ◦ 冗⻑設計 ◦ 早期の障害検知 ガイダンス コードの保守性, サービスの安定性 37
©2024 Aiming Inc. • コードの保守性 ◦ 保守性 (maintainability) ▪ プログラムの継続動作
▪ プログラムの問題解消への容易さ ガイダンス コードの保守性, サービスの安定性 38
©2024 Aiming Inc. • コードの保守性 ◦ 保守性 (maintainability) ▪ プログラムの継続動作
▪ プログラムの問題解消への容易さ ガイダンス コードの保守性, サービスの安定性 39 サービス運用後も考慮した コーディング(設計)が大事
©2024 Aiming Inc. • コードの保守性 ◦ 保守性 (maintainability) ▪ プログラムの継続動作
▪ プログラムの問題解消への容易さ ガイダンス コードの保守性, サービスの安定性 40 サービス運用後も考慮した コーディング(設計)が大事 とはいえ、いきなりは難しいので、まずは経験のある人に支えてもらいましょう。 そのためのチーム開発です。
©2024 Aiming Inc. ガイダンス 追加開発への拡張性 41 開発ロードマップの公開 非公開
©2024 Aiming Inc. オンラインサービスはアップデートが前提 バグの状況もユーザに告知する リリースし、サービスを提供している以上、問題点は明らかにし て改善しなければならない • <告知へのリンク> ガイダンス
追加開発への拡張性 42
©2024 Aiming Inc. • PJ のアップデート計画を決めるためには ◦ 将来(1年後までなど⻑期)のマイルストーン策定 ◦ 仕様の決定タイミング
◦ 協業先との合意タイミング ◦ 開発完了タイミング ◦ QA フェーズの確保 ◦ ストアの審査期間 ◦ メンテナンス⽇の決定 etc… ガイダンス 追加開発への拡張性 43
©2024 Aiming Inc. ガイダンス 追加開発への拡張性 44 非公開 • スケジュール表
©2024 Aiming Inc. • アップデートを⾒越した開発は、実のところ難しい • 継続してサービスしているので状況次第で開発計画も変わり 得る • 経験が必要になる⾯は多分にある
ガイダンス 追加開発への拡張性 45
©2024 Aiming Inc. • アップデートを⾒越した開発は、実のところ難しい • 継続してサービスしているので状況次第で開発計画も変わり 得る • 経験が必要になる⾯は多分にある
ガイダンス 追加開発への拡張性 46 サービス運用後も考慮した コーディング(設計)が大事 とはいえ、いきなりは難しいので、まずは経験のある人に支えてもらいましょう。 そのためのチーム開発です。 再掲
©2024 Aiming Inc. • ⼈⼒で対応可能なことはたくさんある。まずは動くものを。 ただ、 • 積もり積もった⼈⼒対応は、いずれ莫⼤なコスト増になる ◦ ⼈件費
▪ ⼈員増, 残業, 深夜対応, 休⽇対応... ◦ ⼈的ミスによる損失 ▪ ⼿作業によるミスやチェックもれ, 疲労によるミス ガイダンス コスト意識 47
©2024 Aiming Inc. • ちょっとしたコードで解決することも プログラミングはエンジニアだけのものではない • 例えば、 ◦ Google
Apps Script で何か書いてみる ◦ 書籍: 退屈なことはPythonにやらせよう ◦ データ分析の SQL はプランナー、運営職が書くことも多い ◦ ChatGPT, GitHub Copilot ex.) 運営のスタッフがコードを書いている事例 ガイダンス コスト意識 48
©2024 Aiming Inc. • 今後、試験は存在しません ◦ 合格するための学習科⽬などの⽬標はありません ◦ 答えのない問題を解いていくのが業務内容(課題解決) ◦
⾃分で⾝につける内容を取捨選択する必要がある ◦ 何を学ぶかを選択するのも課題解決能⼒を磨くひとつ • 急ぐ必要はない ◦ ⼀つずつじっくりと ◦ わからなくても時間をおいて何度も咀嚼するのがおすすめ • 開発のすべてをできないと⼀⼈前ではないわけではない ◦ すでに現場では⼀⼈前の社員として扱われます ◦ できることからやっていきましょう ガイダンス 学習について 49
©2024 Aiming Inc. どうやって学習するか • 就業時間内で⼗分学習できる ◦ ⼀⽇ 8 時間、約
200 ⽇分の学びの機会がある ▪ 実装で考える、調査する ▪ コードレビューで知⾒を得る、質問する ▪ チームや社内の⼈に気軽に聞く ▪ 勉強会、輪読会を開催する(就業時間内で実施可能) ▪ 書籍購⼊(申請は上⻑に確認) ガイダンス 学習について 50
©2024 Aiming Inc. ガイダンス ガイダンスのまとめ 51
©2024 Aiming Inc. • 誰でも理解できるようなコーディングができるようになりま しょう • なぜなら ◦ チームで開発するから
◦ コードの保守性を⾼めたいから ◦ 安定したサービス運営をしたいから ガイダンス ガイダンスのまとめ 52
©2024 Aiming Inc. • 誰でも理解できるようなコーディングができるようになりま しょう • そのための武器をこれから⾝につけていきましょう ◦ 読みやすいコードの書き⽅
◦ ソフトウェア⼯学の基礎知識 ◦ チーム開発 について研修で理解を深めていきます。 ガイダンス ガイダンスのまとめ 53
©2024 Aiming Inc. ガイダンス ガイダンスおわり 54
©2024 Aiming Inc. • 誰でも理解できるようなコーディングができるようになりま しょう • ただし、研修ではすぐに役に⽴つ⼒は⾝につきません ◦ ⾃分で⼿を動かす
◦ ⾃分で考える ◦ なんでもやってみる ことを継続すること重要です ガイダンス ガイダンスのまとめ 55
©2024 Aiming Inc. Ruby の基礎 Ruby の基礎 56
©2024 Aiming Inc. 研修では Ruby を使います 基礎⽂法を駆け⾜で確認します ※ この講義では Ruby
を習得することが⽬的ではありません。 Ruby に関する問題はすぐに質問してください。 周囲の⼈にサポートを求めても構いません。 Ruby の基礎 Ruby の基礎 57
©2024 Aiming Inc. • 動的型付け⾔語 • リファレンスマニュアル ◦ https://docs.ruby-lang.org/ja/ •
チュートリアル ◦ https://www.ruby-lang.org/ja/documentation/quickstart Ruby の基礎 Ruby の基礎 58
©2024 Aiming Inc. FizzBuzz を出⼒してみよう FizzBuzz というゲーム プレイヤーは円状に座る。 最初のプレイヤーは「1」と数字を発⾔する。 次のプレイヤーは直前のプレイヤーの次の数字を発⾔していく。
ただし、 3で割り切れる場合は 「Fizz」 5で割り切れる場合は 「Buzz」 両者で割 り切れる場合は 「Fizz Buzz」 を数の代わりに発⾔しなければならない。 発⾔を間違えた者や、ためらった者は脱落となる。 http://ja.wikipedia.org/wiki/Fizz_Buzz Ruby の基礎 課題 59
©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
©2024 Aiming Inc. • ファイル名: tutorial/<your_name>/fizzbuzz.rb • main ブランチに push
せず、トピックブランチを作成し Pull Request を作成してください ◦ ブランチ名: <⾃分のアカウント>/tutorial ▪ ex.) ckazu/tutorial ◦ git 研修を思い出して! Ruby の基礎 課題 61
©2024 Aiming Inc. Ruby の基礎 提出課題のレビュー 62
©2024 Aiming Inc. お昼休憩 63
©2024 Aiming Inc. ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 64
©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • オブジェクト指向 ◦ SOLID 原則 ◦
デザインパターン • ソフトウェアアーキテクチャ • テスト技法 • リファクタリング技法 • ⾔語やライブラリのリファレンス ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 65
©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • オブジェクト指向, SOLID 原則, デザインパターン •
ソフトウェアアーキテクチャ • テスト技法 • リファクタリング これらをベーススキルとして、理解し使えるようになっていく。 学校の講義に出てくるだけのものではなく、エンジニアの業務上 で実際に使⽤するスキル。 ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 66
©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • ⾔語やライブラリのリファレンス これが⼀番の武器 ⾃分が使う技術の仕様(実装)を把握しておく • ex.)
⾔語仕様の理解 ⽂法だけではなく、すべての標準メソッドが把握できてい る、など • ex.) 使⽤ライブラリの実装把握 ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 67
©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 • ⾔語やライブラリのリファレンス • ⼀次ソースに当たる癖をつけるためにも、リファレンスを⾒ に⾏くようにするのが良い •
アップデートを追いリリースノートを読む習慣をつけるのも 良い • とりあえずググる、はしばらくやめてみるのがおすすめ ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 68
©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 2024 年の状況 • Copilot, ChatGPT などの⽣成系
AI は有効活⽤する これまで、レビューや書籍などから得ていた知識を超特急で⾝に つけることができるようになった。 最短で実践で通⽤するコードや知識の習得が可能なのでツールと して有効活⽤する。 ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 69
©2024 Aiming Inc. 「誰でも理解できる」コードを書くための武器 2024 年の状況 • Copilot, ChatGPT などの⽣成系
AI は有効活⽤する ただし、セキュリティには⼗分気をつける。 ChatGPT など(に限らず検索やウェブサービスなどでも)に、業 務上の機密情報や特定可能な情報は決して⼊⼒しないこと。 新⼈だから許される、ということはありません。 ex) ChatGPT, Google 検索, DeepL など ソフトウェア⼯学の知識 ソフトウェア⼯学の知識 70
©2024 Aiming Inc. ソフトウェア⼯学の知識 把握しておいてほしいトピック 71 本講義ではトピックを列挙するので、業務を通じて徐々に理解を 深めていってください。
©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 太字: 業務で使⽤されることのある⾔語
©2024 Aiming Inc. 現実のものや概念を「オブジェクト」として、プログラミングに 反映させる⽅法論 ソフトウェア⼯学の知識 オブジェクト指向プログラミング 73
©2024 Aiming Inc. • クラス ◦ オブジェクトの設計図のようなもの ◦ 属性 (フィールド)
と動作/機能 (メソッド) が定義される • オブジェクト ◦ クラスから⽣成されるインスタンス ▪ ex.)「⾞」という抽象的なクラスから「⾚い⾞」や「スポー ツカー」といった具体的なオブジェクトを⽣成 ◦ 実際のデータ(フィールドの値)と 動作/機能(メソッドの実⾏)をもつ ソフトウェア⼯学の知識 オブジェクト指向プログラミング 74
©2024 Aiming Inc. 3つの特性 • 継承 (inheritance) ◦ クラスの構造化。コードの再利⽤性の向上 •
カプセル化 (encapsulation) ◦ 外部からのアクセスを制限。データの安全性の確保 • ポリモーフィズム(多態性: polymorphism) ◦ overload, override により、オブジェクトの型に基づいて 異なる振る舞い(メソッド実⾏)を可能に ソフトウェア⼯学の知識 オブジェクト指向プログラミング 75
©2024 Aiming Inc. オブジェクト指向プログラミングの利点 • 直感的 ◦ 現実を模倣することで、直感的な設計ができる • 再利⽤性
◦ ⼀度作ったクラスを複数のコードで利⽤できる • 拡張可⽤性 ◦ 追加実装の際、実装量や既存コードの変更を少なくできる ソフトウェア⼯学の知識 オブジェクト指向プログラミング 76
©2024 Aiming Inc. プログラミングにおける⼀般的な問題に対する検証済みの解決策 • 効率的な開発 • コードの再利⽤ • 保守性の向上
ソフトウェア⼯学の知識 デザインパターン 77
©2024 Aiming Inc. Gang of Four (GoF) の 23 パターン
• ⽣成に関するパターン ◦ ex. Singleton, Factory Method • 構造に関するパターン ◦ ex. Facade, Proxy • 振る舞いに関するパターン ◦ ex. Observer, Strategy ソフトウェア⼯学の知識 デザインパターン 78 徐々に増やしていけば良い。 PJ やライブラリのコードを読んでいると、パター ンに出くわすことがよくあるので、一度ざっとさ らっておくと良い
©2024 Aiming Inc. • 新しい課題 ◦ クラウドサービス、モバイルアプリケーション、⼤規模 データ処理など、現代に即したパターンも ◦ ゲーム開発
=> https://gameprogrammingpatterns.com/ ex.) 依存性の注⼊ (DI: Dependency Injection) ◦ オブジェクトがその他のオブジェクトの 依存関係を⾃動で注⼊する ▪ ref. Spring Framework, Zenject(Extenject) など… ソフトウェア⼯学の知識 デザインパターン 79
©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
©2024 Aiming Inc. • 配属プロジェクトで採⽤されているアーキテクチャは? ◦ Unity のクライアント ◦ サーバサイド
◦ 開発⽤社内ウェブサービス ソフトウェア⼯学の知識 ソフトウェアアーキテクチャ 81
©2024 Aiming Inc. SOLID 原則 • オブジェクト指向設計のための5つの原則 • 可読性、再利⽤性、拡張性を向上させ、⾼い保守性や変更に 強いシステムを構築する
ソフトウェア⼯学の知識 ソフトウェア設計 82
©2024 Aiming Inc. SOLID 原則 • 単⼀責任の原則 (S: Single Responsibility
Principle) ◦ あるクラスは⼀つの責任だけを持つべき ▪ ex.) ログ記録とデータ処理を⼀つのクラスで⾏うのではなく、 それぞれの責任を持つクラスを分ける • 開放/閉鎖の原則 (O: Open/Closed Principle) ◦ 拡張に対して開かれ、変更に対して閉じられているべき ▪ ex.) 新しい機能を追加するために既存のコードを変更するので はなく、既存のコードに新しいコードを追加する形で拡張する ▪ 注) 既存コードの実装を変更してはいけない、のではなく、そ ういう⾵に設計しましょうという話 ソフトウェア⼯学の知識 ソフトウェア設計 83
©2024 Aiming Inc. SOLID 原則 • リスコフの置換原則 (L: Liskov Substitution
Principle) ◦ サブタイプは、そのスーパータイプと置換可能であるべき ▪ ex.) 「⾶ぶ」メソッドをもつ「⿃」クラスのサブクラスとして 「ペンギン」クラスは適当か? • 解決策1) 「⾶べる⿃」、「⾶べない⿃」の抽象クラスを使 ⽤ • 解決策2) 「⾶べる」というインタフェースを使⽤ • インターフェース分離の原則 (I: Interface Segregation Principle) ◦ クライアントは不必要なインターフェースに依存すべきではない ▪ ex.) ⼀つの汎⽤インターフェースよりも、特定のクライアント に必要なメソッドのみを提供する複数の特化したインター フェースを⽤意する ソフトウェア⼯学の知識 ソフトウェア設計 84
©2024 Aiming Inc. SOLID 原則 • 依存性逆転の原則 (D: Dependency Inversion
Principle) ◦ ⾼レベルのモジュールは低レベルのモジュールに依存すべきではな い。両者は抽象に依存すべき。 ▪ ⾼レベル: ビジネスルールを定義するモジュールなど ▪ 低レベル: データアクセスや、ユーティリティなど、具体的な実 装を提供するモジュール ソフトウェア⼯学の知識 ソフトウェア設計 85
©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) { // クエスト報酬としてアイテムを取得するロジック } }
©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); } }
©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 をモックに置き換えることで、統合テストやユニットテ ストが簡単になります。
©2024 Aiming Inc. ドメイン駆動設計 (DDD: Domain-Driven Design) • 現実の問題領域(ドメイン)を中⼼に、設計/開発を進めるアプロー チ
◦ 開発者はビジネスへの深い理解を元に現実世界の問題をモデリ ングする(ドメインモデル) ◦ 開発者と ビジネスのステークホルダーが協⼒ ソフトウェア⼯学の知識 ソフトウェア設計 89
©2024 Aiming Inc. ドメイン駆動設計のコンセプト • エンティティ (Entity) ⼀意の識別⼦を持つ、変化するドメインオブジェクト • 値オブジェクト
(Value Object) 識別⼦を持たず、属性のみで定義される不変のオブジェクト • 集約 (Aggregate) ⼀つのエンティティを主とし、関連オブジェクトを⼀つの単位として扱う • リポジトリ (Repository) 集約の永続化と再構築を管理する • ドメインサービス (Domain Service) エンティティや値オブジェクトを超えるドメインロジックを提供 • ユビキタス⾔語 (Ubiquitous Language) 開発チームとステークホルダーが共有するプロジェクト固有の⾔語 ソフトウェア⼯学の知識 ソフトウェア設計 90
©2024 Aiming Inc. • DRY (Don't Repeat Yourself.) • KISS
(Keep it Simple, stupid.) • YAGNI (You Ain't Gonna Need It.) • 驚き最⼩の原則 • 確証性バイアス • 銀の弾丸 • 計測せよ • コードの臭い • ⾞輪の再発明 ソフトウェア⼯学の知識 過去の⼈類の知⾒を知る ソフトウェア開発の原理原則/ベストプラクティス/アンチパターン 91 • 正常性バイアス • ドッグフーディング • 早すぎる最適化 • プログラマの三⼤美徳 • マジックナンバー • ヤクの⽑刈り • ラバーダッキング • 割れ窓理論 … 1年後, 2年後くらいに改めて読んでみると腹落ちするかも
©2024 Aiming Inc. ソフトウェア⼯学の知識 過去の⼈類の知⾒を知る 92
©2024 Aiming Inc. 実習1 実習1 93
©2024 Aiming Inc. https://github.com/foo/bar/baz/exam1 にあるファイルを修正し、次ページの要件を満たしてください • 最初に exam1 フォルダに⾃分のアカウント名のフォルダを作 成し、雛形のファイルをコピーしてください
• 成果物は GitHub のリポジトリに push してください • main ブランチに push せず、トピックブランチを作成し Pull Request を作成してください ◦ ブランチ名: <⾃分のアカウント>/exam1 ▪ ex.) ckazu/exam1 実習1 実習1 94
©2024 Aiming Inc. 雛形コードの解説 実習1 実習1 95
©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 の質問は随時してください • コミットの粒度もきちんと考えること
©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
©2024 Aiming Inc. 発展課題 1. 今のままでは、各レアリティで1種類のカードしか扱えませ ん。複数のカードを扱えるように拡張してください。 2. (ここまでで実装していない場合)外部から設定データを読 み込む機構を実装してください。
実習1 実習1 98
©2024 Aiming Inc. 発展課題2 1. 抽選確率が設定通りであろうことを検証する、確率集計ツー ルを作ってください。 ex.) 数万回試⾏した結果を集計して、設定確率との差異を表⽰ するなど。
ただし、本体のコードには⼿を⼊れず、新たにクラス実装を してください。 実習1 実習1 99
©2024 Aiming Inc. 開発プロセスについて ⼆⽇⽬ 100
©2024 Aiming Inc. • 他のメンバーの PR にレビューコメントを書いてください 各メンバーのコード、最低⼀箇所にコメントを残すこと ◦ 明らかな間違いの指摘
▪ バグ、仕様との差異など ◦ 別案の提案 ▪ 効率性、可読性などの観点から ◦ ⾃分が知らなかったところ ◦ 良いと思ったところ ◦ 質問 など 実習1 実習1のピアレビュー/講評 101
©2024 Aiming Inc. 開発プロセスについて 開発プロセスについて 102
©2024 Aiming Inc. 仕様をそのまま実装することが、⾯⽩いゲーム(良いサービス) を作ることにつながるだろうか 開発プロセスについて ゲーム開発 103
©2024 Aiming Inc. 仕様をそのまま実装することが、⾯⽩いゲーム(良いサービス) を作ることにつながるだろうか • 新しいゲーム要素を追加することで、全体の⾯⽩さが変化 • Try &
Error が重要 ◦ 作っては評価して変更していくことの繰り返し ◦ 作った機能を作り直すことも厭わない ◦ そのサイクルを何度も回していくことで、ゴールに近づ いていく 開発プロセスについて ゲーム開発 104
©2024 Aiming Inc. 1999 Extreme Programming (Kent Beck) • 従来の開発⼿法へのアンチテーゼ
• アジャイル開発⼿法の先駆け • XP におけるプラクティス • 共同: イテレーション、共通⾔語、共同作業、振り返り • 開発: TDD(テスト駆動開発: Test driven development ), ペア プロ, リファクタ, YAGNI, CI(continuous integration), コードの 共同化 • 管理者: 責任, 援護... • 顧客: ストーリー作成, 短期リリース... 開発プロセスについて XP 105
©2024 Aiming Inc. agile: 俊敏な、機敏な • 短い開発プロセスと顧客からのフィードバックの繰り返しに より、顧客の⽬的を達成 • 主なフレームワーク
◦ スクラム, カンバン, XP など • 注: これさえやっておけば良いという開発⼿法ではない 柔軟な対応をすることが重要 PJ やチームメンバー、開発フェーズに合わせたやり⽅を模索 し、改善することが必要 開発プロセスについて アジャイル開発 106
©2024 Aiming Inc. アジャイルマニフェスト https://agilemanifesto.org/iso/ja/manifesto.html 開発プロセスについて アジャイル開発 107
©2024 Aiming Inc. スクラム • プロダクトオーナー ◦ PJ のビジョン要件定義、優先順位の決定 •
スクラムマスター ◦ チームがスクラムのプロセスにしたがって作業できる よう⽀援する • チーム ◦ 実際に開発を⾏う、⾃⼰管理型のチーム 開発プロセスについて アジャイル開発 108
©2024 Aiming Inc. スクラムにおけるイベント • スプリント(イテレーション) ◦ 開発期間の単位 • デイリースクラム(スタンドアップミーティング)
◦ ⽇々の進捗の共有 • スプリントレビュー ◦ スプリントの最後に⾏う製品デモ フィードバックを得る • レトロスペクティブ ◦ 振り返り。改善点は次のスプリントに反映させる 開発プロセスについて アジャイル開発 109
©2024 Aiming Inc. • イテレーションを回すことの重要性 ◦ フィードバックの収集 ◦ リスクの低減 ◦
進⾏状況の明確化 ◦ モチベーション向上 • 不確実性コーン ◦ PJ 開始時には⾼い不確実性が、時間の経過とともに減 少していく ◦ 初期段階では未知な部分がとても⼤きい 開発プロセスについて アジャイル開発 110 小さなサイクルを回していくことでリスクを低減
©2024 Aiming Inc. 開発プロセスについて アジャイル開発 111
©2024 Aiming Inc. TDD: Test-Driven Development テストファースト • まず最初にテストコードを書く(注: 網羅しないこと)
◦ テストを失敗させる (red) • テストを通る実装を最速で⾏う (green) • テストが成功する状態を保ちながら、リファクタリン グを⾏う 開発プロセスについて テスト駆動開発 112
©2024 Aiming Inc. 最初にテストコードを書くことの利点 • テストコードは仕様である リファクタリングをすることの利点 • 「きれいな」コードにする テストコードがあることの利点
• リファクタリングが容易である • 保守性が確保できる 開発プロセスについて テスト駆動開発 113
©2024 Aiming Inc. BDD: Behavior Driven Development 振る舞い駆動開発 システムの振る舞いをテストコードで記述する •
TDD: 単体テスト • 仕様のテスト • BDD: 結合(受け⼊れ)テスト • 要件やユースケースに近い部分のテスト 開発プロセスについて テスト駆動開発 114
©2024 Aiming Inc. 「TDD と⻩⾦の回転」 https://speakerdeck.com/twada/tdd-live-in-50-minutes 開発プロセスについて テスト駆動開発 115
©2024 Aiming Inc. • 端的に⾔えば、コードや設計をきれいにする • 機能やインタフェースを変更せずに、内部実装を改善する 開発プロセスについて リファクタリング 116
©2024 Aiming Inc. なぜやるか • 保守性や拡張性の担保が⽬的 開発プロセスについて リファクタリング 117
©2024 Aiming Inc. いつやるか • 毎実装ごとにやる TDD の⽂脈で⾔えば、 毎回の実装の最初と最後にリファクタリングのフェーズがある 開発プロセスについて
リファクタリング 118
©2024 Aiming Inc. いつやるか • 毎実装ごとにやる TDD の⽂脈で⾔えば、 毎回の実装の最初と最後にリファクタリングのフェーズがある 機能追加の実装作業であれば、最初にリファクタリングを⾏うの
を勧めます 開発プロセスについて リファクタリング 119
©2024 Aiming Inc. いつやるか • 毎実装ごとにやる 機能追加のフェーズであれば、最初にリファクタリングを⾏う • コードに⼿を⼊れる前に⼿を⼊れやすくしておく •
テストがなければ(不⼗分であれば)追加する => 実装から時間が経っていると、状況が変化している事が多い 開発プロセスについて リファクタリング 120
©2024 Aiming Inc. • メソッドの抽出/クラスの分割 • マジックナンバーの除去 • 配列やハッシュから、オブジェクトへの変更 •
ポリモーフィズムの導⼊ • State/Strategy パターンへの変更 • 条件式のメソッド化 • 深いネストの解消 • フラグ処理の除去 など... 「何となくこっちが良さそう」、 ではなく、根拠を持ったリファクタリングを 開発プロセスについて リファクタリングの⼿法 121
©2024 Aiming Inc. Q. テストを書いたり、リファクタリングをしたりしていたら、開 発スピードは落ちないのか? A. 落ちない 最初は時間がかかる⾯は確かにある(慣れていない、チームのの コミュニケーション不⾜、ドメイン知識の不⾜など)。
ただ、継続した開発を続ければ続けるほど効いてくる。 逆に、テストコードがなかったり、まずい設計を残してしまう と、後でつけを払うことになる(技術的負債) 開発プロセスについて 疑問: 開発スピードへの危惧 122
©2024 Aiming Inc. • ゲーム開発 ◦ ⾯⽩くするために、常にコードは変更される ◦ 短いサイクルで改善 ◦
アジャイル開発の⼿法を取り⼊れる • コーディングにおけるトピック ◦ テスト⼤事 ◦ リファクタリング⼤事 ◦ どちらも、保守性、拡張性を担保するためのもの 開発プロセスについて まとめ 123
©2024 Aiming Inc. 開発プロセスについて 演習2 124
©2024 Aiming Inc. FizzBuzz を TDD で実装してみましょう テストフレームワーク https://github.com/seattlerb/minitest 開発プロセスについて
演習2: introduction 125
©2024 Aiming Inc. • 1 台の PC • 1 台の⼤きなディスプレイ
• 1 種類の⼊⼒デバイス を使い、 • 2 ⼈の⼈間が 実装作業をおこなう ペアプログラミング ペアプログラミング 126
©2024 Aiming Inc. • ⼀⼈がドライバー • もう⼀⼈がナビゲーター として、作業する お互い、考えていることを⼝に出しながら作業する。 意思疎通がなされて、作業の共通認識ができていること。
ペアプログラミング ペアプログラミング 127
©2024 Aiming Inc. ドライバー • キーボードを触り、コーディングを進める係。 • これからやろうとしていることは逐⼀⼝に出して共有する。 • 勝⼿に実装しない。⽅向性はナビゲーターに委ねる。
ナビゲーター • ドライバーは⽬の前のタイピングに意識を取られがちになる • 広い視野を持ち先読みをしてドライバーをナビゲートする • タイプミスなども指摘し無駄なはまり⽅をしないよう助ける ペアプログラミング ペアプログラミング 128
©2024 Aiming Inc. • ドライバーとナビゲーターは 10-15 分単位を⽬処に交代する • 想像以上に負荷が⾼いので、適度に休憩を挟むこと •
チームにおいては、ドライバーとナビゲーターのペアは、⼀ ⽇ごとに変更する、などの⽅策を取るのが良い ペアプログラミング ペアプログラミング 129
©2024 Aiming Inc. • 実装時間の短縮 • 品質の向上 • スキル、知識の共有 •
教育 • チームワークの向上 • コードの共有意識 ... ペアプログラミング ペアプログラミングの効果 130
©2024 Aiming Inc. • 必ずしも全員がペア作業を好むわけではない • 性格上、ペア作業に向かない⼈もいる • 共同作業をするための理解を得るのが難しいケースがある ペアプログラミング
ペアプログラミングの弱点 131
©2024 Aiming Inc. 組み合わせが効果的になる例 • 専⾨家 x 専⾨家 ◦ もっとも複雑な作業を成功させる
• 専⾨家 x ⼀般的なエンジニア ◦ ⼀般的なエンジニアのスキルアップ • 専⾨家 x 新⼈ ◦ トレーニング。⽐較的容易な課題の達成 • 新⼈ x 新⼈ ◦ 単純なタスクによって、双⽅のエンジニアが経験を積む ペアプログラミング ペアリング 132
©2024 Aiming Inc. • ペアプログラミング => 2 ⼈ • モブプログラミング
=> 3 ⼈以上 1 ⼈がドライバー(タイピスト) それ以外がナビゲーター(その他のモブ) モブプログラミング モブプログラミング 133
©2024 Aiming Inc. • ドライバーは 10-15 分単位で、他のナビゲーターと順に交代 していく • ペアプロよりも、よりやろうとしていることを共有していか
なければうまくいかない ホワイトボードなどを活⽤する • ⼈数が多いので横道にそれすぎないよう注意する ファシリテーターが別にいると良いケースも • 否定的なことは⾔わない モブプログラミング モブプログラミング 134
©2024 Aiming Inc. • 期待する効果はペアプロと同様 ◦ 品質の向上 ◦ 知識の共有 ▪
など • プログラミングだけではない場⾯にも ◦ コードのペアレビュー、モブレビュー ◦ 仕様の確認 ◦ エンジニア以外のチームでも ◦ … モブプログラミング モブプログラミング 135 その時のチームに合わせたやり方を模索しましょう
©2024 Aiming Inc. 開発プロセスについて 演習3 136
©2024 Aiming Inc. モブプログラミングで課題を実装してください • ドライバーの順番は今ここで抽選します • この演習でのルール ◦ 15
分経過したら、速やかにドライバーを交代してください ◦ 作業途中であってもその時点の状態をコミットすることと します ◦ 切りの良いタイミングでのコミットもおこなってください 開発プロセスについて 演習3 137
©2024 Aiming Inc. • ドライバー ◦ 操作しようとしていること、悩んでいることを常に発話し てください ◦ ⾃分の考えで実装を進めてはいけません
• ナビゲーター ◦ ドライバー以外は全員ナビゲーターです ◦ 気がついたことを積極的に発⾔してください ◦ ナビゲーターの道標がないとドライバーは作業できません • ホワイトボードも活⽤しましょう 開発プロセスについて 演習3 138
©2024 Aiming Inc. • ナビゲーターが個⼈の PC やスマホで勝⼿に調べないこと ◦ PC を操作できるのはドライバーだけです
◦ 調査したいことがあれば、指⽰をして全員で共有している 状態で調査します • この演習では⼿分けして作業するという⾏為は禁⽌します ※ 演習の⽬的は、より良い実装をすることよりも、チーム開発の 実感を得ることです。 相談しながら協⼒してチームで作業を進め、課題を解決してくだ さい。 開発プロセスについて 演習3 139
©2024 Aiming Inc. • 最初に 15 分間、課題について実装の進め⽅や設計⽅針などを 相談する時間を設けます。 • 15
分間 x n ⼈ x 2 回 = h 時間で実装してください • タイムキーパーは講師が担当します • 随時休憩をはさみます • git を活⽤して、適宜 commit などしてください 開発プロセスについて 演習3 140
©2024 Aiming Inc. /exam3/master_data にガチャの抽選テーブルのデータが格納さ れています。 このデータをもとに、いくつかの種類のガチャを実装してくださ い。 演習2の実装は⼀旦忘れて、今回の仕様に合わせたより良い設計 を検討してください。
開発プロセスについて 演習3: 課題 141
©2024 Aiming Inc. • プレミアムガチャを実装してください ◦ 排出物の情報は確率以外すべて出⼒すること • ノーマルガチャを実装してください •
ドラゴン種族の排出確率が2倍になるドラゴンガチャを実装してく ださい。ノーマルガチャのテーブルをベースとします • 特定のキャラクターの排出確率が10倍になるピックアップガチャを 実装してください。ノーマルガチャのテーブルをベースとします ▪ ピックアップ: xxx, xxx, xxx 開発プロセスについて 演習3: 課題-1 142
©2024 Aiming Inc. • すべてのガチャで回数を指定して実⾏(最⼤10回)できるように してください 1-10 回以外はエラーとし、実⾏できないようにしてください • プレミアムガチャの10回連続実⾏では、最後の⼀回では
SR, UR が必ず排出されるようにしてください 確率はプレミアムガチャに準じます ※ プレミアムドラゴンガチャは対象外です 開発プロセスについて 演習3: 課題-2 143
©2024 Aiming Inc. • 排出されたログをファイルに記録してください ◦ ⽇時 ◦ ガチャ種別 ◦
排出物 ◦ (連続実⾏の場合)排出順 開発プロセスについて 演習3: 課題-3 144
©2024 Aiming Inc. • ボックスガチャを実装してください ◦ ボックスガチャの排出状況は内部メモリで管理せず、外部に永 続化して管理すること 開発プロセスについて 演習3:
発展課題 145
©2024 Aiming Inc. • (テストコードが存在しない場合)テストコードを追加してくだ さい • 全ての要件を踏まえて、現在の実装のコード設計を議論してくだ さい ◦
議論を元にコード設計を再度おこなって、リファクタリング に取り組んでください 開発プロセスについて 演習3: 発展課題 146
©2024 Aiming Inc. 参考⽂献 147
©2024 Aiming Inc. コーディング研修 完 148