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
47
リニューアルで学んだ通説の捉え方
「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
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
8
680
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
7
3.9k
Yahoo! 知恵袋フロントエンドをリアーキテクトしている話
lycorptech_jp
PRO
6
3.1k
UIコンポーネント Vue3マイグレーション体験記
lycorptech_jp
PRO
0
220
スタンプショップの推薦枠に2-stage制を導入した事例紹介
lycorptech_jp
PRO
1
120
Head toward Java 22 and Java 23
lycorptech_jp
PRO
1
180
データ品質をコード化! LINEヤフーのMLOpsを最適化する "ACP Data Quality" の紹介
lycorptech_jp
PRO
5
1.2k
年度末の振り返り!テクニカルライターは成果をどうアピールすべきか
lycorptech_jp
PRO
1
72
差分プライバシーによる 安全な連合学習の実現
lycorptech_jp
PRO
5
1k
Other Decks in Technology
See All in Technology
IaCジェネレーターとBedrockで詳細設計書を生成してみた
tsukasa_ishimaru
4
940
LangSmith入門―トレース/評価/プロンプト管理などを担うLLMアプリ開発プラットフォーム
os1ma
5
780
Microsoft Intune 勉強会 第 2 回目
tamaiyutaro
2
510
今年のRubyKaigiはProfiler Year🤘
osyoyu
0
510
Documentação de Produtos: Artefatos essenciais na prática
rigolon
1
200
自己改善からチームを動かす! 「セルフエンジニアリングマネージャー」のすゝめ
shoota
6
1.1k
プロンプトエンジニアリングでがんばらない-Agentic Workflow へ-近藤憲児
kenjikondobai
6
1.3k
AWSに詳しくない人でも始められるコスト最適化ガイド
yuhta28
2
410
Grafana x PagerDuty Better Together
jacopen
1
330
CockroachDB はどのくらい「しぶとい」のか? / How tough is CockroachDB?
kota2and3kan
6
3.7k
kcp: Kubernetes APIs Are All You Need #techfeed_live / TechFeed Experts Night 28th
ytaka23
1
120
実例で紹介するRAG導入時の知見と精度向上の勘所
yamahiro
7
2.2k
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
15
1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
14
8.4k
Done Done
chrislema
178
15k
Art, The Web, and Tiny UX
lynnandtonic
290
19k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
22
1.6k
Become a Pro
speakerdeck
PRO
13
4.6k
Building Flexible Design Systems
yeseniaperezcruz
320
37k
The Art of Programming - Codeland 2020
erikaheidi
43
12k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
26
2.3k
The Invisible Customer
myddelton
114
12k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
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!