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
700
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
7
4k
Yahoo! 知恵袋フロントエンドをリアーキテクトしている話
lycorptech_jp
PRO
7
3.2k
UIコンポーネント Vue3マイグレーション体験記
lycorptech_jp
PRO
0
240
スタンプショップの推薦枠に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
6
1k
Other Decks in Technology
See All in Technology
今日からできる!簡単 .NET 高速化 Tips -2024 edition-
xin9le
8
5.1k
データ基盤を支える技術
chanyou0311
5
2.8k
Dungeons and Dragons and Rails
joelq
0
210
Documentação de Produtos: Artefatos essenciais na prática
rigolon
1
240
令和版ソフトウェアエンジニアの情報収集術 PHPカンファレンス香川2024
ysknsid25
4
750
高専で制御を、大学でセンシングを学び、次は脳みそ
satoshirobatofujimoto
0
120
コードファーストの考え方。 Amplify Gen2から学ぶAWS次世代のWeb開発体験
yoshiitaka
2
570
AWS アーキテクチャ作図入門/aws-architecture-diagram-101
ma2shita
16
6.7k
Cloud Service Mesh に触れ合う
phaya72
1
350
Taking Flight with Tailwind CSS
opdavies
0
4.3k
From here to resilience - a travel guide
ufried
1
140
Babylon.jsと色々なものを組み合わせる:ブラウザのAPIやガジェットや2D描画ライブラリなど / Babylon.js 勉強会 vol.3
you
PRO
0
200
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
91
13k
Building a Modern Day E-commerce SEO Strategy
aleyda
22
6.4k
Fireside Chat
paigeccino
22
2.7k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
20
1.8k
The Invisible Customer
myddelton
114
12k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
358
22k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
117
18k
Building an army of robots
kneath
300
41k
Visualization
eitanlees
137
14k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
8
3.5k
GraphQLとの向き合い方2022年版
quramy
33
12k
The Art of Programming - Codeland 2020
erikaheidi
43
12k
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!