少人数チーム開発でのレガシープロダクトとの向き合い方

PHPカンファレンス2022で発表したスライドです。

Transcript

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