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
49
リニューアルで学んだ通説の捉え方
「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
LINEヤフーのウェブアクセシビリティ
lycorptech_jp
PRO
1
88
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
8
710
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
7
4k
Yahoo! 知恵袋フロントエンドをリアーキテクトしている話
lycorptech_jp
PRO
7
3.2k
UIコンポーネント Vue3マイグレーション体験記
lycorptech_jp
PRO
0
250
スタンプショップの推薦枠に2-stage制を導入した事例紹介
lycorptech_jp
PRO
1
130
Head toward Java 22 and Java 23
lycorptech_jp
PRO
1
190
データ品質をコード化! LINEヤフーのMLOpsを最適化する "ACP Data Quality" の紹介
lycorptech_jp
PRO
5
1.2k
年度末の振り返り!テクニカルライターは成果をどうアピールすべきか
lycorptech_jp
PRO
1
77
Other Decks in Technology
See All in Technology
cgroup v2 で何が変わったのか / TechFeed Experts Night #28
tenforward
2
150
知識と実践を紡ぐGenAI / Connecting Knowledge and experience with GenAI
aki_moon
2
160
株式会社EventHub・エンジニア採用資料
eventhub
0
2.1k
PHP 9 に備えよ - 動的プロパティ、どうすればいぃ?
taisukearase
0
150
試作とデモンストレーション / Prototyping and Demonstrations
ks91
PRO
0
160
5分で分かる(かもしれない) Vector engine for OpenSearch Serverless
tsukuboshi
1
380
エムスリーQAチーム紹介資料 / Introduction of M3 QA Team
m3_engineering
1
290
ハードウェアを動かすTypeScriptの世界
9wick
3
1.2k
TypescriptでのContextualな構造化ロギングと社内全体への導入
leveragestech
3
560
エンジニアゼロの組織から内製開発の DX をどう実現したのか / How did we achieve DX in in-house development in an organization with zero engineers?
genkiogasawara
6
2.6k
CockroachDB はどのくらい「しぶとい」のか? / How tough is CockroachDB?
kota2and3kan
13
4.9k
類似ロジック実装をiOS/Android間で合わせる道標No.1
fumiyasac0921
1
220
Featured
See All Featured
Robots, Beer and Maslow
schacon
PRO
155
8k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
A Tale of Four Properties
chriscoyier
153
22k
For a Future-Friendly Web
brad_frost
172
9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
126
32k
Designing on Purpose - Digital PM Summit 2013
jponch
111
6.5k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
228
16k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
275
13k
[RailsConf 2023] Rails as a piece of cake
palkan
28
4k
How GitHub Uses GitHub to Build GitHub
holman
468
290k
Build The Right Thing And Hit Your Dates
maggiecrowley
25
2k
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!