仕様変更に耐えるための"今の"DRY原則を考える / Rethinking the "Don't repeat yourself" for resilience to specification changes

2025/02/22に行われたPHPカンファレンス名古屋2025の発表資料です。

---

DRY（Don't Repeat Yourself）原則はコードの重複を減らし、保守性を高める効果的な手法ですが、適用の仕方によっては仕様変更に対応できなくなることがあります。
私が直面したのは、二つの似た処理を一つのメソッドに統合し、フラグで細かい違いを切り替えるコードでした。しかし、片方の処理を変更すると、もう片方にも影響が出てメソッドが複雑化する…これ本当にDRYなん？と思いました。

このトークでは、当時はDRYだったものが、時間とともに保守性を損ない、結果的にDRYではなくなったケースについて紹介します。
何を共通化し、何を分離すべきかを考え直し、どのようにリファクタリングを行ったかについて具体的な事例を交えてお話します！

「当時はこうでよかったが、今ここに大変更を加えたい」と感じている方や、似たような体験をした方にとって、私の対処方法が参考になれば嬉しいです！

Transcript

1. 仕様変更に耐えるための "今の"DRY原則を考える まきまき 2025/02/22 PHPカンファレンス名古屋 1
2. まきまき　 　　　　　　　 @_mkmk884 愛媛→京都→小田原　PHPer 名古屋目的でちゃんと来るのは初めて 学生のころに音楽フェス（TREASURE05X） で蒲郡にはよく行っていた 2
3. 目次 1. 私が直面した問題について 2. ”今”考える共通にするべきもの 3. どう変えて仕様変更へ追従したか 4. 直面して実感したこと、学び 5. まとめ 3
4. 目次 1. 私が直面した問題について 2. ”今”考える共通にするべきもの 3. どう変えて仕様変更へ追従したか 4. 直面して実感したこと、学び 5. まとめ 4
5. 今回のおはなし 5 二つの似た処理を一つのメソッドに統合した ソースコード。 そのメソッドは、フラグで細かい違いを 切り替えていました。 片方の処理に変更を加えようとしたときに、 もう片方に影響が出たというお話です。
6. 占い配信サービス 6 入稿データ 配信 サービスA データ 配信 サービスB データ … 2/24〜3/2の おとめ座 ★★★★★ 変 換
7. 自社データをもとに外部サービス用のデータを作る 7 入稿データ ユニークコード ‘submission0222’ … 配信 サービスA データ 配信 サービスB データ サービスA内 ユニークコード ‘phone0222’ サービスB内 ユニークコード ‘tv0222’
8. [やりたいこと] 配信サービスデータを削除する 8 入稿データ ユニークコード ‘submission0222’ … 配信 サービスA データ 配信 サービスB データ サービスA内 ユニークコード ‘phone0222’ サービスB内 ユニークコード ‘tv0222’
9. 9 配信サービスデータを削除できる画面は2つ 配信サービスデータ一覧画面 　ぺちなご占い 　　2/24〜3/2　♈おひつじ座 配信サービスAデータ一覧 　　2/24〜3/2　♉おうし座 ☑ ☑ 　　2/24〜3/2　♊ふたご座 □ 削除 　　2/24〜3/2　♉おうし座 □
10. 10 入稿データ一覧画面 　ぺちなご占い 　　2/24〜3/2　おひつじ座 入稿データ一覧 　　2/24〜3/2　おうし座 ☑ ☑ 　　2/24〜3/2　ふたご座 □ 配信データ削除 　　2/24〜3/2　おうし座 □ 削除対象の配信サービス ✕ 　　サービスA 　　サービスB ☑ □ 削除 外部サービスを選択する ことで入稿データに紐づく 配信データが削除できる 配信サービスデータを削除できる画面は2つ
11. 削除メソッド 11 delete() 前処理 削除リスト（配列） を作る 削除処理
12. 削除メソッド 12 delete() 前処理 削除リスト（配列） を作る 削除処理 $is_from_submission フラグで、 どちらの画面から 呼ばれているかを判断 if ($is_from_submission)
13. 削除メソッド 13 delete() 削除リスト（配列） を作る 削除処理 ▼ 配信サービスデータ一覧画面 ▼ 入稿データ一覧画面 前処理 if ($is_from_submission) if ($is_from_submission) { } else { }
14. 削除メソッド 14 delete() 削除リスト（配列） を作る 削除処理 ▼ 配信サービスデータ一覧画面 ユニークコード レコードID 前処理 if ($is_from_submission)
15. ユニークコードの取得方法 15 ユニークコードとする カラム名が プロパティで定義 Factoryパターンを用いたガチガチ継承クラス → 対応サービスの拡充を楽にするため ▼ 入稿データ ▼ 配信サービスAデータ
16. 16 ここで 問 題 発 生
17. 17 \ ﾅﾝﾀﾞｯﾃ---!!! / 外部配信サービスA 仕様変更
18. Aサービスが2つのコードでユニークになった 18 入稿データ ユニークコード ‘submission0222’ … 配信 サービスA データ 配信 サービスB データ Aサービス内 ユニークコード ‘phone’ ‘0222’ Bサービス内 ユニークコード ‘tv0222’ 2つ掛け合わせて ユニーク
19. 19 配信サービスデータ一覧画面 　ぺちなご占い 　　2/24〜3/2　♈おひつじ座 配信サービスAデータ一覧 　　2/24〜3/2　♉おうし座 ☑ ☑ 　　2/24〜3/2　♊ふたご座 □ 削除 　　2/24〜3/2　♉おうし座 □ 今回修正したい画面の処理 配信サービスデータ一覧 画面からの削除処理の 修正が必要になった
20. 何も修正しなければ起こる問題 20 配信サービスデータ一覧画面からの処理で出来上がる配列 キーが重複し、後続のレコードIDのみしか削除できない ※ イメージ
21. レコードIDをキーにするか…！ 21 削除するレコードIDの保持はできる 配信サービスデータ一覧画面からの処理で出来上がる配列
22. レコードIDをキーにするか…！ 22 入稿データ一覧画面からの処理で出来上がる配列 同じ形にできない！！！ 入稿データに紐づくサービスの レコードがない可能性がある
23. 片方の処理の変更がもう片方の処理に影響する 23 家の都合で 実家に帰ることに したんだよね 入稿データ一覧 画面からの処理 配信サービスデータ 一覧画面からの処理 え？ 俺普通に今の家に 帰りたい
24. サクッと終わらないことに絶望 24 ユニークキーが２つになる仕様変更 • ガチガチの継承クラスを用いている • 2画面から呼ばれるメソッド 影響範囲〜〜〜！ 課題 現状 制約〜〜〜！
25. サクッと終わらないことに絶望 25 ユニークキーが２つになる仕様変更 • ガチガチの継承クラスを用いている • 2画面から呼ばれるメソッド 影響範囲〜〜〜！ 課題 現状 制約〜〜〜！
26. 26 これって世にいう DRYなん…？ Don't repeat yourself
27. 目次 1. 私が直面した問題について 2. ”今”考える共通にするべきもの 3. どう変えて仕様変更へ追従したか 4. 直面して実感したこと、学び 5. まとめ 27
28. DRY(Don't repeat yourself)原則 28 • 同じ意味や機能を持つ情報を複数の場所に 重複して置くことをなるべく避けるべきとする考え方 • ソフトウェアの構成や構築手法についての原則の一つ 信頼性の高いソフトウェアを開発して、開発そのものを簡単に理解したり メンテナンスできるようにする唯一の方法は、DRY原則に従うことです。 　 新装版 達人プログラマー 職人から名匠への道
29. 29 delete() 前処理 削除リスト（配列） を作る 削除処理 （たぶん）当時はDRYだと思っていた
30. 30 前処理 削除リスト（配列） を作る 削除処理 （たぶん）当時はDRYだと思っていた ▼ 配信サービスデータ一覧画面 ▼ 入稿データ一覧画面 削除リスト（配列） を作る 削除処理
31. 31 前処理 削除リスト（配列） を作る 削除処理 （たぶん）当時はDRYだと思っていた ▼ 配信サービスデータ一覧画面 ▼ 入稿データ一覧画面 削除リスト（配列） を作る 削除処理
32. 32 前処理 削除リスト（配列） を作る 削除処理 （たぶん）当時はDRYだと思っていた ▼ 配信サービスデータ一覧画面 ▼ 入稿データ一覧画面 削除リスト（配列） を作る 削除処理 同じようなコードだし 共通化するとよさそう 当時の開発者
33. [当時] これからも変わらない部分と変わる部分 33 変わらない部分 • サービスデータを消すこと 自分たちのサービスの2種類の画面で共通なこと • 各サービスのデータの構成方法
34. [当時] これからも変わらない部分と変わる部分 34 変わる部分 • サービス間の差異 新規サービス連携開始時に拡充すること • 例：外部サービスAと外部サービスBの値
35. DRY(Don't repeat yourself)原則 35 すべての知識はシステム内において、単一、かつ明確な、そして信頼できる 表現になっていなければならない。 　新装版 達人プログラマー 職人から名匠への道 DRY原則を破るということは、同じ知識を２箇所以上に記述することです。 　新装版 達人プログラマー 職人から名匠への道
36. DRY(Don't repeat yourself)原則 36 すべての知識はシステム内において、単一、かつ明確な、そして信頼できる 表現になっていなければならない。 　新装版 達人プログラマー 職人から名匠への道 DRY原則を破るということは、同じ知識を２箇所以上に記述することです。 　新装版 達人プログラマー 職人から名匠への道
37. 37 ❌ コードの重複を許さない DRY(Don't repeat yourself)原則 ⭕ 知識の重複を許さない
38. 知識…？ 38 • データ構造やフォーマット • ビジネスルール • 設定値 などなど… 将来にわたって同じ動作が期待されるもの
39. 今回の機能の「変わらない部分」とは 「自分たちのサービス内で決められること」 なのでは…！？
40. [今] これからも変わらない部分と変わる部分 40 変わらない部分 • サービスデータを消すこと この機能の役割
41. [今] これからも変わらない部分と変わる部分 41 変わる部分 • サービス間の差異 • 同一サービスの仕様変更 自社でコントロールできない部分
42. 目次 1. 私が直面した問題について 2. ”今”考える共通にするべきもの 3. どう変えて仕様変更へ追従したか 4. 直面して実感したこと、学び 5. まとめ 42
43. リファクタリングから始めた 43 仕様変更への追従の前に 削除できる2画面同士の依存を剥がすことにした 別居 ※ 想いは同じ
44. [手順①] メソッドを2つに分ける 44 1. 複製してメソッド名だけ変える 2. テストコードを複製 3. 呼び出し箇所を $is_from_submission フラグで分岐
45. [手順②] 特化することで不要になった処理を消す 45 $is_from_submission フラグを消す
46. [手順③] 仕様変更への追従を行う 46 レコードIDがキーになる配列ができるように修正
47. 目次 1. 私が直面した問題について 2. ”今”考える共通にするべきもの 3. どう変えて仕様変更へ追従したか 4. 直面して実感したこと、学び 5. まとめ 47
48. 変わらない部分と変わる部分を明確にする 48 改修・機能追加を行うときは これからも変わらない部分と変わる部分を明確にしておく 変わらない部分 変わる部分 自社でコントロール できない部分 この機能の役割
49. 今回、私は対象の機能の「変わらない部分」とは 「自分たちのサービス内で決められること」とした “今の”変わらない部分と変わる部分を明確にする 49 しかし、方針や需要によって、 自分たちのサービス内でも仕様変更はある
50. 50 ユニークコードとする カラム名が プロパティで定義 Factoryパターンを用いたガチガチ継承クラス → 対応サービスの拡充を楽にするため ▼ 入稿データ ▼ 配信サービスAデータ 実際に何年かは変更に強かった “今の”変わらない部分と変わる部分を明確にする
51. “今の”変わらない部分と変わる部分を明確にする 51 将来どういう変化が起こるかは可能性でしかない できるだけ変更に耐えられるように • “今”のものを”今”考えておく • 考えたものを意図を含めてコードに落とし込んでおく → 今後の変更に比較的耐えられそう
52. 変更が容易に加わりそうなところほど、 あえて共通化をしない できるだけ決定を遅らせる 52 優れたシステムアーキテクチャは、このような決定を従属的かつ遅延可能なも のにする。優れたシステムアーキテクチャは、このような決定に依存しない。 優れたシステムアーキテクチャは、重大な影響を与えることなく、このような 決定を最終時点まで引き延ばせる。 　Clean Architecture 達人に学ぶソフトウェアの構造と設計
53. • 外部サービスとの連携箇所 • 開発を繰り返しながら機能を拡充している途中のもの → ある程度固まってからまとめる 例 できるだけ決定を遅らせる 53
54. ユーザーフローが異なる場合はメソッドも分ける 54 入稿データ 配信 サービスA データ 配信 サービスB データ … 今回 配信サービス データ 一覧画面 入稿データ 一覧画面
55. ユーザーフローが異なる場合はメソッドも分ける 55 改修前の実装はたまたま同じであっただけ 入稿データ一覧画面 画 面 挙 動 配信サービスデータ 一覧画面 ユーザーが選択した情報を もとに紐づく情報を検索 して削除 ユーザーが選択した情報を 削除 概念は異なる
56. ユーザーフローが異なる場合はメソッドも分ける 56 異なるユーザーフローの処理が同じメソッドを通っている → SOLID原則の中の 単一責任原則 に違反している つまりソフトウェアにおける責任とは、「ある関心事について、不正な動作に ならないよう、正常に動作するよう制御する責任」と考えることができます。 ここで重要な役割を果たすのが、単一責任の原則です。「クラスが担う責任 は、たったひとつに限定すべき」とする設計原則です。 　良いコード悪いコードで学ぶ設計入門
57. ユーザーフローが異なる場合はメソッドも分ける 57 変更する場合だけでなく、読むときにも読みやすい → 他のことを気にしなくてよくなる こないださ〜、 〇〇のときに△△が 起こってさ〜 ちょ、聞いてや 昨日✕✕さんと☆☆ に行ったんやけどね ひ…一人ずつ頼む… ねぇ、聞いたー？
58. 今回気づいた変更に耐えないコードと耐えるコード 58 当時 似たような処理が まとまっていること そのメソッド・クラスが、 自身のやるべきことだけ を担う 耐 え な い 耐 え る 似たような処理を 重複して書く 同時に気にしなくていい 処理がまとまっていること 今
59. 目次 1. 私が直面した問題について 2. ”今”考える共通にするべきもの 3. どう変えて仕様変更へ追従したか 4. 直面して実感したこと、学び 5. まとめ 59
60. まとめ 60 • DRY原則とは、コードの重複を避けるのではなく、 知識を複数の場所に重複して置くことをなるべく避ける べきとする考え方 • できるだけ変更に耐えられるよう、変わらない部分と 変わる部分を“今の”段階で、明確にする • 責務が異なる場合は、似たような処理であっても メソッドやクラスを分ける