Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

PHPカンファレンス福岡2023

Ryo Tomidokoro

June 24, 2023
Tweet

More Decks by Ryo Tomidokoro

Other Decks in Technology

Transcript

  1. @hanhan1978
    レガシー回避のPHP開発術
    保守性の高いアプリケーションを作る方法
    2023-06-24 PHPカンファレンス福岡

    View full-size slide

  2. @hanhan1978
    ● 富所 亮
    ● 所属
    株式会社カオナビ
    BackEnd Re-architecturing Team (BERT)
    ● 職業
    バックエンドエンジニア
    ● ブログ
    https://blog.hanhans.net
    ● Yokohama North AM
    https://anchor.fm/yokohama-north-am
    2

    View full-size slide

  3. レガシーとはなにか?
    3

    View full-size slide

  4. 4
    レガシーの定義

    View full-size slide

  5. 5
    “レガシーコードとは、単にテスト
    の無いコードです。”

    View full-size slide

  6. 6
    “毎日実行され、過去の意思決定をもと
    にのがれようのない影響を及ぼし続ける
    が、なんの活力もないようなコードがあ
    る。それを丁寧な言葉で「レガシー」と呼
    ぶ。”

    View full-size slide

  7. 7
    “保守または拡張が困難な既存のプ
    ロジェクトなら、なんでも「レガシー」
    (legacy)と呼ぶことにしている”

    View full-size slide

  8. 8
    “創業期の資金不足や人材不足によっ
    て生じたコード上の課題全般を、広義
    のレガシーコードと定義”

    View full-size slide

  9. まとめると
    9

    View full-size slide

  10. ● テストが無い
    ● 活力が無い
    ● 保守・拡張が困難
    10

    View full-size slide

  11. 11
    これらの性質が一つでもあればレガシーなのか?

    View full-size slide

  12. 12
    白黒はつかない
    All or Nothing ではない。

    View full-size slide

  13. 13
    ● レガシーではない部分(計画的に設計・実装)
    ● レガシーな部分(涙を飲んだ部分)FIXME, TODOなど
    ● レガシーな部分(知らなかった、未認識)
    実際にはアプリケーション内に良い箇所・悪
    い箇所が混在する

    View full-size slide

  14. 14
    思考停止は危険
    全体をまとめてレガシーと表現してしまうと
    「さあ!フルリニューアルだ!」という話にしかならない

    View full-size slide

  15. 15
    場合によっては
    フルリニューアルは合理的な判断だが
    大抵の場合はコストがかかりすぎる
    → かつ、その組織で1から作ってレガシーになったのよね?

    View full-size slide

  16. 16
    場合によっては
    フルリニューアルは合理的な判断だが
    大抵の場合はコストがかかりすぎる
    → かつ、その組織で1から作ってレガシーになったのよね?
    歴史に学べ!!!

    View full-size slide

  17. 17
    この登壇内でのレガシーの扱い

    View full-size slide

  18. 18
    ● テストが無い
    ● 活力が無い
    ● 保守・拡張が困難
    これらを「レガシーな性質」と呼ぶ。

    View full-size slide

  19. 19
    アプリケーション内にある「レガシーな性
    質」の割合に目を向ける
    全体を包含して、思考停止しないこと

    View full-size slide

  20. 20
    レガシーな性質≒技術的負債
    ただ、このままだと解像度が低い

    View full-size slide

  21. 21
    ● 自然には少なくならない
    ● 時間とともに勝手に増える
    レガシーな性質の特性

    View full-size slide

  22. 22
    「改善しないと、改善されないんだよ?」
    ねぇ知ってる?

    View full-size slide

  23. 23
    レガシーな性質を減らす活動をしないとい
    けない

    View full-size slide

  24. 24
    レガシーを回避するとは?

    View full-size slide

  25. 25
    ソフトウェア開発の目的はレガシー回避で
    はない

    View full-size slide

  26. 26
    ● テストがあり
    ● 活力があり
    ● 保守・拡張が容易
    これらは必ずしも必須ではない

    View full-size slide

  27. 27
    プロダクトアウト+カスタマーサクセスが目

    -> みんなでアジャイル

    View full-size slide

  28. 28
    ただし
    レガシーな性質を放置すると
    目的達成の足を引っ張るようになる

    View full-size slide

  29. 29
    現状、達成されていることにも目を向けましょ
    うね。
    ところで

    View full-size slide

  30. 30
    ● 希望
    ● 利益
    ● 人々の生活
    ● ビジョン
    これらを達成できていないものはレガシーにも
    なれていない

    View full-size slide

  31. 31
    ● 希望
    ● 利益
    ● 人々の生活
    ● ビジョン
    これらを達成できていないものはレガシーにも
    なれていない
    良い面にもきちんとフォーカスを
    当てましょう

    View full-size slide

  32. 32
    なるようになって、今がある

    View full-size slide

  33. 33
    ソフトウェアが達成したい目的はそれぞれ
    作られてきたコンテキストも様々

    View full-size slide

  34. 34
    そのソフトウェアを作ってきた歴史がある
    作ってきたチームがある
    経済活動をしてきた結果として今がある

    View full-size slide

  35. 35
    そのアプリケーションに不満があるかもし
    れない
    体制に不満があるかもしれない
    やり方に不満があるかもしれない

    View full-size slide

  36. 36
    それはそれで、ある種安定した状態
    単純に、レガシーな性質を悪とみなして活
    動しても、うまくいかんぞ!

    View full-size slide

  37. 37
    無計画な開発による意図しない副作用
    https://www.coastalwiki.org/wiki/Human_causes_of_coastal_erosion

    View full-size slide

  38. 38
    テストがないことが普通の場所で、テスト
    があることを普通にしようとするのは、不
    自然な行為
    (サバンナをのぞく)

    View full-size slide

  39. 39
    現状維持しがち
    ● 今はこれで動いているんだから
    ● 今までこれでやってきたから
    ● 変更するのは大変だから
    正常性バイアスとの戦い

    View full-size slide

  40. 40
    ”当たり前”を変える必要がある

    View full-size slide

  41. 41

    ● リファクタリング
    ● PHPStan対応
    ● Accessibility対応
    ● フレームワークのバージョンアップ
    ● プログラミング言語のバージョンアップ
    ● CIの速度改善

    View full-size slide

  42. 42
    ここまでのまとめ

    View full-size slide

  43. 43
    ● レガシーはソフトウェアの性質
    ● なるようになったものは変わりづらい

    View full-size slide

  44. 44
    レガシーな性質を減らすには、そもそもレガ
    シーを生み出す既存の流れ全体に抗う必要
    がある。
    局地戦で改善できるほど甘い相手ではない

    View full-size slide

  45. ソフトウェアはどうやって作られるか?
    45

    View full-size slide

  46. 46
    0 -> 1 のフェーズ

    View full-size slide

  47. 47
    ● リリースが命
    ● 動くことが最優先

    View full-size slide

  48. 48
    色々とない
    ● 金がない
    ● 開発者がいない
    あるのは達成したいこと

    View full-size slide

  49. 49
    目先の対応が求められる
    > 個社対応

    View full-size slide

  50. 50
    ● 人材も環境も不十分
    ● ドメインが安定していない
    「レガシーコードとの付き合い方」における課題はこ
    のフェーズで大量に生み出される

    View full-size slide

  51. 51
    1->10のフェーズ

    View full-size slide

  52. 52
    ちょっと余裕がでてくる
    ● 開発者の採用にお金を使える
    ● 安定したドメインが出来てくる
    商売になる黄金パターンが生まれてくる

    View full-size slide

  53. 53
    ソフトウェアの状態
    まだ、ビッグリライトをする余地がある

    View full-size slide

  54. 54
    技術的負債の要因とその効果
    Software Architecture Metrics / Oreilly & Associates Inc, 2022

    View full-size slide

  55. 55
    技術的負債の要因とその効果
    Software Architecture Metrics / Oreilly & Associates Inc, 2022
    リプレースで一気に負債を返済

    View full-size slide

  56. 56
    ● 事業成長が求められる
    ● 機能がどんどん追加される
    このフェーズの先には、リプレース作戦を取るの
    が非現実的になるくらいに、システムの横のサイ
    ズが増える

    View full-size slide

  57. 57
    このフェーズで、「リリース優先なので...」
    を連発すると、改善の難易度がバク上が
    りする

    View full-size slide

  58. 58
    技術的負債の要因とその効果
    Software Architecture Metrics / Oreilly & Associates Inc, 2022
    リプレースが非現実的になるほど、機
    能が増えて、複雑度が増す

    View full-size slide

  59. 59
    10->100 のフェーズ

    View full-size slide

  60. 60
    市場をある程度押さえてきた状態
    さらに市場を取りに行くために、採用にコストを
    かけてチームを増やす
    組織も大きくなる。

    View full-size slide

  61. 61
    ● どんどん機能が増える!
    ● リプレースは、非現実的になる。
    ● レガシー解消のコストも大きい
    ● 結局リリース優先の圧力は強い
    単純に、影響が大きすぎる&同時並行で開発してい
    るものが多すぎて改善活動を諦めだす

    View full-size slide

  62. 62
    リプレースが出来ないならどうする?

    View full-size slide

  63. 63
    【一発逆転】銀の弾丸を探す現実逃避
    ● サービス分割
    ● 一部機能をSaaSに寄せる
    ● マイクロサービス??
    ● モジュラーモノリス
    ● Rustで書き直す

    View full-size slide

  64. 64
    いわゆる茹でガエル

    View full-size slide

  65. 65
    ● なんかCI重いな?
    ● なんか開発に時間かかるな
    ● なんか色々面倒くさいな
    こんなことをひしひしと感じているフェーズ

    View full-size slide

  66. 66
    積み上がるレガシーを肌で感じる
    ビジネスとしての成功と、開発効率のバラ
    ンスを上手にとる必要がある

    View full-size slide

  67. 67
    ここまでのまとめ

    View full-size slide

  68. 68
    ソフトウェアは、社会を良くするという動機を持って
    誕生して、だれかの役に立つことで、経済活動が
    なりたつようになって、どんどん開発が進んで行く

    View full-size slide

  69. 69
    レガシーな性質は、普通に開発しているだけで
    積み上がっていく。
    そして、改善活動はソフトウェアの開発プロセ
    ス上は優先度の高くない活動。

    View full-size slide

  70. ソフトウェアの各フェーズで何が積み上がるのか?
    70

    View full-size slide

  71. 71
    0 -> 1 のフェーズ

    View full-size slide

  72. 72
    知識不足によるインフラ面、ソフトウェア設
    計面の負債
    とにかく最速で作って動かすことが重視さ
    れている

    View full-size slide

  73. 73
    反面、そのときのモダンなスタックで作られてい
    るので、経年劣化は起きてない。
    ソフトウェアの中身や、インフラ構成(カネがな
    い)で「とにかくリリース優先」の影響を受ける

    View full-size slide

  74. 74
    総じて、レガシーな性質は少なく、打ち手
    は多いが、やる人がいない、指摘する人
    がいない

    View full-size slide

  75. 75

    ● フロントエンドの人しかいないので、全部 Firebase
    ● ベンチャー優遇の、謎SAASを使っている
    ● ノーコードのツール類を組み合わせたキメラ構成

    View full-size slide

  76. 76
    1->10のフェーズ

    View full-size slide

  77. 77
    開発者が増える。このフェーズで、インフラのうま
    い載せ替えなどをすると、負債は一気に減る。
    例 コンテナ化、イミュータブルインフラストラク
    チャー化など

    View full-size slide

  78. 78
    技術的負債の要因とその効果(再掲)
    Software Architecture Metrics / Oreilly & Associates Inc, 2022

    View full-size slide

  79. 79
    ソフトウェア自体が機能数が少ない状態なの
    で、大胆な施策も取りやすい。
    このタイミングで、機能開発全振りにしてしま
    うと、大胆な施策が取りにくくなる

    View full-size slide

  80. 80
    単純にデータ量も少ないので、色々やり
    やすい
    一方で、セカンドシステム症候群にとらわ
    れる可能性

    View full-size slide

  81. 81
    負債解消のゴールデンタイムであるため、
    アレもコレもと欲が出る

    View full-size slide

  82. 82

    ● 俺たちの考えた最強のインフラ(最強ではない
    ● 俺たちの考えた最強のアーキテクチャー(最強ではない
    ● 俺たちの考えた最強の.... (最強ではない
    ● プログラミング言語変更 (変更できない

    View full-size slide

  83. 83
    一見して、簡単に倒せそうなサイズ感に見
    えてしまうため、きちんとやろうとしすぎる

    View full-size slide

  84. 84
    結果として、拡張性のないアーキテクチャーが出
    来上がったり、一品物のカスタマイズインフラが出
    来てしまい、採用に困るような名品が作られる

    View full-size slide

  85. 85
    10->100 のフェーズ

    View full-size slide

  86. 86
    基本的には 1->10 のフェーズと同じだが、ビジ
    ネスドメインの安定がさらに進む
    会社の各組織が大きくなり、コミュニケーションコ
    ストが上がる。

    View full-size slide

  87. 87
    失敗したときのコストが、内外に対して上がる
    このあたりまでにレガシーな性質が解消されずに残っ
    ている場合、追加で時の試練を受け始める

    View full-size slide

  88. 88
    例)
    ● ソフトウェアのバージョン問題
    ● フレームワークのバージョン問題
    ● OSのバージョン問題
    ● 問題のあるデータベース設計
    ● 取り返しの付かない仕様ハレーション

    View full-size slide

  89. 89
    時間経過によって、モダンの概念が変わってくる
    仮想サーバー -> コンテナ化
    分散システム -> マイクロサービス

    View full-size slide

  90. 90
    今やるなら当然コレという方式がでてきてお
    り、何もしてなかったからレガシーになりました
    という状態

    View full-size slide

  91. 91
    若手優秀層は、隣の芝生は青いな〜っとな
    る。
    つねにデバフを食らっている状態

    View full-size slide

  92. 92
    このフェーズでは、チーム数や関連する人間
    の数も増えている
    いかなる改善を行うにもコストが大きい

    View full-size slide

  93. 93
    チーム内合意では不十分で、横断的合意が
    必要となる
    新規加入するメンバーのオンボーディングが
    問題になるのもこの頃

    View full-size slide

  94. 94
    加入するメンバー数が多いので、教育に携わる
    メンバーも増やす必要がある
    EM的なポジションが不在 or EM的な性質を
    持ったメンバーがいなくなると、フォローが減る

    View full-size slide

  95. 95
    とにかく、問題が多いので、ソフトウェアのレガシー
    な性質に対する関心も低い
    チーム内で上手くやることが大事になる
    レガシーな性質もサイロ化

    View full-size slide

  96. なぜ、改善されないのか?
    96

    View full-size slide

  97. 97
    > 改善活動を行わない限り、メンテナンスコストは
    上がる
    当然ですが、開発にはコストがかかります。コストの
    大半は人件費
    開発は、つまり開発者を金で雇って、ソフトウェアに
    変更を行うこと

    View full-size slide

  98. 98
    開発コストに、改善活動は含まれるか?
    スクラム開発では、スプリント内に、チームが
    主体的に改善活動を意図的に取り入れている
    チームもありますが、大半のチームは、そんな
    余裕はありません。
    受託では......

    View full-size slide

  99. 99
    質とスピード

    View full-size slide

  100. 100
    質とスピードは両立する
    https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition

    View full-size slide

  101. 101
    質とスピードは両立する
    https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition
    それが出来るチームならな!

    View full-size slide

  102. 102
    大半のチームは、質とスピードの境地に達して
    いない
    せいぜい、APoSD における戦術的プログラ
    マーと同じ状態
    複雑性は上がるけど、とりあえず要件は満た

    View full-size slide

  103. 103
    ほとんどの会社において、とりあえず要件は満たす
    という開発チームが必要最低限のレベル
    すくなくともリリースが出来るなら、経営陣としては問
    題なく見える

    View full-size slide

  104. 104
    ほとんどの会社において、とりあえず要件は満たす
    という開発チームが必要最低限のレベル
    すくなくともリリースが出来るなら、経営陣としては問
    題なく見える
    ソフトウェアのやばさは、目に見えにくい

    View full-size slide

  105. 105
    チームの基本行動

    View full-size slide

  106. 106
    ディレクション
    チームリード
    デザイナー
    QC
    プログラマー
    ● インフラ
    ● バックエンド
    ● フロントエンド
    ● アプリ
    いわゆる開発チーム
    チームトポロジーにおけるストリームアラインドチーム

    View full-size slide

  107. 107
    場合によっては、ここにマネージャーというさらに
    高次のマネジメントを行う人がいたり、スクラム
    やっている場合は、スクラムマスターやPOがいる

    View full-size slide

  108. 108
    さて、このチームだけで、レガシーを促進せず
    に開発がやれるか?
    ほとんどの場合、このチームはメンテナンスコ
    ストを足す方向に開発します。

    View full-size slide

  109. 109
    改善は、このチームの第一目的ではない
    このチームは、顧客に価値を提供するために機能
    開発を行う
    OSのアップデートとか、脆弱性対応は優先度として
    は一段下がる

    View full-size slide

  110. 110
    技術的負債の要因とその効果
    Software Architecture Metrics / Oreilly & Associates Inc, 2022
    負債がたまる方向にしか行動しない

    View full-size slide

  111. 111
    チームにおこる変化

    View full-size slide

  112. 112
    上手くいっているチーム

    View full-size slide

  113. 113
    機能開発は行えるチームが、仮にうまくまわっ
    ていたとする
    収益があがるので、企業はさらに投資を行う。
    さらに市場を取りに行く。

    View full-size slide

  114. 114
    投資をすると、会社は開発者を採用してチームを増
    やして、開発を複数並行では実行する。問題はその
    やり方。

    View full-size slide

  115. 115
    よくあるパターンは、チーム解体

    View full-size slide

  116. 116
    バラして増やす

    View full-size slide

  117. 117
    バラして増やす
    やったぜ!3倍のアウトカム!
    (とはならない)

    View full-size slide

  118. 118
    TeamB, TeamC の2つのチームが新設
    当初のチームは解体されている
    同じスピードでの開発は期待できない

    View full-size slide

  119. 119
    増えた2チームは、同じスピード、少なくとも同じ
    品質で開発することが、投資した側からは期待さ
    れる
    実際には人間関係の再構築
    役割の再定義などが起こるので、当初の効率は下がる

    View full-size slide

  120. 120
    チームにおこる変化2

    View full-size slide

  121. 121
    ● メンバー離脱
    ● メンバー同士の相性問題
    ● 評価への不満
    買い手市場であるエンジニアは、自分が適切に評
    価されていないと感じると、すぐに転職する

    View full-size slide

  122. 122
    PHPの主戦場であるインターネット業界で
    は、平均勤続年数は4年前後
    https://web-camp.io/magazine/archives/77694

    View full-size slide

  123. ここまでの話のポイント
    123

    View full-size slide

  124. 124
    みんなの大好きなクリーンアーキテクチャーの話も、イ
    ミュータブルインフラストラクチャーの話も、アジャイルも
    スクラムも出てきません。オブジェクト指向とかも知りま
    せん。

    View full-size slide

  125. 125
    そんなものに関係なく
    サービスの成長と共にソフトウェアはレガシーな
    性質を貯める方向に成長していく

    View full-size slide

  126. 126
    ところで
    レガシーな性質が溜まりすぎるとどうなるか?

    View full-size slide

  127. 127
    Bobおじさんの著書 Clean Craftsmanship には、倫理
    の話がでてくる。
    つまり、プログラマーが匠としての意識、高い倫理を保
    たず、テストも書かず、現状が悪化するにまかせた場
    合、どうなるか?

    View full-size slide

  128. 128

    1. Volkswagen の改ざんソフトウェア
    2. HealthCare.gov におけるパフォーマンス問題
    3. Knight Capital の誤発注による倒産

    View full-size slide

  129. レガシーを積み上げにくくする
    129
    メモ、ここから30分かかる

    View full-size slide

  130. 130
    全てに先立つ意識
    顧客中心主義
    ソフトウェアだけを見てはいけない。良い価値提供
    という北極星を忘れないように。

    View full-size slide

  131. 131
    それって、精神論?
    いやいや、誰も技術を軽んじたりしてない。極端
    に考えるのはNG

    View full-size slide

  132. 132
    https://mtx2s.hatenablog.com/entry/2023/04/26/230917

    View full-size slide

  133. 133
    証明できるのか?

    View full-size slide

  134. 134
    プロジェクトを改善をした状態、改善をして
    ない状態で、それぞれ計測しないと、改善
    の効果は証明できない?
    そんなこと不可能では?

    View full-size slide

  135. 135
    マインドチェンジ
    正常性バイアスとの正しい向き合い方

    View full-size slide

  136. 136
    > 改善を止めようとするなら現状維持のメ
    リットをださないといけない

    View full-size slide

  137. 137
    Q レガシーな性質を保持し続けるメリット
    を教えてください?
    A 無いなら改善が必要だよね?

    View full-size slide

  138. 138
    戦略面の打ち手

    View full-size slide

  139. 139
    チームを大切に
    Team First

    View full-size slide

  140. 140
    うまくいっているチームを解散させない
    改善を活動内に含むことができるような強い
    チームがこの世でもっとも大切
    -> まじで解散させるのはサイコパス

    View full-size slide

  141. 141
    教育施策
    1. オンボーディングの充実
    2. ドメイン知識の共有・促進化策
    3. チーム横断のコミュニケーション施策

    View full-size slide

  142. 142
    組織変更
    機能開発を主とせず、横断的にDevOpsを行
    うチームの結成なども候補にはあがる

    View full-size slide

  143. 143
    ただ、職能組織でワークしてないからって、横
    断的組織を作ったら即座にワークするわけで
    はない。人による。
    チームトポロジーより
    > 職能集団はサイロ化する。

    View full-size slide

  144. 144
    ただ、職能組織でワークしてないからって、横
    断的組織を作ったら即座にワークするわけで
    はない。人による。
    チームトポロジーより
    > 職能集団はサイロ化する。
    横断的組織もサイロ化する危険

    View full-size slide

  145. 145
    採用
    平均勤続年数が4年という世界線
    採用した人が4年経過する前に、新しい人を採用
    できないと開発が回せません。

    View full-size slide

  146. 146
    まとめ

    View full-size slide

  147. 147
    1. うまくいっているチームを解体しない
    2. プロだって、成果を出すには、時間がかかる
    3. 自主的な横断施策を行う人材を、大切にする

    View full-size slide

  148. 148
    組織変更だけはうまくいかない
    結局は人なので、横断的活躍をするラジカル
    なメンバーが内部に存在してくれる必要があ
    る。

    View full-size slide

  149. 149
    戦術面でのうちて

    View full-size slide

  150. 150
    視野を広くもつこと
    ● 🙅フロントエンドなのでバックエンドわからん
    ● 🙅バックエンド専門なのでインフラわからん
    ● 🙅インフラなのでアプリケーションはわからん

    View full-size slide

  151. 151
    問題は職能内に閉じないので、個人が自
    分の専門領域に閉じこもると解決が難しく
    なる。

    View full-size slide

  152. 152
    自分しか対応できるひとがいないという状
    況だったら、何が出来るか?
    -> 「出来ない」で蓋を閉じないで、自分の
    領域の横に手をのばすことが大切
    精神論ではない。最善を尽くせ!

    View full-size slide

  153. 153
    レガシーな性質が溜まりにくいアプリケー
    ションの基本

    View full-size slide

  154. 154
    12 Factor APP
    まだまだ当たり前になっていない。
    先進的というよりは、それに従うことで、自然と
    運用・保守し易いアプリケーション+インフラ環
    境になるというイメージ

    View full-size slide

  155. 155
    https://12factor.net/ja/

    View full-size slide

  156. 156
    https://12factor.net/ja/

    View full-size slide

  157. 157
    計算機科学の知識
    ● アルゴリズム
    ● 空間計算量、時間計算量
    ● プログラムがどのように実行されているのかの知

    View full-size slide

  158. 158
    バグとは?
    積み上がったスタックの経路上で、想定外
    の状態が混入した結果

    View full-size slide

  159. 159
    Why Programs Fail / Morgan Kaufmann 2009

    View full-size slide

  160. 160
    Why Programs Fail / Morgan Kaufmann 2009
    型がついていると状態を確定し
    やすい
    早めの型付けで安心

    View full-size slide

  161. 161
    Working out loud
    問題はまず認識されることが必要なので、
    大声で叫べ!

    View full-size slide

  162. 162
    https://blog.studysapuri.jp/entry/2018/11/14/working-out-loud

    View full-size slide

  163. 163
    Slackが活発で、小さいやり取りが多い
    チームはコミュニケーションの問題が少な
    い(経験談)

    View full-size slide

  164. 164
    テストは書け
    テスト書くこと自体というよりは、テストを書きや
    すいコードに自然になるというのがポイントです。

    View full-size slide

  165. 165
    テスト書く -> 終わりではない
    TDDでコードを改善するための、最初の
    一歩がテストコード
    みんなもサバンナで暮らそうな!

    View full-size slide

  166. 166
    コレ一冊で、とりあえず現場では困らなくなる

    View full-size slide

  167. 167
    その先はコレ!みんなで付録Cの話をしよう!

    View full-size slide

  168. 168
    設計視点を持つ
    🙅ただコードを書けば良いという意識

    View full-size slide

  169. 169
    ● 一貫性を保てているか?
    ● 理解しやすいか?
    ● 変更しやすいか?
    ● 場当たり的な対応をしていないか?
    ● 名前付けは妥当か?
    将来のために出来ることはたくさんある!

    View full-size slide

  170. 170
    クリーンアーキテクチャーや、DDDにつ
    いての私見
    -> 特効薬ではない。トップダウン・アプ
    ローチとして使うとむしろ毒

    View full-size slide

  171. 171
    発想法からの指摘

    View full-size slide

  172. 172
    まず課題がある
    次に解決策がある
    課題を見ずに解決策を当てはめるのは🙅

    View full-size slide

  173. 173
    設計力をあげるには?
    ちょうぜつ本を読め!APoSDを読め!
    視野を広く!

    View full-size slide

  174. 174
    相談する
    コミュニティを頼って! PHP Slack
    PHPerRoom に、野生のPHPerがいるぞ!

    View full-size slide

  175. 175
    サーベイ系
    ちょっと真面目な技術選定の話

    View full-size slide

  176. 176
    この回、超おすすめ

    View full-size slide

  177. 177
    広く世間に知識を求めて
    少し良い技術選定が出来るように

    View full-size slide

  178. カオナビ での取り組みを紹介
    178

    View full-size slide

  179. 179
    チーム横断課題への取り組み

    View full-size slide

  180. 181
    https://speakerdeck.com/kaonavi/growth-ready-engineering-team

    View full-size slide

  181. 182
    レビューマスター

    View full-size slide

  182. 185
    設計レビュー

    View full-size slide

  183. 187
    BERT設計相談会

    View full-size slide

  184. 189
    教育・採用への取り組み

    View full-size slide

  185. 190
    カタリバ (社内勉強会)

    View full-size slide

  186. 192
    kaonavi Tech Talk

    View full-size slide

  187. 194
    エンジニア採用

    View full-size slide

  188. 197
    アーキテクチャー施策

    View full-size slide

  189. 198
    Architecture Decision Record

    View full-size slide

  190. 200
    Package by Feature

    View full-size slide

  191. 204
    Feature Toggle

    View full-size slide

  192. 206
    その他、細かい施策

    View full-size slide

  193. - PHPUnit
    - PHPStan
    - E2Eテスト
    - メトリクス取得
    - 書籍購入制度(ホンダナ)
    207

    View full-size slide

  194. 208
    今後目指したいこと

    View full-size slide

  195. 210
    https://ieeexplore.ieee.org/document/5010301

    View full-size slide

  196. 211
    https://blog.hanhans.net/2023/05/29/gqm/

    View full-size slide

  197. 目的指向
    -> 企業のパーパスなどとすり合わせしやすい
    -> ただの数字から目的思考のメトリクスへ
    212

    View full-size slide

  198. 213
    まとめ

    View full-size slide

  199. - レガシー化させないことは目的じゃない
    - 目的はもちろん達成する
    - かつ、レガシー化させない
    214

    View full-size slide

  200. 215
    https://speakerdeck.com/soudai/learn-from-predecessors

    View full-size slide

  201. 216
    救いがないと感じたとき、私は石切工が岩石を叩くのを見に行
    く。おそらく100回叩いても亀裂さえできないだろう。しかしそれで
    も100と1回目で真っ二つに割れることもある。私は知っている。
    その最後の一打により岩石は割れたのではなく、それ以前に叩
    いたすべてによることを。
    Pounding the rocks

    View full-size slide

  202. 217
    レガシーから目をそらすな!

    View full-size slide

  203. @hanhan1978
    相談・指摘・その他 
    下記のTwitterアカウントにどうぞ
    218

    View full-size slide