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
50
リニューアルで学んだ通説の捉え方
「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
Exploit the smart speaker at Pwn2Own
lycorptech_jp
PRO
1
43
システム化で乗り切る1200クラスタのKaaS運用
lycorptech_jp
PRO
3
160
LINEヤフーのウェブアクセシビリティ
lycorptech_jp
PRO
3
280
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
8
750
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
7
4.1k
Yahoo! 知恵袋フロントエンドをリアーキテクトしている話
lycorptech_jp
PRO
7
3.3k
UIコンポーネント Vue3マイグレーション体験記
lycorptech_jp
PRO
0
270
スタンプショップの推薦枠に2-stage制を導入した事例紹介
lycorptech_jp
PRO
1
270
Head toward Java 22 and Java 23
lycorptech_jp
PRO
1
220
Other Decks in Technology
See All in Technology
継続性視点での開発生産性マネジメント / Managing Engineering Organization in a Strategic Way
sms_tech
10
1.6k
プロダクトの不具合傾向分析と改善活動について
masayuki_yamad
0
210
Databricksにおける生成AIの取り組み
taka_aki
1
150
Python Web UIフレームワークのススメ
terapyon
0
240
Amazon RDS / Amazon Aurora パフォーマンスチューニングとモニタリング
twingob
4
410
Building Static Websites with Sculpin
opdavies
0
1.3k
[JSAI24] Attention Lattice Adapter: Visual Explanation for Vision-Language Foundation Models
keio_smilab
PRO
0
130
De 0 a SRE en un año - tech4impact 2024
pablokbs
1
180
Nuxt DevTools 101
nozomuikuta
3
320
SONiCスイッチを商用サービスに入れてみた(三井情報株式会社)
sonic
0
190
Oracle Database Technology Night #79 - Oracle Database 23ai 新機能 Oracle Advanced Cluster File System (ACFS)
oracle4engineer
PRO
1
110
何を使って可視化する?AWSでのログ分析/What-do-you-use-to-visualise-it-log-analysis-in-AWS
emiki
2
700
Featured
See All Featured
Statistics for Hackers
jakevdp
790
220k
BBQ
matthewcrist
80
8.8k
Bash Introduction
62gerente
605
210k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
221
21k
Bootstrapping a Software Product
garrettdimon
PRO
302
110k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
24
1.7k
How to train your dragon (web standard)
notwaldorf
76
5.3k
The Straight Up "How To Draw Better" Workshop
denniskardys
228
130k
Practical Orchestrator
shlominoach
183
9.8k
No one is an island. Learnings from fostering a developers community.
thoeni
16
2.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
12
1.1k
Thoughts on Productivity
jonyablonski
60
3.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!