令和に独自CMSを動かし続けるために

https://otaku.connpass.com/event/318100/ のLTです

Transcript

1. 令和に独自 CMSを 動かし続けるためにやったこと pixiv Inc. fono 2024.7.12
2. 2 自己紹介 • ピクシブ事業本部オブザーバーチーム • やっていたこと ◦ pixiv/pixivision(バックエンド) • やっていること ◦ pixiv系バックエンド等 ◦ データ整備(データ基盤) • 趣味 ◦ アニメ一気見(来週まで待てない族) ◦ 旅行: バイク, 鉄道, 自動車 ◦ 自宅サーバ fono
3. 全体の流れ 1. 今日の内容 2. pixivisionとは？ 3. 機能のかいしゃく 4. アーキテクチャ改善 5. 韓国語導入 6. 未来へ届ける 3
4. 今日の内容 話すこと • 2021年8月着任時から2024年3月までpixivisionでやってきたこと • 全体を通した技術的な思考、志向、アーキテクチャ • 注: PIXIV MEETUP 2023(招待制)の増補版になります 話さないこと • 実装の細部 • 言語や環境に依存したトリッキーな部分 4
5. www.pixivision.net のこと(since 2014.6) 歴史的経緯でコードネームはspotlight ＼ ﾐﾃﾈ! ／ 5 とは？
6. 公式説明 (/ja/about)は下記の通り イラストやマンガ、ノベルをはじめとした「創 意工夫から生まれる"とっておきの作品"」と オタクカルチャーを多言語で世界に向けて発信 する、毎日に退屈したくない人のための創作系 メディアです。 ＼ ﾐﾃﾈ! ／ 6 とは？
7. 7 今回の話1 コードに整頓ルールを決めて適用した ↓before(47 file/directory) after(29 file/dir)→
8. 8 今回の話2 全般的に設計思想を導入して ファクタした • 所謂CQRSがちゃんと刺さる環境だと判断して採用した
9. 9 9 今回の話3 今年3月に韓国語がリリースされた • それまでのリファクタが大きな寄与した
10. 機能のかいしゃく 10
11. 解釈🤔 11
12. 機能実装の経緯と意図を解釈する • 機能の経緯と動作と実運用 • 資料はUMLと文章で構成 • 古いという理由で邪険にしない(不要なバイアス) つぶさに調べて資料にまとめた上で、丁寧に解釈していく 12
13. つぶさに調べて まとめている様子 UMLでの表現 • ステートマシン図(状態遷移) • 相互作用とフロー(シーケンス図) • 自然言語よりは意味が固まっている • コード読解より大枠を理解しやすい • 必要な部分は文章で補足 13
14. つぶさに調べて まとめている様子 文章での表現 • 必要な分だけ • とはいえ少なくできない • 実装経緯 • 期待された・実は違う動作 • 今後の改修方針 14
15. わ　か　る 資料はめんどい…… 15
16. VCSはコードの履歴を残すが 経緯と意図は残してくれない しかしながら 16
17. だからこそ • 過度に1資料を肥大化させない ⇒カジュアルに新しいページを作る • 惰性で残すことだけに固執しない ⇒Archiveという状態で見えなくする • しっかり資料奉行をやる ⇒読める、書ける、整っているを維持する 17
18. 機能のかいしゃく 18
19. 介錯😇 19
20. 使われていない機能を片付ける 解釈を終えた機能を、精度高く判断して介錯する • 敬意を持って看取る • 安全に消す ◦ 管理画面以外、基本的にメンテナンスで停止しない • 次に活かす ◦ なぜ不要になってしまったのかは軽く考慮する ◦ やむを得ない場合もある(ほとんどかも) 20
21. 看取った機能たち 消したもの 使っていないから看取る • 独自ABテスト • 管理画面の一部ロール • 運用実態のない表示領域 • 記事末導線テンプレート管理 • 公開済み記事の膨大な編集履歴 吸収合併したもの まとめて片寄せする • 記事データ形式(2形式⇒1形式) • 記事サムネイル形式(2形式⇒1形式) 21
22. 確実に実装量は減って 明らかに身軽になった 結果として DB 52カラム廃止 仕様 10+機能廃止 ※チケットベース,統廃合含む 21万+滞留レコード削除 ※本番DB保持から必要なレコードのみデータ基盤退避に仕様変更 22
23. アーキテクチャ改善 23
24. アーキテクチャ改善 • 身軽になったので、解釈が十分にできた機能が多くなる • 全体の実装をどのように整理するかの議論ができるようになる • 資料と照らし合わせて差分で検討できる • しかし、まだ実装を諦める機能がある • 全体の構造を見直す時期では？ 24
25. まずは実装を大きく整頓した 平置きだったコードを フォルダに整頓 ※1ファイル1クラス before(47 file)→ after(29 file)→ 単純に認知コストが下がる 25
26. 整頓した結果 • パッケージングを意識し始めることができた • 「こちらを触ってもあちらのパッケージは壊れない」 という安心感が生まれた • 整頓できないクラスの特徴から今後のリファクタ方針が浮かび上がった ◦ OOP, DDDにおける各種原則の実践も視野に入るようになってきた ◦ 惰性で配置するのではなく、もっと意図した配置とアーキテクチャへ 26
27. 整頓前の何が辛かったか • 全て平置きであり、依存関係が見通せない • 記事に関する神クラスを片付ける目処が立たない • 2017年の段階で 大半の処理が2種類に分けられるとされていたが 実装に反映されていなかった(次のスライドで説明) 27
28. 2種類の分類 赤色 管理画面/ビジネスユーザー側 • 記事の管理 • 諸々の業務システム的な部分 青色 公開画面/記事を表示する側 • www.pixivision.net • 表示やSNSのシェアといった 公開されるデータを扱う 28
29. 整頓方針 • 分類に名前がついていなかったので Public, Adminと名付けた • 処理の役割に合わせてPublic, Adminの分離を行い CQRSになぞらえて Spotlight Public Admin Responsive Segregation と名付け「エスパーズ」と呼んだが呼ぶ機会はあまりない 29
30. 整頓方針 • CQRS(クエリコマンド責務分離)とセットで考え 3種類に整頓(4分類だが、1分類は該当処理なし) • 読み書きの偏在を生かして実装時に考えること減らす • 記事本体の読み書きに関して、下記のように整理できた CQRS\SPARS Public Admin Command N/A(該当処理なし) (表示側で書き込む) Admin/ArticleCommandRoutine (管理側で書き込む) Query ArticleQueryRoutine (表示側で読み込む) Admin/ArticleQueryRoutine (管理側で読み込む) 30
31. 読み書きの偏在 表示と編集を行う処理 • Read/Write • Query, Commandがある 表示に限られた処理 • ReadOnly • Queryしかない Admin(赤色) Public(青色) 31
32. 保守だけの状態が終わって あるべき問いに帰結した 32
33. pixivisionでなにしたい？ 33
34. 『韓国語入れたい！！！！』 34
35. 韓国語導入 • 軽く調査した結果 • 意外とできそう 35
36. 韓国語導入 • リファクタ前には想像できなかった速度で実装された韓国語 • 2人で実装、10月着手、12月上旬実装完了 • 2ヶ月調整、3月リリース 36
37. 韓国語導入 • これまでのリファクタの成果が軒並み刺さる • 在るべき場所に在るべきコードを書くことで安全に機能が拡張される 37
38. 次の要求に素早く応える 価値あるリファクタに 38
39. 未来へ届ける • 実は最初のQRコードのリンク先はID=1、最初の記事 • 一貫していたのは「過去の記事がそつなく表示できること」 • これまでpixivisionに携わったすべての人が意図してか意図せずか 記事で紹介した作品と作者を尊敬し、未来に届ける という営みが連綿と続いていた • その営みを、真摯に、されど楽しく受け継いでいきたい 39
40. pixivision先生の次回作に ご期待ください ご清聴ありがとうございました 40