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
pixivisionを動かし続けるために
Search
ふぉの
September 29, 2023
Technology
0
1.7k
pixivisionを動かし続けるために
2023-09-29, PIXIV MEETUP 2023 (LT1-2)
https://conference.pixiv.co.jp/2023/meetup#lt
ふぉの
September 29, 2023
Tweet
Share
More Decks by ふぉの
See All by ふぉの
令和に独自CMSを動かし続けるために
fono09
0
46
Other Decks in Technology
See All in Technology
Snowflake のアーキテクチャは本当に筋がよかったのか / Data Engineering Study #30
indigo13love
0
290
AIを使っていい感じにE2Eテストを書けるようになるまで / Trying to Write Good E2E Tests with AI
katawara
3
1.9k
AI時代の知識創造 ─GeminiとSECIモデルで読み解く “暗黙知”と創造の境界線
nyagasan
0
160
東京海上日動におけるセキュアな開発プロセスの取り組み
miyabit
0
200
私とAWSとの関わりの歩み~意志あるところに道は開けるかも?~
nagisa53
1
140
2025-07-25 NOT A HOTEL TECH TALK ━ スマートホーム開発の最前線 ━ SOFTWARE
wakinchan
0
180
経験がないことを言い訳にしない、 AI時代の他領域への染み出し方
parayama0625
0
260
Kiro Hookを Terraformで検証
ao_inoue
0
140
Wasmで社内ツールを作って配布しよう
askua
0
150
Vision Language Modelと自動運転AIの最前線_20250730
yuyamaguchi
2
740
増え続ける脆弱性に立ち向かう: 事前対策と優先度づけによる 持続可能な脆弱性管理 / Confronting the Rise of Vulnerabilities: Sustainable Management Through Proactive Measures and Prioritization
nttcom
1
220
経理出身PdMがAIプロダクト開発を_ハンズオンで学んだ話.pdf
shunsukenarita
1
240
Featured
See All Featured
Six Lessons from altMBA
skipperchong
28
3.9k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
What's in a price? How to price your products and services
michaelherold
246
12k
A Tale of Four Properties
chriscoyier
160
23k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
Designing Experiences People Love
moore
142
24k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
390
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Transcript
pixiv.inc pixivisionを 動かし続けるために @fono 1
Profile fono バックエンドエンジニア 2019年度新卒入社。趣味は旅(鉄道, バイク)と自宅サーバー 入社時所信は「自分の”好き”でみんな の”好き”を支えたい」 2
全体の流れ 1. 今日の内容 2. pixivisionとは? 3. 機能のかいしゃく 4. アーキテクチャ改善 5.
未来へ届ける 3
今日の内容 話すこと • 2021年8月着任時からpixivisionでやってきたこと • 全体を通した技術的な思考、志向、アーキテクチャ 話さないこと • 実装の細部 •
言語や環境に依存したトリッキーな部分 4
とは? www.pixivision.net のこと(since 2014.6) 歴史的経緯でコードネームはspotlight \ ミテネ! / 5
公式説明 (/ja/about)は下記の通り イラストやマンガ、ノベルをはじめとし た「創意工夫から生まれる"とっておきの 作品"」とオタクカルチャーを多言語で世 界に向けて発信する、毎日に退屈したく ない人のための創作系メディアです。 \ ミテネ! /
6 とは?
機能のかいしゃく 7
解釈🤔 8
機能実装の経緯と意図を解釈する • 機能の経緯と動作と実運用 • 資料はUMLと文章で構成 • 古いという理由で邪険にしない(不要なバイアス) つぶさに調べて資料にまとめた上で、丁寧に解釈していく 9
つぶさに調べて まとめている様子 UMLでの表現 • ステートマシン図(状態遷移) • 相互作用とフロー(シーケンス図) • 自然言語よりは意味が固まっている •
コード読解より大枠を理解しやすい • 必要な部分は文章で補足 10
つぶさに調べて まとめている様子 文章での表現 • 必要な分だけ • とはいえ少なくできない • 実装経緯 •
期待された・実は違う動作 • 今後の改修方針 11
わ か る 資料はめんどい…… 12
VCSはコードの履歴を残すが 経緯と意図は残してくれない しかしながら 13
だからこそ • 過度に1資料を肥大化させない ⇒カジュアルに新しいページを作る • 惰性で残すことだけに固執しない ⇒Archiveという状態で見えなくする • しっかり資料奉行をやる ⇒読める、書ける、整っているを維持する
14
機能のかいしゃく 15
介錯😇 16
使われていない機能を片付ける 解釈を終えた機能を、精度高く判断して介錯する • 敬意を持って看取る • 安全に消す ◦ 管理画面以外、基本的にメンテナンスで停止しない • 次に活かす
◦ なぜ不要になってしまったのかは軽く考慮する ◦ やむを得ない場合もある(ほとんどかも) 17
看取った機能たち 消したもの 使っていないから看取る • 独自ABテスト • 管理画面の一部ロール • 運用実態のない表示領域 •
記事末導線テンプレート管理 • 公開済み記事の膨大な編集履歴 吸収合併したもの まとめて片寄せする • 記事データ形式(2形式⇒1形式) • 記事サムネイル形式(2形式⇒1形式) 18
確実に実装量は減って 明らかに身軽になった 結果として DB 52カラム廃止 仕様 10+機能廃止 ※チケットベース,統廃合含む 21万+滞留レコード削除 ※本番DB保持から必要なレコードのみデータ基盤退避に仕様変更
19
アーキテクチャ改善 20
アーキテクチャ改善 • 身軽になったので、解釈が十分にできた機能が多くなる • 全体の実装をどのように整理するかの議論ができるようになる • 資料と照らし合わせて差分で検討できる • しかし、複雑性起因で撤退する機能はまだある •
全体の構造を見直す時期では? 21
深まる検討と実装 分割 ベタ書きの脱却と疎結合化 • どこで分割するか • 分割して差し替えたらどうなるか • 疎結合にして差し替えるのに適切な 場所はどこか
抽象化 移譲と認知負荷の軽減 • 適度な抽象度か • 既存実装に抽象度のブレはないか • この抽象は何を表現しているのか 22
まずは実装を大きく整頓した 平置きだったコードを フォルダに整頓 ※1ファイル1クラス ←before(47 file) after(29 file)→ 単純に認知コストが下がる 23
整頓前の何が辛かったか • 全て平置きであり、依存関係が見通せない • 記事に関する神クラスを片付ける目処が立たない • 2017年の段階で大半の処理が2種類に分けられるとわかったが 実装に反映されていなかった(次のスライドで説明) 24
横2分割 2種類の分類 Admin(赤色) 管理画面/ビジネスユーザー側 • 記事の管理 • 諸々の業務システム的な部分 Public(青色) 公開画面/記事を表示する側
• www.pixivision.net • 表示やSNSのシェアといった 公開されるデータを扱う 25
整頓方針 • 分類に名前がついていなかったのでPublic, Adminと名付けた • 処理の役割に合わせてPublic, Adminの分離を行い Spotlight Public Admin
Responsive Segregation と名付けた 頭文字から「エスパーズ」と呼んだが呼ぶ機会はあまりない 26
整頓方針 • CQRS(クエリコマンド責務分離)とセットで考え 3種類に整頓(4分類だが、1分類は該当処理なし) • 記事本体の読み書きに関して、下記のように整理できた CQRS\SPARS Public Admin Command
N/A(該当処理なし) (表示側で書き込む) Admin/ArticleCommandRoutine (管理側で書き込む) Query ArticleQueryRoutine (表示側で読み込む) Admin/ArticleQueryRoutine (管理側で読み込む) 27
横2分割 CQRSとの関係 表示と編集を行う処理 • Read/Write • Query, Commandがある 表示に限られた処理 •
ReadOnly • Queryしかない Admin(赤色) Public(青色) 28
整頓結果 • パッケージングを意識し始めることができた • 「こちらを触っても直接Publicは壊れない」という安心感が生まれた • 整頓できないクラスの特徴から今後のリファクタ方針が浮かび上がった ◦ OOP, DDDにおける各種原則の実践も視野に入るようになってきた
◦ 惰性で配置するのではなく、もっと意図した配置とアーキテクチャへ 29
アーキテクチャ改善の続き • 突き詰めると一番身構えるべき変更がわからなくなる • それを脱するにはこの問いが発生する ◦ pixivisionをどうしていくか ◦ 今の実装をどう変えて何を実現したいか •
限られたリソースで優先順位をつけなければならないので、 精度高く、意図を持って決めておく必要性が認識できた • 記事を編集しているチームとより密に連携する必要が出てきた 30
保守だけの状態が終わり あるべき問いに帰結した 31
未来へ届ける • 実は最初のQRコードのリンク先はID=1、最初の記事 • 一貫していたのは「過去の記事がそつなく表示できること」 • これまでpixivisionに携わったすべての人が意図してか意図せずか 記事で紹介した作品と作者を尊敬し、未来に届ける という営みが連綿と続いていた •
その営みを、真摯に、されど楽しく受け継いでいきたい 32
pixivision先生の次回作に ご期待ください ご清聴ありがとうございました 33