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.8k
2023-04-28_Muddy_Web.pdf
pagu0602
April 28, 2023
Tweet
Share
More Decks by pagu0602
See All by pagu0602
パフォーマンス改善のケーススタディ
pagu0602
1
330
Other Decks in Programming
See All in Programming
Code Reviews
bkuhlmann
4
890
『Railsオワコン』と言われる時代に、なぜブルーモ証券はRailsを選ぶのか
free_world21
1
270
Ruby Pattern Matching
bkuhlmann
0
930
禅の心を手に入れよ
eltociear
1
180
AmperとFleetを使ったAndroidアプリ
yoppie
0
220
Goのエラースタックトレースの歴史と今後
sonatard
9
1.6k
PHP8.3の機能を振り返る / Review of PHP 8.3 features
seike460
PRO
1
110
Tailwind CSSを本気でカスタマイズする方法
fsubal
14
5.3k
ADRを一年運用してみた/adr_after_a_year
hanhan1978
7
2.4k
AWS CDKコントリビュートTIPS / aws-cdk-contribution-tips
gotok365
3
260
if constexpr文はテンプレート世界のラムダ式である
faithandbrave
3
650
Milestoner
bkuhlmann
1
410
Featured
See All Featured
Gamification - CAS2011
davidbonilla
76
4.6k
Embracing the Ebb and Flow
colly
80
4.1k
Into the Great Unknown - MozCon
thekraken
10
1k
Code Reviewing Like a Champion
maltzj
514
39k
The Illustrated Children's Guide to Kubernetes
chrisshort
31
46k
A Philosophy of Restraint
colly
197
16k
Atom: Resistance is Futile
akmur
259
25k
Infographics Made Easy
chrislema
238
18k
KATA
mclloyd
15
12k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
7
1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
274
13k
Design by the Numbers
sachag
274
18k
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