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
2023-04-28_Muddy_Web.pdf
Search
pagu0602
April 28, 2023
Programming
0
3.9k
2023-04-28_Muddy_Web.pdf
pagu0602
April 28, 2023
Tweet
Share
More Decks by pagu0602
See All by pagu0602
パフォーマンス改善のケーススタディ
pagu0602
1
420
Other Decks in Programming
See All in Programming
Catch Up: Go Style Guide Update
andpad
0
210
CSC509 Lecture 02
javiergs
PRO
0
410
Web フロントエンドエンジニアに開かれる AI Agent プロダクト開発 - Vercel AI SDK を観察して AI Agent と仲良くなろう! #FEC余熱NIGHT
izumin5210
3
480
いま中途半端なSwift 6対応をするより、Default ActorやApproachable Concurrencyを有効にしてからでいいんじゃない?
yimajo
2
390
タスクの特性や不確実性に応じた最適な作業スタイルの選択(ペアプロ・モブプロ・ソロプロ)と実践 / Optimal Work Style Selection: Pair, Mob, or Solo Programming.
honyanya
3
160
CSC509 Lecture 06
javiergs
PRO
0
260
GraphQL×Railsアプリのデータベース負荷分散 - 月間3,000万人利用サービスを無停止で
koxya
1
1.2k
チームの境界をブチ抜いていけ
tokai235
0
140
The Flutter Journey of Building a Live Streaming App — With a Side of Performance Tuning
u503
1
100
クラシルを支える技術と組織
rakutek
0
200
CSC305 Lecture 03
javiergs
PRO
0
240
CSC509 Lecture 03
javiergs
PRO
0
330
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
We Have a Design System, Now What?
morganepeng
53
7.8k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Being A Developer After 40
akosma
91
590k
A Tale of Four Properties
chriscoyier
160
23k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
How to Ace a Technical Interview
jacobian
280
24k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
The Pragmatic Product Professional
lauravandoore
36
6.9k
How STYLIGHT went responsive
nonsquared
100
5.8k
A Modern Web Designer's Workflow
chriscoyier
697
190k
How GitHub (no longer) Works
holman
315
140k
Transcript
あああ 1 アメブロにおける WYSIWYGエディタ開発
自己紹介 2 柳 耕太(やなぎ こうた) / パグ Twitter: @pagu0602 • 2017年入社、Ameba7年目 •
Webフロントエンドエンジニア • アメブロの運用開発 ◦ Ameba Pick(アフィリエイト機能)の立ち上げ ◦ WYSIWYGエディタ開発 ◦ アメブロにおけるSPブラウザ向けのエディタ開発
現状の説明 3
4 1. アメブロとエディタについて 2. 現状の課題感 3. 改善プロジェクトの立ち上げ
5 アメブロとエディタについて
6 アメブロについて アメブロは今年で19周年を迎え る誰でも簡単にブログを書くこ とが出来るサービスです。 記事数は25億記事以上存在し、 日々様々な記事が投稿されてい ます。
7 アメブロを書くために用いるエディタについて Web - PC Web - SP iOS Android
8 アメブロのエディタについて - 設計 PC SP Android iOS ユーザーインターフェース ユーザーインターフェース
ユーザーインターフェース ユーザーインターフェース エディタ機能 エディタ機能 エディタ機能 エディタ機能
9 現状の課題感
10 現状の課題感 - PCのエディタ設計 • ライブラリとしてCKEditor 4を利用している • コアのコードを書き換えており、アップデートが難しい ◦
サポートが今年で切れてしまう →メンテナビリティに不安を抱えた状態
11 現状の課題感 - 開発コストが高い PC Android iOS 機能 実装 実装
実装 リリース 各プラットフォームの実装が完了次第 SP 実装 →機能を各プラットフォームで実装する必要がある →機能落ち、もしくは待ちが発生する
12 現状の課題感 - 属人性が高い • あまり使われないAPIや機能についての理解が求められるケースがある • 機能同士の相性が悪いことがあるが、それを考慮出来る範囲が人によって違う ◦ 範囲選択をしてセンタリングをした場合にこの要素には適用しない等
→エディタに関わる案件をアサイン出来るメンバーが限られている
13 現状の課題感 - デグレの検知が困難 • エディタの操作を自動的にテストする環境がない ◦ テスト項目書から漏れるケースがある • 特定のデバイス・ブラウザ・OSで発生するバグ等も存在
→テスト項目書が膨大になりがちで、完璧に網羅するのも難しい →ユーザーのお問い合わせで発覚するケースも有る
14 改善プロジェクトの立ち上げ
15 改善プロジェクトの立ち上げ 『各プラットフォームで使える共通のエディタを開発し 堅牢なテストで動作を担保できている状態』 プロジェクトのゴール
16 改善プロジェクトの立ち上げ - 評価方法 • デバッグ工数の削減量 • 実装工数の削減量とリードタイム短縮 • メンテナーの数とオンボーディング時間改善
→これらを概算で出して承認を得た上で評価にも用いることに。
WYSIWYGエディタ開発について 17
自己紹介 18 捧 貴史(ささげ たかふみ) Twitter: @sasaplus1 • 2017年中途入社 • Webフロントエンドエンジニア •
アメブロの運用開発 ◦ ビルド環境やCIの整備 ◦ WYSIWYGエディタの開発
19 1. エディタの設計について 2. 指標はどれくらい改善されたか 3. 持続可能なエディタ保守に向けて
20 エディタの設計について
21 エディタを設計する前に • アメブロ固有の前提条件や制約、悩んだこと ◦ contenteditable属性の使用が必須 ◦ document.execCommandを使用しない ◦ エディタライブラリを使用するかどうか
22 contenteditable属性とは • HTMLの要素に付加できるグローバル属性 • 要素の内容をユーザーが編集できるようになる https://developer.mozilla.org/ja/docs/Web/HTML/Global_attributes/contenteditable
23 contenteditable属性の使用が必須 • なぜ属性を使用する必要があるのか? ◦ 既存の機能の1つがcontenteditable属性の要素の中で 使用されることを前提とした実装をしているため → この属性を使用していないエディタライブラリを使用すると
機能が壊れる可能性がある
24 document.execCommandとは • 編集可能領域に対して様々な変更を加えることができる ◦ 文字の装飾(太字、斜体、色、等々) ◦ Undo/Redo ◦ コピー
& ペースト ◦ 等々
25 document.execCommandを使用しない https://developer.mozilla.org/ja/docs/Web/API/Document/execCommand • 非推奨となっており、いつ機能が削除されるかわからない • ブラウザによって対応もまちまち → 自前で実装する方針に
26 エディタライブラリを使用するかどうか • これまでの条件に合うライブラリが存在するか調査した ◦ GitHubで"editor"を検索した ◦ 条件に合うものはいくつか存在したものの最終更新が数年 前のものなどが多数 •
Lexicalの登場でDraft.jsがメンテナンスモードとなるなど 外部要因に振り回されたくないという気持ちもあった https://lexical.dev/ https://draftjs.org/ → ライブラリを使用しない方向で作ることに
27 自前でエディタを設計・実装する • メリット ◦ 自前で実装するので機能を柔軟に変更できる ▪ 特にa11yに関する挙動への要望は多くなるのではないかと予想した ◦ 外部要因に振り回されない
• デメリット ◦ RangeやSelectionなどの利用機会の少ないAPIの理解が必要 ◦ contenteditableの挙動の理解が必要でとにかく大変 https://developer.mozilla.org/ja/docs/Web/API/Selection https://developer.mozilla.org/ja/docs/Web/API/range
28 エディタを設計するにあたって • 目指したいこと ◦ 機能の追加が容易であること ◦ 保守に苦労しないこと ▪ コードベースが大きくなりすぎないこと
▪ ソースコードを読むときに当たりを付けられること
29 機能の追加が容易・コードベースの肥大化に対して • 現状のエディタの機能を単純に再実装していくと確実に コードベースが大きくなっていくはず → 機能をプラグインとして単体のnpmモジュールとする → プラグインの管理や連携を担うコアモジュールを作る
30 構成図 コア packages/core プラグイン Undo&Redoプラグイン packages/plugin-undo-and-redo 文字装飾プラグイン packages/plugin-decorator プラグイン
各種プラグイン packages/plugin-xxx
31 コアとプラグインの連携 コア packages/core プラグイン Undo&Redoプラグイン packages/plugin-undo-and-redo 文字装飾プラグイン packages/plugin-decorator プラグイン
各種プラグイン packages/plugin-xxx contenteditable要素 イベント コマンド
32 SPエディタに新エディタを搭載してリニューアル
33 指標はどれくらい改善されたか
34 指標はどれくらい改善されたか • デバッグ工数の削減量 → テスト環境を整えたので大幅に削減できた • 実装工数の削減量とリードタイム短縮 → 4環境への対応が不要になり大幅に削減できた
• メンテナーの数とオンボーディング時間改善 → アルバイトがすぐに開発に取りかかることができた
35 持続可能なエディタ保守に向けて
36 持続可能なエディタ保守に向けて • より一層メンテナーの数を増やす • ユニットテストやE2Eテストを充実させる • RangeやSelectionに関する理解が深まるような環境づくり
ご静聴ありがとうございました 37