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