Tweet
Tweet

Slide 1

Slide 1 text

PHPを始めて1年、 レガシーシステムにどう向き合っているか 2019/08/28 PHP勉強会 #141 @mizuki_r

Slide 2

Slide 2 text

@mizuki_r 弁護士ドットコム株式会社 税理士ドットコム事業部/開発チーム チームマネージャー 2 なにもの PHP, Vue, Nuxt, Management, Recruitment, etc…

Slide 3

Slide 3 text

今日話すこと

Slide 4

Slide 4 text

転職してそろそろ1年、 レガシーシステムにどう向き 合ってきたか

Slide 5

Slide 5 text

これまでの経歴

Slide 6

Slide 6 text

経歴 サーバサイドエンジニア（Perl） ↓ フロントエンドエンジニア（AngularJS, Vue） ↓ テックリード兼フロントエンド兼サーバ兼インフラ ↓ （転職）開発マネージャー（PHP）

Slide 7

Slide 7 text

経歴 • これまで触ったWeb App Frameworks • Perl: Amon2, Mojo • Node: express, koa • DBとか • Perl: Teng, Aniki, DBIx • Node: Sequelize, TypeORM, mysql

Slide 8

Slide 8 text

個性 • ライトウェイトフレームワーク + 様々な モジュールの構成が得意 • パズルを組むのが好き • フルスタックフレームワークが苦手←

Slide 9

Slide 9 text

レガシーシステムとは？

Slide 10

Slide 10 text

レガシーシステムとは • 古いフレームワーク • 古いパラダイム • 積み重ねられた歴史的経緯 • 断絶した知識 • 現在のビジネスモデルとシステムの乖離 • モダンとレガシー
 https://speakerdeck.com/rymizuki/modantoregasi-number-gotandaem

Slide 11

Slide 11 text

運用しているサービス

Slide 12

Slide 12 text

税理士ドットコム • 日本最大級の税理士/税務ポータルサイト • 税理士紹介、Q&A、ニュースなど • サービス開始: 2006年 • エンジニア: 社員x1, 業務委託x5

Slide 13

Slide 13 text

システム • PHP 7.3 • Yii 1.1.20 • jQuery（一部Vue, 一部TypeScript） • MySQL 5.6

Slide 14

Slide 14 text

ビジネス • 税理士紹介サービス • 税理士検索サービス • 税務相談サービス（Q&A） • メディア、広告など • 税理士が監修するものもある • etc

Slide 15

Slide 15 text

人がすくない＼(^o^)／

Slide 16

Slide 16 text

課題

Slide 17

Slide 17 text

課題 • 使ってるかどうかもわからないルーティング • DBの知識があらゆるところに漏洩 • カラム50を超える重要なテーブル • 同じ目的で存在する複数のロジック • 違う目的が共存する巨大なロジック

Slide 18

Slide 18 text

れがしー！＼(^o^)／

Slide 19

Slide 19 text

取り組み

Slide 20

Slide 20 text

課題 • フレームワークがEOL • フレームワークに依存したシステム • ミドルウェアに依存したシステム • ビジネスニーズとシステムの乖離

Slide 21

Slide 21 text

フレームワークがEOL End Of Life なんだよ＼(^o^)／

Slide 22

Slide 22 text

フレームワークに依存したシステム • Routing, Request, Response, Session • あらゆるファイルに存在する Yii::app() • システム的な境界は存在せず、あえて言う ならWAFの制約のみ • アップデートが辛い

Slide 23

Slide 23 text

ミドルウェアに依存したシステム • 特定のミドルウェアのバージョンとコード が密結合、分散しており、バージョンアッ プが困難 • DB構造がActiveRecordを通してViewに漏 洩している • SQLがあちこちでベタ書き

Slide 24

Slide 24 text

ビジネスニーズとシステムの乖離 • みんなが頭の中で思い描くシステムが違う • ビジネス側が想像してるシステム • 開発側が認識しているシステム • 実際に動いているシステム • 「こうしたい」という要望に対して、温度感やスケジュールが噛み 合わない • ビジネス側としては素早く判断して素早く動きたい要望でも、シス テム的に困難な場合がある

Slide 25

Slide 25 text

どうすんのこれ ＼(^o^)／

Slide 26

Slide 26 text

対策 • ビジネス領域の整理 • Diの導入 • ロガーの抽象化 • DBレイヤの抽象化 • Web各レイヤの抽象化 • Routerの抽象化

Slide 27

Slide 27 text

ビジネス領域の整理 • 言葉の認識違いを地道に埋めていく • よくやる変更・ワークフローを認知し、分析の範囲の 目処をつけていく • 将来的にやりたいことから大きめの改善の予定を切っ ていく • 改修によって、ビジネス的な価値が最大化できるよう に計画にコミットする

Slide 28

Slide 28 text

Diの導入 • Ray.Di • DiはFWから独立したものを使いたい • Interfaceを定義して、FWのシステムを隠 蔽する

Slide 29

Slide 29 text

ロガーの抽象化 • `Yii::app()->log()` • 本当に至る所で使われている • Diを使ってLoggerのInterface経由でイン スタンスを注入する

Slide 30

Slide 30 text

DB層の抽象化 • ActiveRecord or Yii::app()->db • ActiveRecordを使うまでもないようなSQLか、 ActiveRecordでは賄いきれない規模のSQL • SQLを直接書く or 外部のSQL Builderを使う • 自作した: https://github.com/rymizuki/ coral-sql

Slide 31

Slide 31 text

DB層の抽象化 2 (予定) • Repository層からのDBアクセスの隠蔽 • Specifiction Patternによる条件の抽象化 • Data Access層を作り、SQL関連の処理を隠蔽 • unitテストを回してスキーマ変更を検知でき るようにする

Slide 32

Slide 32 text

各Web層の抽象化 • Controller層ではYiiを使う • Controllerからビジネスロジックを呼び出し、ビジ ネスロジックはYiiを使わない • UseCase/Interaction/Repository • Response（Renderer）は現状PHPだが、他のライブ ラリに差し替えられるようにInterfaceで抽象してお く

Slide 33

Slide 33 text

Routerの抽象化 • ルーティングライブラリを差し替える（予 定） • 謎不要なルールなども残っており整理を始 める

Slide 34

Slide 34 text

なんとかできそう ＼(^o^)／

Slide 35

Slide 35 text

1年やってみて • PHP 7系は型が示せてハッピー • ドキュメントは公式を見ろ、PSRを把握しておけ • リクエスト単位でスコープが切られている • expressとかより抽象化しやすい • 地道にやっていきの気持ち

Slide 36

Slide 36 text

まとめ • レガシーシステムに対する取り組みをご紹 介しました • 地道にやってくしかない

Slide 37

Slide 37 text

ご清聴ありがとうございました