レガシー回避のPHP開発術/avoid_php_legacy

PHPカンファレンス福岡2023

Transcript

1. @hanhan1978 レガシー回避のPHP開発術 保守性の高いアプリケーションを作る方法 2023-06-24 PHPカンファレンス福岡
2. @hanhan1978 • 富所 亮 • 所属 株式会社カオナビ BackEnd Re-architecturing Team (BERT) • 職業 バックエンドエンジニア • ブログ https://blog.hanhans.net • Yokohama North AM https://anchor.fm/yokohama-north-am 2
3. レガシーとはなにか？ 3
4. 4 レガシーの定義
5. 5 “レガシーコードとは、単にテスト の無いコードです。”
6. 6 “毎日実行され、過去の意思決定をもと にのがれようのない影響を及ぼし続ける が、なんの活力もないようなコードがあ る。それを丁寧な言葉で「レガシー」と呼 ぶ。”
7. 7 “保守または拡張が困難な既存のプ ロジェクトなら、なんでも「レガシー」 (legacy)と呼ぶことにしている”
8. 8 “創業期の資金不足や人材不足によっ て生じたコード上の課題全般を、広義 のレガシーコードと定義”
9. まとめると 9
10. • テストが無い • 活力が無い • 保守・拡張が困難 10
11. 11 これらの性質が一つでもあればレガシーなのか？
12. 12 白黒はつかない All or Nothing ではない。
13. 13 • レガシーではない部分（計画的に設計・実装） • レガシーな部分（涙を飲んだ部分）FIXME, TODOなど • レガシーな部分（知らなかった、未認識） 実際にはアプリケーション内に良い箇所・悪 い箇所が混在する
14. 14 思考停止は危険 全体をまとめてレガシーと表現してしまうと 「さあ！フルリニューアルだ！」という話にしかならない
15. 15 場合によっては フルリニューアルは合理的な判断だが 大抵の場合はコストがかかりすぎる → かつ、その組織で１から作ってレガシーになったのよね？
16. 16 場合によっては フルリニューアルは合理的な判断だが 大抵の場合はコストがかかりすぎる → かつ、その組織で１から作ってレガシーになったのよね？ 歴史に学べ！！！
17. 17 この登壇内でのレガシーの扱い
18. 18 • テストが無い • 活力が無い • 保守・拡張が困難 これらを「レガシーな性質」と呼ぶ。
19. 19 アプリケーション内にある「レガシーな性 質」の割合に目を向ける 全体を包含して、思考停止しないこと
20. 20 レガシーな性質≒技術的負債 ただ、このままだと解像度が低い
21. 21 • 自然には少なくならない • 時間とともに勝手に増える レガシーな性質の特性
22. 22 「改善しないと、改善されないんだよ？」 ねぇ知ってる？
23. 23 レガシーな性質を減らす活動をしないとい けない
24. 24 レガシーを回避するとは？
25. 25 ソフトウェア開発の目的はレガシー回避で はない
26. 26 • テストがあり • 活力があり • 保守・拡張が容易 これらは必ずしも必須ではない
27. 27 プロダクトアウト＋カスタマーサクセスが目 的 -> みんなでアジャイル
28. 28 ただし レガシーな性質を放置すると 目的達成の足を引っ張るようになる
29. 29 現状、達成されていることにも目を向けましょ うね。 ところで
30. 30 • 希望 • 利益 • 人々の生活 • ビジョン これらを達成できていないものはレガシーにも なれていない
31. 31 • 希望 • 利益 • 人々の生活 • ビジョン これらを達成できていないものはレガシーにも なれていない 良い面にもきちんとフォーカスを 当てましょう
32. 32 なるようになって、今がある
33. 33 ソフトウェアが達成したい目的はそれぞれ 作られてきたコンテキストも様々
34. 34 そのソフトウェアを作ってきた歴史がある 作ってきたチームがある 経済活動をしてきた結果として今がある
35. 35 そのアプリケーションに不満があるかもし れない 体制に不満があるかもしれない やり方に不満があるかもしれない
36. 36 それはそれで、ある種安定した状態 単純に、レガシーな性質を悪とみなして活 動しても、うまくいかんぞ！
37. 37 無計画な開発による意図しない副作用 https://www.coastalwiki.org/wiki/Human_causes_of_coastal_erosion
38. 38 テストがないことが普通の場所で、テスト があることを普通にしようとするのは、不 自然な行為 （サバンナをのぞく）
39. 39 現状維持しがち • 今はこれで動いているんだから • 今までこれでやってきたから • 変更するのは大変だから 正常性バイアスとの戦い
40. 40 ”当たり前”を変える必要がある
41. 41 例 • リファクタリング • PHPStan対応 • Accessibility対応 • フレームワークのバージョンアップ • プログラミング言語のバージョンアップ • CIの速度改善
42. 42 ここまでのまとめ
43. 43 • レガシーはソフトウェアの性質 • なるようになったものは変わりづらい
44. 44 レガシーな性質を減らすには、そもそもレガ シーを生み出す既存の流れ全体に抗う必要 がある。 局地戦で改善できるほど甘い相手ではない
45. ソフトウェアはどうやって作られるか？ 45
46. 46 0 -> 1 のフェーズ
47. 47 • リリースが命 • 動くことが最優先
48. 48 色々とない • 金がない • 開発者がいない あるのは達成したいこと
49. 49 目先の対応が求められる > 個社対応
50. 50 • 人材も環境も不十分 • ドメインが安定していない 「レガシーコードとの付き合い方」における課題はこ のフェーズで大量に生み出される
51. 51 1->10のフェーズ
52. 52 ちょっと余裕がでてくる • 開発者の採用にお金を使える • 安定したドメインが出来てくる 商売になる黄金パターンが生まれてくる
53. 53 ソフトウェアの状態 まだ、ビッグリライトをする余地がある
54. 54 技術的負債の要因とその効果 Software Architecture Metrics / Oreilly & Associates Inc, 2022
55. 55 技術的負債の要因とその効果 Software Architecture Metrics / Oreilly & Associates Inc, 2022 リプレースで一気に負債を返済
56. 56 • 事業成長が求められる • 機能がどんどん追加される このフェーズの先には、リプレース作戦を取るの が非現実的になるくらいに、システムの横のサイ ズが増える
57. 57 このフェーズで、「リリース優先なので...」 を連発すると、改善の難易度がバク上が りする
58. 58 技術的負債の要因とその効果 Software Architecture Metrics / Oreilly & Associates Inc, 2022 リプレースが非現実的になるほど、機 能が増えて、複雑度が増す
59. 59 10->100 のフェーズ
60. 60 市場をある程度押さえてきた状態 さらに市場を取りに行くために、採用にコストを かけてチームを増やす 組織も大きくなる。
61. 61 • どんどん機能が増える！ • リプレースは、非現実的になる。 • レガシー解消のコストも大きい • 結局リリース優先の圧力は強い 単純に、影響が大きすぎる＆同時並行で開発してい るものが多すぎて改善活動を諦めだす
62. 62 リプレースが出来ないならどうする？
63. 63 【一発逆転】銀の弾丸を探す現実逃避 • サービス分割 • 一部機能をSaaSに寄せる • マイクロサービス？？ • モジュラーモノリス • Rustで書き直す
64. 64 いわゆる茹でガエル
65. 65 • なんかCI重いな？ • なんか開発に時間かかるな • なんか色々面倒くさいな こんなことをひしひしと感じているフェーズ
66. 66 積み上がるレガシーを肌で感じる ビジネスとしての成功と、開発効率のバラ ンスを上手にとる必要がある
67. 67 ここまでのまとめ
68. 68 ソフトウェアは、社会を良くするという動機を持って 誕生して、だれかの役に立つことで、経済活動が なりたつようになって、どんどん開発が進んで行く
69. 69 レガシーな性質は、普通に開発しているだけで 積み上がっていく。 そして、改善活動はソフトウェアの開発プロセ ス上は優先度の高くない活動。
70. ソフトウェアの各フェーズで何が積み上がるのか？ 70
71. 71 0 -> 1 のフェーズ
72. 72 知識不足によるインフラ面、ソフトウェア設 計面の負債 とにかく最速で作って動かすことが重視さ れている
73. 73 反面、そのときのモダンなスタックで作られてい るので、経年劣化は起きてない。 ソフトウェアの中身や、インフラ構成（カネがな い）で「とにかくリリース優先」の影響を受ける
74. 74 総じて、レガシーな性質は少なく、打ち手 は多いが、やる人がいない、指摘する人 がいない
75. 75 例 • フロントエンドの人しかいないので、全部 Firebase • ベンチャー優遇の、謎SAASを使っている • ノーコードのツール類を組み合わせたキメラ構成
76. 76 1->10のフェーズ
77. 77 開発者が増える。このフェーズで、インフラのうま い載せ替えなどをすると、負債は一気に減る。 例 コンテナ化、イミュータブルインフラストラク チャー化など
78. 78 技術的負債の要因とその効果（再掲） Software Architecture Metrics / Oreilly & Associates Inc, 2022
79. 79 ソフトウェア自体が機能数が少ない状態なの で、大胆な施策も取りやすい。 このタイミングで、機能開発全振りにしてしま うと、大胆な施策が取りにくくなる
80. 80 単純にデータ量も少ないので、色々やり やすい 一方で、セカンドシステム症候群にとらわ れる可能性
81. 81 負債解消のゴールデンタイムであるため、 アレもコレもと欲が出る
82. 82 例 • 俺たちの考えた最強のインフラ（最強ではない • 俺たちの考えた最強のアーキテクチャー（最強ではない • 俺たちの考えた最強の.... (最強ではない • プログラミング言語変更 (変更できない
83. 83 一見して、簡単に倒せそうなサイズ感に見 えてしまうため、きちんとやろうとしすぎる
84. 84 結果として、拡張性のないアーキテクチャーが出 来上がったり、一品物のカスタマイズインフラが出 来てしまい、採用に困るような名品が作られる
85. 85 10->100 のフェーズ
86. 86 基本的には 1->10 のフェーズと同じだが、ビジ ネスドメインの安定がさらに進む 会社の各組織が大きくなり、コミュニケーションコ ストが上がる。
87. 87 失敗したときのコストが、内外に対して上がる このあたりまでにレガシーな性質が解消されずに残っ ている場合、追加で時の試練を受け始める
88. 88 例) • ソフトウェアのバージョン問題 • フレームワークのバージョン問題 • OSのバージョン問題 • 問題のあるデータベース設計 • 取り返しの付かない仕様ハレーション
89. 89 時間経過によって、モダンの概念が変わってくる 仮想サーバー -> コンテナ化 分散システム -> マイクロサービス
90. 90 今やるなら当然コレという方式がでてきてお り、何もしてなかったからレガシーになりました という状態
91. 91 若手優秀層は、隣の芝生は青いな〜っとな る。 つねにデバフを食らっている状態
92. 92 このフェーズでは、チーム数や関連する人間 の数も増えている いかなる改善を行うにもコストが大きい
93. 93 チーム内合意では不十分で、横断的合意が 必要となる 新規加入するメンバーのオンボーディングが 問題になるのもこの頃
94. 94 加入するメンバー数が多いので、教育に携わる メンバーも増やす必要がある EM的なポジションが不在 or EM的な性質を 持ったメンバーがいなくなると、フォローが減る
95. 95 とにかく、問題が多いので、ソフトウェアのレガシー な性質に対する関心も低い チーム内で上手くやることが大事になる レガシーな性質もサイロ化
96. なぜ、改善されないのか？ 96
97. 97 > 改善活動を行わない限り、メンテナンスコストは 上がる 当然ですが、開発にはコストがかかります。コストの 大半は人件費 開発は、つまり開発者を金で雇って、ソフトウェアに 変更を行うこと
98. 98 開発コストに、改善活動は含まれるか？ スクラム開発では、スプリント内に、チームが 主体的に改善活動を意図的に取り入れている チームもありますが、大半のチームは、そんな 余裕はありません。 受託では......
99. 99 質とスピード
100. 100 質とスピードは両立する https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition
101. 101 質とスピードは両立する https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition それが出来るチームならな！
102. 102 大半のチームは、質とスピードの境地に達して いない せいぜい、APoSD における戦術的プログラ マーと同じ状態 複雑性は上がるけど、とりあえず要件は満た す
103. 103 ほとんどの会社において、とりあえず要件は満たす という開発チームが必要最低限のレベル すくなくともリリースが出来るなら、経営陣としては問 題なく見える
104. 104 ほとんどの会社において、とりあえず要件は満たす という開発チームが必要最低限のレベル すくなくともリリースが出来るなら、経営陣としては問 題なく見える ソフトウェアのやばさは、目に見えにくい
105. 105 チームの基本行動
106. 106 ディレクション チームリード デザイナー QC プログラマー • インフラ • バックエンド • フロントエンド • アプリ いわゆる開発チーム チームトポロジーにおけるストリームアラインドチーム
107. 107 場合によっては、ここにマネージャーというさらに 高次のマネジメントを行う人がいたり、スクラム やっている場合は、スクラムマスターやPOがいる
108. 108 さて、このチームだけで、レガシーを促進せず に開発がやれるか？ ほとんどの場合、このチームはメンテナンスコ ストを足す方向に開発します。
109. 109 改善は、このチームの第一目的ではない このチームは、顧客に価値を提供するために機能 開発を行う OSのアップデートとか、脆弱性対応は優先度として は一段下がる
110. 110 技術的負債の要因とその効果 Software Architecture Metrics / Oreilly & Associates Inc, 2022 負債がたまる方向にしか行動しない
111. 111 チームにおこる変化
112. 112 上手くいっているチーム
113. 113 機能開発は行えるチームが、仮にうまくまわっ ていたとする 収益があがるので、企業はさらに投資を行う。 さらに市場を取りに行く。
114. 114 投資をすると、会社は開発者を採用してチームを増 やして、開発を複数並行では実行する。問題はその やり方。
115. 115 よくあるパターンは、チーム解体
116. 116 バラして増やす
117. 117 バラして増やす やったぜ！３倍のアウトカム！ （とはならない）
118. 118 TeamB, TeamC の２つのチームが新設 当初のチームは解体されている 同じスピードでの開発は期待できない
119. 119 増えた２チームは、同じスピード、少なくとも同じ 品質で開発することが、投資した側からは期待さ れる 実際には人間関係の再構築 役割の再定義などが起こるので、当初の効率は下がる
120. 120 チームにおこる変化２
121. 121 • メンバー離脱 • メンバー同士の相性問題 • 評価への不満 買い手市場であるエンジニアは、自分が適切に評 価されていないと感じると、すぐに転職する
122. 122 PHPの主戦場であるインターネット業界で は、平均勤続年数は４年前後 https://web-camp.io/magazine/archives/77694
123. ここまでの話のポイント 123
124. 124 みんなの大好きなクリーンアーキテクチャーの話も、イ ミュータブルインフラストラクチャーの話も、アジャイルも スクラムも出てきません。オブジェクト指向とかも知りま せん。
125. 125 そんなものに関係なく サービスの成長と共にソフトウェアはレガシーな 性質を貯める方向に成長していく
126. 126 ところで レガシーな性質が溜まりすぎるとどうなるか？
127. 127 Bobおじさんの著書 Clean Craftsmanship には、倫理 の話がでてくる。 つまり、プログラマーが匠としての意識、高い倫理を保 たず、テストも書かず、現状が悪化するにまかせた場 合、どうなるか？
128. 128 例 1. Volkswagen の改ざんソフトウェア 2. HealthCare.gov におけるパフォーマンス問題 3. Knight Capital の誤発注による倒産
129. レガシーを積み上げにくくする 129 メモ、ここから３０分かかる
130. 130 全てに先立つ意識 顧客中心主義 ソフトウェアだけを見てはいけない。良い価値提供 という北極星を忘れないように。
131. 131 それって、精神論？ いやいや、誰も技術を軽んじたりしてない。極端 に考えるのはNG
132. 132 https://mtx2s.hatenablog.com/entry/2023/04/26/230917
133. 133 証明できるのか？
134. 134 プロジェクトを改善をした状態、改善をして ない状態で、それぞれ計測しないと、改善 の効果は証明できない？ そんなこと不可能では？
135. 135 マインドチェンジ 正常性バイアスとの正しい向き合い方
136. 136 > 改善を止めようとするなら現状維持のメ リットをださないといけない
137. 137 Q レガシーな性質を保持し続けるメリット を教えてください？ A 無いなら改善が必要だよね？
138. 138 戦略面の打ち手
139. 139 チームを大切に Team First
140. 140 うまくいっているチームを解散させない 改善を活動内に含むことができるような強い チームがこの世でもっとも大切 -> まじで解散させるのはサイコパス
141. 141 教育施策 1. オンボーディングの充実 2. ドメイン知識の共有・促進化策 3. チーム横断のコミュニケーション施策
142. 142 組織変更 機能開発を主とせず、横断的にDevOpsを行 うチームの結成なども候補にはあがる
143. 143 ただ、職能組織でワークしてないからって、横 断的組織を作ったら即座にワークするわけで はない。人による。 チームトポロジーより > 職能集団はサイロ化する。
144. 144 ただ、職能組織でワークしてないからって、横 断的組織を作ったら即座にワークするわけで はない。人による。 チームトポロジーより > 職能集団はサイロ化する。 横断的組織もサイロ化する危険
145. 145 採用 平均勤続年数が4年という世界線 採用した人が4年経過する前に、新しい人を採用 できないと開発が回せません。
146. 146 まとめ
147. 147 1. うまくいっているチームを解体しない 2. プロだって、成果を出すには、時間がかかる 3. 自主的な横断施策を行う人材を、大切にする
148. 148 組織変更だけはうまくいかない 結局は人なので、横断的活躍をするラジカル なメンバーが内部に存在してくれる必要があ る。
149. 149 戦術面でのうちて
150. 150 視野を広くもつこと • 🙅フロントエンドなのでバックエンドわからん • 🙅バックエンド専門なのでインフラわからん • 🙅インフラなのでアプリケーションはわからん
151. 151 問題は職能内に閉じないので、個人が自 分の専門領域に閉じこもると解決が難しく なる。
152. 152 自分しか対応できるひとがいないという状 況だったら、何が出来るか？ -> 「出来ない」で蓋を閉じないで、自分の 領域の横に手をのばすことが大切 精神論ではない。最善を尽くせ！
153. 153 レガシーな性質が溜まりにくいアプリケー ションの基本
154. 154 12 Factor APP まだまだ当たり前になっていない。 先進的というよりは、それに従うことで、自然と 運用・保守し易いアプリケーション＋インフラ環 境になるというイメージ
155. 155 https://12factor.net/ja/
156. 156 https://12factor.net/ja/
157. 157 計算機科学の知識 • アルゴリズム • 空間計算量、時間計算量 • プログラムがどのように実行されているのかの知 識
158. 158 バグとは？ 積み上がったスタックの経路上で、想定外 の状態が混入した結果
159. 159 Why Programs Fail / Morgan Kaufmann 2009
160. 160 Why Programs Fail / Morgan Kaufmann 2009 型がついていると状態を確定し やすい 早めの型付けで安心
161. 161 Working out loud 問題はまず認識されることが必要なので、 大声で叫べ！
162. 162 https://blog.studysapuri.jp/entry/2018/11/14/working-out-loud
163. 163 Slackが活発で、小さいやり取りが多い チームはコミュニケーションの問題が少な い（経験談）
164. 164 テストは書け テスト書くこと自体というよりは、テストを書きや すいコードに自然になるというのがポイントです。
165. 165 テスト書く -> 終わりではない TDDでコードを改善するための、最初の 一歩がテストコード みんなもサバンナで暮らそうな！
166. 166 コレ一冊で、とりあえず現場では困らなくなる
167. 167 その先はコレ！みんなで付録Cの話をしよう！
168. 168 設計視点を持つ 🙅ただコードを書けば良いという意識
169. 169 • 一貫性を保てているか？ • 理解しやすいか？ • 変更しやすいか？ • 場当たり的な対応をしていないか？ • 名前付けは妥当か？ 将来のために出来ることはたくさんある！
170. 170 クリーンアーキテクチャーや、DDDにつ いての私見 -> 特効薬ではない。トップダウン・アプ ローチとして使うとむしろ毒
171. 171 発想法からの指摘
172. 172 まず課題がある 次に解決策がある 課題を見ずに解決策を当てはめるのは🙅
173. 173 設計力をあげるには？ ちょうぜつ本を読め！APoSDを読め！ 視野を広く！
174. 174 相談する コミュニティを頼って！ PHP Slack PHPerRoom に、野生のPHPerがいるぞ！
175. 175 サーベイ系 ちょっと真面目な技術選定の話
176. 176 この回、超おすすめ
177. 177 広く世間に知識を求めて 少し良い技術選定が出来るように
178. カオナビ での取り組みを紹介 178
179. 179 チーム横断課題への取り組み
180. 180 CTO室
181. 181 https://speakerdeck.com/kaonavi/growth-ready-engineering-team
182. 182 レビューマスター
185. 185 設計レビュー
187. 187 BERT設計相談会
189. 189 教育・採用への取り組み
190. 190 カタリバ (社内勉強会)
192. 192 kaonavi Tech Talk
194. 194 エンジニア採用
197. 197 アーキテクチャー施策
198. 198 Architecture Decision Record
200. 200 Package by Feature
204. 204 Feature Toggle
206. 206 その他、細かい施策
207. - PHPUnit - PHPStan - E2Eテスト - メトリクス取得 - 書籍購入制度（ホンダナ） 207
208. 208 今後目指したいこと
209. 209 GQM
210. 210 https://ieeexplore.ieee.org/document/5010301
211. 211 https://blog.hanhans.net/2023/05/29/gqm/
212. 目的指向 -> 企業のパーパスなどとすり合わせしやすい -> ただの数字から目的思考のメトリクスへ 212
213. 213 まとめ
214. - レガシー化させないことは目的じゃない - 目的はもちろん達成する - かつ、レガシー化させない 214
215. 215 https://speakerdeck.com/soudai/learn-from-predecessors
216. 216 救いがないと感じたとき、私は石切工が岩石を叩くのを見に行 く。おそらく100回叩いても亀裂さえできないだろう。しかしそれで も100と1回目で真っ二つに割れることもある。私は知っている。 その最後の一打により岩石は割れたのではなく、それ以前に叩 いたすべてによることを。 Pounding the rocks
217. 217 レガシーから目をそらすな！
218. @hanhan1978 相談・指摘・その他　 下記のTwitterアカウントにどうぞ 218