Slide 1
Slide 1 text
少人数チーム開発での
レガシープロダクトとの
向き合い方
PHP Conference 2022
@9rokirishima
Slide 2
Slide 2 text
自己紹介
● 緒方 大佑(おがた だいすけ)
● Twitter：くろきり(@9rokirishima)
● 所属
○ Growfit株式会社
○ Webエンジニア(PHPer)
Slide 3
Slide 3 text
話さないこと
● フロントエンド周りの改善
● 組織ビルドについての話
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
STRAYM(ストレイム)
● アートのオーナー権を小口分割化し、取引を行うサービス
● 2019年12月ローンチ
● Growfitとしては2020年5月から開発を請け負う
● 現在Web版とアプリ(Android)版を提供している
○ アプリは2022/03〜
● バックエンドはPHP+Laravel フロントはblade+jQuery
● 開発メンバーはCTO+自分の2人(たまに助っ人)
プロダクト説明
Slide 6
Slide 6 text
技術的な負債がやや多かった
● ビジネスロジックがほぼ全てControllerに実装されていてFat
● 別クラスに同じ処理が存在
● 未使用クラス、未使用メソッド
● エラー処理がそのまますり抜けて正常ルートにいくような処理
● ユニットテストは存在した形跡があるが壊れている
○ seederやfactoryがメンテされておらず何が正かもわからない
引き継いだコード
Slide 7
Slide 7 text
例えば
下記はS3からファイルを取得する際の処理
● エラー処理が未実装な上にreturnしていない等未実装箇所が散見された
Slide 8
Slide 8 text
● 放置できないのでリファクタリングを始める
● 特に計画を立てずにタスクとリファクタリングを並行してこなそう
としていた
● 現状のタスク依頼ペースなら並行して問題はないだろうと考えて
いた
改善を考える
Slide 9
Slide 9 text
最初はある程度スムーズに進んだ
Slide 10
Slide 10 text
この感じならタスクを進めながら
リファクタリングやテスト導入できるだろう
(2020年5月当時)
Slide 11
Slide 11 text
3ヶ月後
Slide 12
Slide 12 text
現実は甘くなかった…
Slide 13
Slide 13 text
● タスク量の増加
○ 大きい機能開発と並行して五月雨に飛んでくる改善案、迫る納期
● 運用業務の増加
○ CSからの質問対応、出品作業、etc。。。
→ 基本的に1人で全て行うため、目の前の仕事をこなすので精一杯になり改善
のことは頭から飛んでいた
3ヶ月後。。
Slide 14
Slide 14 text
このままではよろしくない
Slide 15
Slide 15 text
リファクタリングしたいけど
2人だとリソースも時間も足りない
Slide 16
Slide 16 text
① より開発に集中できる環境を作る
②リファクタリングを継続的に行える仕組み
どうしたか
Slide 17
Slide 17 text
より開発に集中できる環境を作る
Slide 18
Slide 18 text
● 裏側は全て手運用(本人確認、入金、出金等)
● 運用のためのSQLをCS側に提供しておりそれを実行し
てもらう運用だったが、オペレーションミスや何かイレ
ギュラーがあった場合にはエンジニア側で調査や修正
を行う。
● 依頼はSlackで五月雨に飛んでくる
当時の状況
Slide 19
Slide 19 text
● CS用の管理画面を作ってオペレーションを手運用に頼
らないように自動化
● CS側は管理画面に従って操作をすれば良いのでこち
らへの依頼が減ってその分開発に集中できる
①管理画面の開発
Slide 20
Slide 20 text
● Slackに随時依頼を投げてもらうのではなく、backlogに
指定したフォーマットで依頼タスクを作成してもらう
● 希望の完了期日も入力してもらい、それを加味して開
発側がスケジュールを立てる
○ 運用と開発のスイッチコスト削減
②タスク管理の導入(backlog)
Slide 21
Slide 21 text
リファクタリングを継続的に行う仕組み
Slide 22
Slide 22 text
● 生産性の向上
○ コードを綺麗に保つことで保守性を上げる
● いつかメンバーが増えた時に受け入れやすい状況を作る
○ 負債が多いと新しいメンバーにとってストレスになるし都
度細かく説明しないといけない
なぜリファクタリングをするか？
Slide 23
Slide 23 text
● 全てをリファクタリングするのは不可能
● 既存の構成はあまり変えずにタスクに関連するクラス・メソッドのみ
● しかし、該当箇所に絞ったとしてもリファクタリングすべきコードの量が多いの
で全部は無理
→より効果のある箇所に絞ってリファクタリングを行う
とはいえ。。
Slide 24
Slide 24 text
1. Viewに関連する箇所の改善
2. 可読性の低いコードの修正
3. 意味のないコードの削除
他の箇所は工数に余裕があれば修正していく
→上記以外をやらないわけではない
絶対にリファクタする項目
Slide 25
Slide 25 text
1. Viewに関連する箇所の改善
Slide 26
Slide 26 text
● プロダクトの特性上デザインや文言の修正依頼がかなり多い
○ 多い時は1日5回以上修正依頼が来てリリースすることもある
● 画面表示用にデータを加工する処理がControllerやModelに入り込んでいる
● 慣れるまではどこに手を加えればいいのかわからない
● 毎度Viewの修正のためにModelやビジネスロジックに手を加えると検証コストが爆
上がりしてしまいリリース速度が落ちてしまう。
1. Viewに関連する箇所の改善
Slide 27
Slide 27 text
● ADR(Action Domain Responder)パターンのResponderを作成
してView関連の処理をそこに集約する
○ 「PHPフレームワーク Laravel Webアプリケーション開発」を参考
○ 既存のディレクトリ構成をあまり変更せずに採用できる
● 新規追加の画面は必須で既存画面も改修対象となった場合は
Responderを実装するルール
アプローチ
Slide 28
Slide 28 text
Responderの例
Slide 29
Slide 29 text
2. 可読性の低いコードの修正
Slide 30
Slide 30 text
● ルールがないので無法地帯
● 徐々にストレスになっていく
○ phpcsを導入(PSR-12準拠)
○ 修正は単独でコミット
2. 可読性の低いコードの修正①
例：同じif文でも記法が全部違う
Slide 31
Slide 31 text
● 一部Controllerでクエリの発行処理が実装されている
○ 後から付け足したのかModelに似たような処理が実装される
■ duplicated codeが量産されていく
● IDEのduplicated codeの警告でている場合は処理をどちらかに寄せる
か新規でクラス作ってそちらに移植するように対応
2. 読みづらいコードの修正②
Slide 32
Slide 32 text
3. 意味のないコードの削除
Slide 33
Slide 33 text
● 下記のようにコメントアウトされているメソッドが散見された
● 今使ってないコードは全部消す。
○ 余計な混乱を招かないように
○ 念の為問題ないかは調査するが、現在動いていない時点で基本消す
3. 意味のないコードの削除
Slide 34
Slide 34 text
● 小さい歩みだがリファクタリングを続けていくことで開発速度が上がりデプロイ件数
も上がっていった。
○ 2022年9月時点での本番デプロイ件数： 189件(2021年：194件、2020年(5月〜)：98件)
● ストレスの軽減 => 開発モチベーションのアップ
● ルール化していくことで細かいことに悩まなくて良くなる
● 悩まずに手を入れられる => 別の人に依頼しやすくなる
● 本来考えるべきプロダクトの成長について考える余裕が出てくる
リファクタリングの成果
Slide 35
Slide 35 text
● ユニットテストの再導入
● ログ周りの見直し
● PHP+Laravelのバージョンアップ
● リアーキテクチャ
○ ADRに完全移行させたい
○ 新しく入ってきた人がより理解しやすい作りに
未来に向けて
Slide 36
Slide 36 text
● リソースが限られている環境で品質を上げるためには全部に向き
合おうとするのではなく効果が高い箇所に集中して向き合う
● 継続してリファクタリングできるようなルール作り、仕組み
まとめ
Slide 37
Slide 37 text
● リソースが限られている環境で品質を上げるためには全部に向き
合おうとするのではなく効果が高い箇所に集中して向き合う
● 継続してリファクタリングできるようなルール作り、仕組み
まとめ
まだまだこれから！
Slide 38
Slide 38 text
ご清聴ありがとうございました！