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
リニューアルで学んだ通説の捉え方
Search
LY Corporation Tech
PRO
December 15, 2023
Technology
0
61
リニューアルで学んだ通説の捉え方
「UIT × Bonfire Front-end Meetup #1」の発表資料です。
https://uit.connpass.com/event/300284/
LY Corporation Tech
PRO
December 15, 2023
Tweet
Share
More Decks by LY Corporation Tech
See All by LY Corporation Tech
年間一億円削減した時系列データベースのアーキテクチャ改善~不確実性の高いプロジェクトへの挑戦~
lycorptech_jp
PRO
3
2.9k
大規模Hive-Trino移行PJの事例紹介
lycorptech_jp
PRO
2
160
Trinoの長期運用から学んだこと
lycorptech_jp
PRO
2
310
Secure and Private Federated Learning with Differential Privacy
lycorptech_jp
PRO
2
120
Kotlin Fest 2024 - Pocket Code Battle 問題解説
lycorptech_jp
PRO
2
40
差分プライバシー入門
lycorptech_jp
PRO
2
160
Adopting ZGC in HBase for LINE Messaging
lycorptech_jp
PRO
2
790
Web UIの黄金時代 - WebとCSSの最新アップデート
lycorptech_jp
PRO
2
80
Exploit the smart speaker at Pwn2Own
lycorptech_jp
PRO
1
88
Other Decks in Technology
See All in Technology
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
210
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
opelab
10
4.3k
[I/O Extended Android 2024] What`s new in Android 2024
kyeongwan
0
220
20240717_イケコパ代表Copilot_in_Teams会社でこう使ってます
ponponmikankan
2
430
AOAI Dev Day LLMシステム開発 Tips集
hirosatogamo
15
3.7k
データ分析を支える技術 生成AI再入門
ishikawa_satoru
0
380
How to Think Like a Performance Engineer
csswizardry
4
590
フルリモートワークはエンジニアの夢を叶えたか? #cm_odyssey
mamohacy
2
600
Azure Pipelinesを使用したCICDベースラインアーキテクチャ実践
yuriemori
0
190
たくさん本を読んだけど 1年後には綺麗サッパリ!を乗り越えて 学習の鬼になるぞ👹
yum3
0
160
Git 研修 Basic【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
310
初中級者用如何使用backlog -VALE TUDOEDITION-
in0u
0
140
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.5k
Large-scale JavaScript Application Architecture
addyosmani
506
110k
Fireside Chat
paigeccino
25
2.8k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
23
1.9k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
149
45k
From Idea to $5000 a Month in 5 Months
shpigford
377
46k
Docker and Python
trallard
37
2.9k
Become a Pro
speakerdeck
PRO
15
4.8k
Why Our Code Smells
bkeepers
PRO
332
56k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
189
16k
Transcript
© LY Corporation LINEヤフー コミュニケーションカンパニー LY会員サービス統括本部 開発本部 PIM開発 ⻑内 創太郎(Osanai
Sotaro) リニューアルで学んだ通説の捉え⽅
© LY Corporation ⾃⼰紹介 ⻑内 創太郎(Osanai Sotaro) 2 ヤフーに2021年新卒⼊社 Yahoo!メールのWebチームでFE,
BEを実装 2023年10⽉からLINEヤフー所属 ü Vim ü デュアルキーボード ü バドミントン
© LY Corporation Agenda 01. リニューアル概要 ・変更点(システム構成, 使⽤技術) ・変更点(UI, UX)
・リニューアルする理由 02. リニューアルスケジュール ・元々予定していたスケジュール ・実際のスケジュール 03. リニューアル結果 ・パフォーマンス ・反響 04. 苦労したこと ・実装 ・テスト ・⼯数 05. 学んだこと 06. まとめ できるエンジニアになるために 3 ・実装 ・テスト ・⼯数
© LY Corporation Agenda 01. リニューアル概要 ・変更点(システム構成, 使⽤技術) ・変更点(UI, UX)
・リニューアルする理由 02. リニューアルスケジュール ・元々予定していたスケジュール ・実際のスケジュール 03. リニューアル結果 ・パフォーマンス ・反響 04. 苦労したこと ・実装 ・テスト ・⼯数 05. 学んだこと 06. まとめ できるエンジニアになるために 4 ・実装 ・テスト ・⼯数
© LY Corporation リニューアル概要 SP(SmartPhone)版Web Yahoo!メールの技術刷新 5 SP版Web Yahoo!メール ・ユーザ数:
約800万MAU ・遷移元 ・検索結果から ・Web版Yahoo!Topから ・Yahoo!Topアプリから ・⼀部Yahoo!メールアプリ内から
© LY Corporation ・jQuery ・PHP ・Apache ・Kubernetes ・React, Redux AsyncThunk
・Nginx ・Kubernetes 6 システム構成/使⽤技術 リニューアル概要 jQuery React Redux (AsyncThunk) リニューアル前 リニューアル後
© LY Corporation ・jQuery ・PHP ・Apache ・Kubernetes ・React, Redux AsyncThunk
・Nginx ・Kubernetes 7 システム構成/使⽤技術 リニューアル概要 React Redux (AsyncThunk) リニューアル前 リニューアル後 jQuery ⾮同期のactionを作成できる → 処理中やエラー時の書き⽅が簡潔に ・ action.fulfilled ・action.pending ・ action.rejected
© LY Corporation リニューアル前 • 受信箱、下書き等を トップに配置 リニューアル後 • スマートカテゴリー機能を
追加 • ⽂⾔の追加や変更 • ⼤きな変更なし 8 UI, UX(トップ⾯) リニューアル概要
© LY Corporation リニューアル前 • 項⽬と説明を載せる • チェック項⽬も前⾯に リニューアル後 •
項⽬のみを表⽰ • アプリに寄せてUI/UX統⼀ 9 UI, UX(設定画⾯) リニューアル概要
© LY Corporation リニューアル前 • 左端に常時タブを表⽰ • きせかえテーマ設定が できない リニューアル後
• チェックボックスを表⽰ • Yahoo!メール⼀覧と 似たデザインに • きせかえテーマ適⽤ 10 UI, UX(連絡先の統合) リニューアル概要
© LY Corporation リニューアル概要 リニューアルした訳 11 1. PHPが社内で準標準プログラミング⾔ 語になった •
社内ライブラリ等のサポートもな くなる 2. PHPに詳しいエンジニアがチーム内に 少ない • 新機能追加やバグ修正に時間がか かる • 保守・運⽤コストも⾼い • PC版Webで使⽤実績のあるReact, Reduxを使⽤ • サーバサイド処理の必要な箇所はチー ムで管理している既存サーバに処理を 追加
© LY Corporation Agenda 01. リニューアル概要 ・変更点(システム構成, 使⽤技術) ・変更点(UI, UX)
・リニューアルする理由 02. リニューアルスケジュール ・元々予定していたスケジュール ・実際のスケジュール 03. リニューアル結果 ・パフォーマンス ・反響 04. 苦労したこと ・実装 ・テスト ・⼯数 05. 学んだこと 06. まとめ できるエンジニアになるために 12 ・実装 ・テスト ・⼯数
© LY Corporation リニューアルスケジュール(Kick off時) 13 Kick off 外部設計完成 開発開始
リリース
© LY Corporation リニューアルスケジュール(Kick off時) 14 Kick off 外部設計完成 開発開始
リリース 開発開始が1年ずれた Kick offから3年8ヶ⽉後に リリース完了
© LY Corporation リニューアルスケジュール(Kick off時) 15 Kick off 外部設計完成 開発開始
リリース 開発開始が1年ずれた Kick offから3年8ヶ⽉後に リリース完了 PC版リニューアル 実装 他チームヘルプのため 開発ストップ 開発再開 PM引き継ぎ
© LY Corporation Agenda 01. リニューアル概要 ・変更点(システム構成, 使⽤技術) ・変更点(UI, UX)
・リニューアルする理由 02. リニューアルスケジュール ・元々予定していたスケジュール ・実際のスケジュール 03. リニューアル結果 ・パフォーマンス ・反響 04. 苦労したこと ・実装 ・テスト ・⼯数 05. 学んだこと 06. まとめ できるエンジニアになるために 16 ・実装 ・テスト ・⼯数
© LY Corporation リニューアル結果 17 • Redux Toolkitを使⽤していても⼤きく 落ちることはなかった •
新機能開発や保守がしやすくなった パフォーマンス/DX • ユーザへの告知はなかったが特に⼤き な反響はなし • 多かった反響 • 「スマートカテゴリー」機能が追 加された (数件) • 広告が全⾯に出てしまう(スマホ の処理能⼒に関連)(数件) • デザインが変わった(数件) • etc… • 「すごく早くなった」等の嬉しい意⾒ も 反響 リニューアル前 リニューアル後
© LY Corporation リニューアル結果 18 • Redux Toolkitを使⽤していても⼤きく 落ちることはなかった •
新機能開発や保守がしやすくなった パフォーマンス/DX • ユーザへの告知はなかったが特に⼤き な反響はなし • 多かった反響 • 「スマートカテゴリー」機能が追 加された (6件) • 広告が前⾯に出てしまう(スマホ の処理能⼒に関連)(8件) • デザインが変わった(5件) • etc… • 「すごく早くなった」等の嬉しい意⾒ も 反響 リニューアル前 リニューアル後 ・起動時の⾮同期処理の⾒直し ・データ量の多いライブラリの⾃作 ・lazyImportの導⼊ (参考: https://github.com/facebook/react/issues/14603#issuecomment- 726551598)
© LY Corporation リニューアル結果 19 • Redux Toolkitを使⽤していても⼤きく 落ちることはなかった •
新機能開発や保守がしやすくなった パフォーマンス/DX 反響 リニューアル前 リニューアル後 • ユーザへの告知はなかったが特に⼤き な反響はなし • 多かった反響 • 「スマートカテゴリー」機能が追 加された (数件) • 広告が全⾯に出てしまう(スマホ の処理能⼒に関連)(数件) • デザインが変わった(数件) • etc… • 「すごく早くなった」等の嬉しい意⾒ も
© LY Corporation リニューアル前 • 受信箱、下書き等を トップに配置 リニューアル後 • スマートカテゴリー機能を
追加 • ⽂⾔の追加や変更 • ⼤きな変更なし 20 UI, UX(トップ⾯) リニューアル概要
© LY Corporation リニューアル結果 21 • Redux Toolkitを使⽤していても⼤きく 落ちることはなかった •
新機能開発や保守がしやすくなった パフォーマンス/DX 反響 リニューアル前 リニューアル後 • ユーザへの告知はなかったが特に⼤き な反響はなし • 多かった反響 • 「スマートカテゴリー」機能が追 加された (数件) • 広告が全⾯に出てしまう(スマホ の処理能⼒に関連)(数件) • デザインが変わった(数件) • etc… • 「すごく早くなった」等の嬉しい意⾒ も
© LY Corporation Agenda 01. リニューアル概要 ・変更点(システム構成, 使⽤技術) ・変更点(UI, UX)
・リニューアルする理由 02. リニューアルスケジュール ・元々予定していたスケジュール ・実際のスケジュール 03. リニューアル結果 ・パフォーマンス ・反響 04. 苦労したこと ・実装 ・テスト ・⼯数 05. 学んだこと 06. まとめ できるエンジニアになるために 22 ・実装 ・テスト ・⼯数
© LY Corporation 苦労したこと 23 • 詳細設計がないためコードが仕様状態 • PHPに不慣れで仕様の把握に時間がか かる
• リニューアル前のサーバーサイド処理 をどうするか? • サービス使⽤中のリニューアル版への 切り替え⽅法 実装 • ⼯数の算出⽅法 • ⼈によって異なる1⼈⽇ • ⾜りない⼯数 ⼯数 • 実機でしか再現しないバグ • 特定のバージョンでしか再現しないバグ • 遷移の煩雑さ • ⾃動テストの少なさ • ⼿動テストの多さ テスト
© LY Corporation 苦労したこと 24 実装 実装 • ⼯数の算出⽅法 •
⼈によって異なる1⼈⽇ • ⾜りない⼯数 ⼯数 • 実機でしか再現しないバグ • 特定のバージョンでしか再現しないバグ • 遷移の煩雑さ • ⾃動テストの少なさ • ⼿動テストの多さ テスト • 有識者に聞く • 既存サーバーに処理を追加 • 体験に違和感がないよう、URLパラメータ なども考慮 • 詳細設計がないためコードが仕様状態 • PHPに不慣れで仕様の把握に時間がか かる • リニューアル前のサーバーサイド処理 をどうするか? • サービス使⽤中のリニューアル版への 切り替え⽅法
© LY Corporation 苦労したこと 25 • 詳細設計がないためコードが仕様状態 • PHPに不慣れで仕様の把握に時間がか かる
• リニューアル前のサーバーサイド処理 をどうするか? • サービス使⽤中のリニューアル版への 切り替え⽅法 実装 • ⼯数の算出⽅法 • ⼈によって異なる1⼈⽇ • ⾜りない⼯数 ⼯数 • 実機でしか再現しないバグ • 特定のバージョンでしか再現しないバグ • 遷移の煩雑さ • ⾃動テストの少なさ • ⼿動テストの多さ テスト
© LY Corporation 苦労したこと 26 • 詳細設計がないためコードが仕様状態 • PHPに不慣れで仕様の把握に時間がか かる
• リニューアル前のサーバーサイド処理 をどうするか? • サービス使⽤中のリニューアル版への 切り替え⽅法 実装 • ⼯数の算出⽅法 • ⼈によって異なる1⼈⽇ • ⾜りない⼯数 ⼯数 • 実機でしか再現しないバグ • 特定のバージョンでしか再現しないバグ • 遷移の煩雑さ • ⾃動テストの少なさ • ⼿動テストの多さ テスト • XcodeのSimulatorや実機を使⽤してデバッグ • 統合テストで確認 • ⼿動テストでカバー • テストメンバー追加
© LY Corporation 苦労したこと 27 • 詳細設計がないためコードが仕様状態 • PHPに不慣れで仕様の把握に時間がか かる
• リニューアル前のサーバーサイド処理 をどうするか? • サービス使⽤中のリニューアル版への 切り替え⽅法 実装 • ⼯数の算出⽅法 • ⼈によって異なる1⼈⽇ • ⾜りない⼯数 ⼯数 • 実機でしか再現しないバグ • 特定のバージョンでしか再現しないバグ • 遷移の煩雑さ • ⾃動テストの少なさ • ⼿動テストの多さ テスト
© LY Corporation 苦労したこと 28 • 詳細設計がないためコードが仕様状態 • PHPに不慣れで仕様の把握に時間がか かる
• リニューアル前のサーバーサイド処理 をどうするか? • サービス使⽤中のリニューアル版への 切り替え⽅法 実装 • ⼯数の算出⽅法 • ⼈によって異なる1⼈⽇ • ⾜りない⼯数 ⼯数 • 実機でしか再現しないバグ • 特定のバージョンでしか再現しないバグ • 遷移の煩雑さ • ⾃動テストの少なさ • ⼿動テストの多さ テスト • ⻑内の匙加減で⼯数算出 • 実装⼒のあるメンバーだったので巻いてくれた • メンバーを追加
© LY Corporation Agenda 01. リニューアル概要 ・変更点(システム構成, 使⽤技術) ・変更点(UI, UX)
・リニューアルする理由 02. リニューアルスケジュール ・元々予定していたスケジュール ・実際のスケジュール 03. リニューアル結果 ・パフォーマンス ・反響 04. 苦労したこと ・実装 ・テスト ・⼯数 05. 学んだこと 06. まとめ できるエンジニアになるために 29 ・実装 ・テスト ・⼯数
© LY Corporation 学んだこと 30 • パッケージサイズは要注意 • 特にSP上で動作する場合 •
構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 テスト ※ あくまで主観です • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する • 後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする
© LY Corporation 学んだこと 31 • パッケージサイズは要注意 • 特にSP上で動作する場合 •
構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 テスト ※ あくまで主観です ReduxはSP上でサクサク動かない • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する • 後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする
© LY Corporation • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する •
後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする 学んだこと 32 • パッケージサイズは要注意 • 特にSP上で動作する場合 • 構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 テスト ※ あくまで主観です 確かに気になる点はあったが 実際は普通に動いた ReduxはSP上でサクサク動かない
© LY Corporation 学んだこと 33 • パッケージサイズは要注意 • 特にSP上で動作する場合 •
構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する • 後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする テスト ※ あくまで主観です
© LY Corporation 学んだこと 34 • パッケージサイズは要注意 • 特にSP上で動作する場合 •
構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 テスト ※ あくまで主観です ⾃動テスト書いてない とかありえない • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する • 後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする
© LY Corporation 学んだこと 35 • パッケージサイズは要注意 • 特にSP上で動作する場合 •
構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 テスト ※ あくまで主観です ⾃動テスト書いてない とかありえない BEはそうかもしれないが FEでは⼿動テストが結構 ⼤事 • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する • 後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする
© LY Corporation 学んだこと 36 • パッケージサイズは要注意 • 特にSP上で動作する場合 •
構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する • 後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする テスト ※ あくまで主観です
© LY Corporation 学んだこと 37 • パッケージサイズは要注意 • 特にSP上で動作する場合 •
構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 テスト ※ あくまで主観です 「遅れているソフトウェアプロジェクトへの要員 追加は、プロジェクトをさらに遅らせるだけであ る」という、ソフトウェア開発のプロジェクトマ ネジメントに関する法則である。(※1) → 炎上PJに増員するな ※1: https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87 • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する • 後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする
© LY Corporation • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する •
後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする 学んだこと 38 • パッケージサイズは要注意 • 特にSP上で動作する場合 • 構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 テスト ※ あくまで主観です ※1: https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87 ・それぞれのプロジェクトや⼯程において 割り当てるのに適切な⼯数はある (それを知る術はないが近づけることはできる) ・⼿動テストは⾮同期に実⾏できるので 割り当てられる⼯数の上限は⾼い (ドメイン知識のある⼈であればなおさら) 「遅れているソフトウェアプロジェクトへの要員 追加は、プロジェクトをさらに遅らせるだけであ る」という、ソフトウェア開発のプロジェクトマ ネジメントに関する法則である。(※1) → 炎上PJに増員するな
© LY Corporation • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する •
後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする 学んだこと 39 • パッケージサイズは要注意 • 特にSP上で動作する場合 • 構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 テスト ※ あくまで主観です 確かに気になる点はあったが 実際は普通に動いた ReduxはSP上でサクサク動かない ⾃動テスト書いてない とかありえない BEはそうかもしれないが FEでは⼿動テストが結構 ⼤事 ・それぞれのプロジェクトや⼯程において 割り当てるのに適切な⼯数はある (それを知る術はないが近づけることはできる) ・⼿動テストは⾮同期に実⾏できるので 割り当てられる⼯数の上限は⾼い (ドメイン知識のある⼈であればなおさら) 「遅れているソフトウェアプロジェクトへの要員 追加は、プロジェクトをさらに遅らせるだけであ る」という、ソフトウェア開発のプロジェクトマ ネジメントに関する法則である。(※1) → 炎上PJに増員するな
© LY Corporation • ⾃動テストは⼤事だが⼿動テストも結構⼤事 • 特にFE領域は保守性との兼ね合い • ⾃動テストの導⼊は早めに検討する •
後回しにすると書かない可能性が⾼い • ⾃動テストがないとリファクタリングしづら いので導⼊しよう • テストコードを書く⽂化作りをする 学んだこと 40 • パッケージサイズは要注意 • 特にSP上で動作する場合 • 構造改善や影響範囲の⼤きい修正は早 めに実施する • ⼤規模テスト後は影響範囲の⼤き い修正がしづらい 実装 • ⼈が増えるとプロジェクトの進みが早 くなった • ブルックスの法則は成り⽴たな い? • ⼯数は曖昧 → ⼯数に固執しない • ⾒積もりの難しさ ⼯数 テスト ※ あくまで主観です 確かに気になる点はあったが 実際は普通に動いた ReduxはSP上でサクサク動かない ⾃動テスト書いてない とかありえない BEはそうかもしれないが FEでは⼿動テストが結構 ⼤事 ・それぞれのプロジェクトや⼯程において 割り当てるのに適切な⼯数はある (それを知る術はないが近づけることはできる) ・⼿動テストは⾮同期に実⾏できるので 割り当てられる⼯数の上限は⾼い (ドメイン知識のある⼈であればなおさら) 「遅れているソフトウェアプロジェクトへの要員 追加は、プロジェクトをさらに遅らせるだけであ る」という、ソフトウェア開発のプロジェクトマ ネジメントに関する法則である。(※1) → 炎上PJに増員するな 過信していた
© LY Corporation Agenda 01. リニューアル概要 ・変更点(システム構成, 使⽤技術) ・変更点(UI, UX)
・リニューアルする理由 02. リニューアルスケジュール ・元々予定していたスケジュール ・実際のスケジュール 03. リニューアル結果 ・パフォーマンス ・反響 04. 苦労したこと ・実装 ・テスト ・⼯数 05. 学んだこと 06. まとめ できるエンジニアになるために 41 ・実装 ・テスト ・⼯数
© LY Corporation 42 まとめ あなたも疑わずに信じてしまっていることはありませんか? ⾃分の⽬で⾒て経験して試⾏錯誤して、できるエンジニアに!
© LY Corporation Thank You!