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
45
Other Decks in Technology
See All in Technology
AIとともに進化するエンジニアリング / Engineering-Evolving-with-AI_final.pdf
lycorptech_jp
PRO
0
140
Snowflake Summit 2025全体振り返り / Snowflake Summit 2025 Overall Review
mtpooh
2
440
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
1
160
Delegating the chores of authenticating users to Keycloak
ahus1
0
130
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
300
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
360
asken AI勉強会(Android)
tadashi_sato
0
140
KubeCon + CloudNativeCon Japan 2025 Recap by CA
ponkio_o
PRO
0
240
LangSmith×Webhook連携で実現するプロンプトドリブンCI/CD
sergicalsix
1
150
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
290
「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善
kubell_hr
1
240
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
300
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Done Done
chrislema
184
16k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
Adopting Sorbet at Scale
ufuk
77
9.4k
4 Signs Your Business is Dying
shpigford
184
22k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
What's in a price? How to price your products and services
michaelherold
246
12k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
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