Tweet
Tweet

Slide 1

Slide 1 text

新卒から4年間、20年もののWebサービスと 向き合って学んだソフトウェア考古学 株式会社 CARTA HOLDINGS ⼩栗 ⼤輝 / ぐり（X: @_guri3） PHPerKaigi 2025 day2 Track C 2025.03.23 13:00

Slide 2

Slide 2 text

株式会社CARTA HOLDINGS ⼩栗 ⼤輝 ぐり X: @_guri3 略歴 ● 2020年新卒⼊社 ● 20年もののWebサービスのリアーキテクチャ プロジェクト 関連書籍 過去スライド 配属⾯談にて レガシーシステムの改善をやってる チームがあるんだけど、どう？ 面白そう！やってみます！ CARTA本 第3章 「VOYAGE MARKETING 20年級大規模レガシーシステムとの戦い」 に登場する話と地続きのお話

Slide 3

Slide 3 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービス「ECナビ」

Slide 4

Slide 4 text

20年もののWebサービスの中⾝って どんな感じ？

Slide 5

Slide 5 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている ● Perlで書かれた旧システムとPHPで書かれた新システム ● Oracle DatabaseとMySQLの共存 ● 年代によって変わる実装方針の混在 ● テストコードが存在しない

Slide 6

Slide 6 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている ● Perlで書かれた旧システムとPHPで書かれた新システム ● Oracle DatabaseとMySQLの共存 ● 年代によって変わる実装方針の混在 ● テストコードが存在しない 2つの言語を行き来しつつ理解。 PHPでも10年前のコードはずいぶん書き味が違うな...

Slide 7

Slide 7 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている ● Perlで書かれた旧システムとPHPで書かれた新システム ● Oracle DatabaseとMySQLの共存 ● 年代によって変わる実装方針の混在 ● テストコードが存在しない こっちのテーブルはOracle、あっちのテーブルはMySQL。 頭が混乱するよ〜

Slide 8

Slide 8 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている ● Perlで書かれた旧システムとPHPで書かれた新システム ● Oracle DatabaseとMySQLの共存 ● 年代によって変わる実装方針の混在 ● テストコードが存在しない 手続き的に書かれているコードもあればオブジェクト指向的に書かれているコードもある。 フレームワークなんてありません。スクリプトのmain関数実行！！とか

Slide 9

Slide 9 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 様々な年代に書かれたコードや技術選定の結果が並行運用されている ● Perlで書かれた旧システムとPHPで書かれた新システム ● Oracle DatabaseとMySQLの共存 ● 年代によって変わる実装方針の混在 ● テストコードが存在しない ガードレールがないので、変更によってどこが壊れるかわからない不安が常に付きまとう

Slide 10

Slide 10 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 古いコードほどなぜそう作ったのか？という理由を追うのが難しい ● 似たような機能をもった複数の管理画面 ● 抽象化されていると思ったら個別の実装も存在していたり ● コメントにドキュメントへのリンクが！

Slide 11

Slide 11 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 古いコードほどなぜそう作ったのか？という理由を追うのが難しい ● 似たような機能をもった複数の管理画面 ● 抽象化されていると思ったら個別の実装も存在していたり ● コメントにドキュメントへのリンクが！ どちらかに統合するつもりだった？ 別々の要件を満たすために必要だった？

Slide 12

Slide 12 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 古いコードほどなぜそう作ったのか？という理由を追うのが難しい ● 似たような機能をもった複数の管理画面 ● 抽象化されていると思ったら個別の実装も存在していたり ● コメントにドキュメントへのリンクが！ リファクタリングをやり切れなかった？ 追加の仕様に対応する必要があった？

Slide 13

Slide 13 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 20年もののWebサービスの中⾝ 古いコードほどなぜそう作ったのか？という理由を追うのが難しい ● 似たような機能をもった複数の管理画面 ● 抽象化されていると思ったら個別の実装も存在していたり ● コメントにドキュメントへのリンクが！ 切れてます...😭

Slide 14

Slide 14 text

ただコードを読むだけでも⼤変

Slide 15

Slide 15 text

でも、理解しないことには どう直せば良いかわからない

Slide 16

Slide 16 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 リアーキテクチャにおいて、既存システムの把握は重要 ● 既存の問題点を正しく認識しないと改善に繋がらない ○ 何を解決すれば現状よりよくなったと言える？ ○ 表面的なコードだけでなくなぜそうなっているのかの意図も重要 ● 開発時のスコープや設計方針の意思決定の材料 ○ 今ある資産はどこまで使える？ → 開発工数に大きく影響する ● ビジネスロジックの抜け漏れが起きかねない ○ 移行後のシステムでは業務が回せない！？なんてことにも

Slide 17

Slide 17 text

古いコードベースを どうやって理解していく？

Slide 18

Slide 18 text

ソフトウェア考古学

Slide 19

Slide 19 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ソフトウェア考古学 “正確なドキュメントがない場合、または知識のある人にアクセスできな い場合、最後の手段は、ジョブ制御言語 (JCL) などのシステムを呼び出す コードを含む、レガシーシステムのソースコードを分析することです。 この作業は、ソフトウェア考古学と呼ばれることがよくあります。” Agile Legacy System Analysis and Integration Modeling https://agilemodeling.com/essays/agileLegacyIntegrationModeling.htm

Slide 20

Slide 20 text

ソフトウェア考古学 古いコードベースを読み解き 当時の設計思想や変化の過程を知ること =

Slide 21

Slide 21 text

AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？

Slide 22

Slide 22 text

AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？

Slide 23

Slide 23 text

古いコードベースの改善はなぜ必要？

Slide 24

Slide 24 text

01. 古いコードベースの改善はなぜ必要？ 古いコードベースの改善はなぜ必要？ 以下のような問題を引き起こす ● 開発のアジリティの低下 ● 影響範囲が不明瞭なことによる予期せぬバグ

Slide 25

Slide 25 text

01. 古いコードベースの改善はなぜ必要？ 開発のアジリティの低下 ビジネスの問題を素早く解決出来なくなる こういう機能を追加して欲しいのですが... 誰もわからないので、調査からになりますね... 工数もやってみないとわかりません...

Slide 26

Slide 26 text

01. 古いコードベースの改善はなぜ必要？ 影響範囲が不明瞭なことによる予期せぬバグ こんなところが壊れるの！？ メソッドに型定義を付けたら予想外のところで使われててエラー

Slide 27

Slide 27 text

01. 古いコードベースの改善はなぜ必要？ 影響範囲が不明瞭なことによる予期せぬバグ こんなところが壊れるの！？ CARTA本 第5章 「サポーターズ 事業を止めない手段としてのシステム刷新」 “部屋のドアノブを回すと風呂の底が抜ける”

Slide 28

Slide 28 text

他にも様々な困りごとがありますが

Slide 29

Slide 29 text

01. 古いコードベースの改善はなぜ必要？ 古いコードベースは雪だるま式に難しくなる ● 様々な都合で理想の形に持っていけない場合もある ● どこかのタイミングで対応しないとどんどん難しくなる ● さらに手を入れづらくなり、場当たり的な対応 しか出来なくなるというループに陥る

Slide 30

Slide 30 text

01. 古いコードベースの改善はなぜ必要？ 古いコードベースの改善はなぜ必要？ ● そりゃそうだよね、と思われるかもしれません ● なぜわざわざ確認したかというと ○ 色々あって大変&基本的に長期戦 ○ やる意味が腹落ちしてないとどんどんスピード感が失われる ○ 最初にやる意味を明確にする&迷う時があれば何度も立ち返る

Slide 31

Slide 31 text

AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？

Slide 32

Slide 32 text

古いコードベースを理解するのは なぜ難しい？

Slide 33

Slide 33 text

⾃⾝の持つメンタルモデルとの乖離が ⼤きい‧多い

Slide 34

Slide 34 text

02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデル “メンタルモデルは、目の前の問題について推論するために、 ワーキングメモリの中で概念を抽象化するものである” プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ 6.2 メンタルモデル

Slide 35

Slide 35 text

02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルのこのトークでの解釈 “メンタルモデルは、目の前の問題について推論するために、 ワーキングメモリの中で概念を抽象化するものである” プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ 6.2 メンタルモデル 過去の経験や一般的な設計パターンなどに基づいて形成された 自身のコードに対する認識や解釈、期待

Slide 36

Slide 36 text

メンタルモデルと実際のコードとの 乖離が⼤きいほど理解が難しくなる

Slide 37

Slide 37 text

例えば

Slide 38

Slide 38 text

02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルと実コードの乖離の例 その1 メンタルモデル この関数はget〇〇という名前がついているからデータを取得するだけだ

Slide 39

Slide 39 text

02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルと実コードの乖離の例 その1 メンタルモデル この関数はget〇〇という名前がついているからデータを取得するだけだ 実際は... 副作用のある登録処理や更新処理が内部で動いていた

Slide 40

Slide 40 text

02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルと実コードの乖離の例 その2 メンタルモデル オブジェクト指向をベースに設計・実装されているだろう

Slide 41

Slide 41 text

02. 古いコードベースを理解するのはなぜ難しい？ メンタルモデルと実コードの乖離の例 その2 メンタルモデル オブジェクト指向をベースに設計・実装されているだろう 実際は... 手続き型の考え方で設計・実装されている

Slide 42

Slide 42 text

02. 古いコードベースを理解するのはなぜ難しい？ 古いコードベースにおけるメンタルモデルの乖離 古いコードベースにおいてメンタルモデルと実コードの乖離は 大きくなりやすく、乖離が起こるタイミングも多い なぜ...？20年もののWebサービスの中身を振り返ると ● 様々な年代に書かれたコードや技術選定の結果が並行運用されている ● 古いコードほどなぜそう作ったのか？という理由を追うのが難しい

Slide 43

Slide 43 text

02. 古いコードベースを理解するのはなぜ難しい？ 古いコードベースにおけるメンタルモデルの乖離 古いコードベースにおいてメンタルモデルと実コードの乖離は 大きくなりやすく、乖離が起こるタイミングも多い なぜ...？20年もののWebサービスの中身を振り返ると ● 様々な年代に書かれたコードや技術選定の結果が並行運用されている ● 古いコードほどなぜそう作ったのか？という理由を追うのが難しい 様々なコンテキストが入り混じっている

Slide 44

Slide 44 text

古いコードベースを理解するのは なぜ難しい？ ⾃⾝の持つメンタルモデルとの乖離が ⼤きい、多い =

Slide 45

Slide 45 text

古いコードベースに合わせて メンタルモデルを 構築する‧柔軟に切り替える

Slide 46

Slide 46 text

AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？

Slide 47

Slide 47 text

具体的な進め⽅

Slide 48

Slide 48 text

03. 具体的な進め方 素直に読み進めると時間がたくさん掛かる 具体的にどういう仕事があったか ● Webメディアの広告運用管理画面改修 ○ 同じような管理画面が複数存在して差分を特定するのも一苦労 ● Perlの旧基盤のバッチ処理をPHPの現行基盤に移行 ○ Perl ↔ PHPで頭を切り替えながら作業を進める必要がある ○ 古いバッチは実装の考え方が今と違ったりする

Slide 49

Slide 49 text

⿃の⽬と⾍の⽬ 問題を解くこと https://blog.kentasuzuki.net/2017/04/blog-post_12.html

Slide 50

Slide 50 text

03. 具体的な進め方 ⿃の⽬ 俯瞰して依存関係などの全体構造を把握する

Slide 51

Slide 51 text

03. 具体的な進め方 ⾍の⽬ コード1行1行レベルの詳細を把握する

Slide 52

Slide 52 text

03. 具体的な進め方 メンタルモデルを構築するアプローチ 鳥の目と虫の目を使って全体構造と詳細を行き来することで 古いコードベースのメンタルモデルを構築 全体構造 詳細 新たなメンタルモデル の構築

Slide 53

Slide 53 text

03. 具体的な進め方 メンタルモデルを構築するアプローチ 読み取った事実や構築したメンタルモデルは成果物としてアウトプット

Slide 54

Slide 54 text

03. 具体的な進め方 メンタルモデルを構築するアプローチ 読み取った事実や構築したメンタルモデルは成果物としてアウトプット “メンタルモデルは、目の前の問題について推論するために、 ワーキングメモリの中で概念を抽象化するものである”

Slide 55

Slide 55 text

03. 具体的な進め方 メンタルモデルを構築するアプローチ 読み取った事実や構築したメンタルモデルは成果物としてアウトプット “メンタルモデルは、目の前の問題について推論するために、 ワーキングメモリの中で概念を抽象化するものである” わかったことは頭の中から外に出すと、また別の領域や さらに複雑な構造などを把握するのにリソースを使える

Slide 56

Slide 56 text

03. 具体的な進め方 メンタルモデルを構築するアプローチ 読み取った事実や構築したメンタルモデルは成果物としてアウトプット これこそがソフトウェア考古学の成果

Slide 57

Slide 57 text

⿃の⽬で全体構造を把握する

Slide 58

Slide 58 text

03. 具体的な進め方 ⿃の⽬で全体構造を把握する ● 依存関係などから大きな構造を読み解く ● データのインプット / アウトプットの把握 ● システムの変化や時の流れを観察する

Slide 59

Slide 59 text

03. 具体的な進め方 依存関係などから⼤きな構造を読み解く ● まずはなるべく大きな構造を読み解く ○ 例えばクラスの依存関係やパブリックなインターフェースなど ○ 何もわからない状態から輪郭を作っていく ■ 規模感・複雑さ・重要な処理が書かれていそうなところ

Slide 60

Slide 60 text

依存関係などから大きな構造を読み解く @startuml class HogeController { } @enduml コントローラーなどのわかりやすい エンドポイントから始める

Slide 61

Slide 61 text

依存関係などから大きな構造を読み解く @startuml namespace Controller { class HogeController { } } namespace Function1 { class ServiceFactory { } interface ServiceInterface { } namespace Hoge { class HogeService { } } namespace Poyo { class PoyoService { } } } HogeController ..> ServiceFactory ServiceFactory --> ServiceInterface HogeService --|> ServiceInterface ~~~ @enduml わかりやすいデザインパターン(Factory) どういう意図で設計したんだろう？

Slide 62

Slide 62 text

依存関係などから大きな構造を読み解く @startuml namespace Controller { class HogeController { } } namespace Function1 { class ServiceFactory { } interface ServiceInterface { } namespace Hoge { class HogeService { } } namespace Poyo { class PoyoService { } } } HogeController ..> ServiceFactory ServiceFactory --> ServiceInterface HogeService --|> ServiceInterface ~~~ @enduml あー、この辺を抽象化して実行時に使い分け したかったんだなー

Slide 63

Slide 63 text

依存関係などから大きな構造を読み解く：成果物の例

Slide 64

Slide 64 text

03. 具体的な進め方 データのインプット / アウトプットの把握 ● バッチ処理の場合特に有効（自分の場合はPerl→PHPへの移行） ● 表面的な画面があるわけでは無いのでパブリックなインターフェース としてデータのインプット・アウトプットから把握するのが有効 ● どういったデータが入って、作り出すことを目的としているのか ○ どのテーブルからどのテーブル？ ○ データの内容

Slide 65

Slide 65 text

03. 具体的な進め方 データのインプット / アウトプットの把握 キャンペーンに参加したユーザーから抽選して当選ユーザーを決める インプット なんらかの処理 アウトプット

Slide 66

Slide 66 text

03. 具体的な進め方 データのインプット / アウトプットの把握 キャンペーンに参加したユーザーから抽選して当選ユーザーを決める インプット なんらかの処理 アウトプット users、campaigns、campaign_participationsテーブルから取得

Slide 67

Slide 67 text

03. 具体的な進め方 データのインプット / アウトプットの把握 キャンペーンに参加したユーザーから抽選して当選ユーザーを決める インプット なんらかの処理 アウトプット 途中のゴニョゴニョは無視

Slide 68

Slide 68 text

03. 具体的な進め方 データのインプット / アウトプットの把握 キャンペーンに参加したユーザーから抽選して当選ユーザーを決める インプット なんらかの処理 アウトプット winning_usersテーブルに保存

Slide 69

Slide 69 text

03. 具体的な進め方 データのインプット / アウトプットの把握 ● インプットとアウトプットの情報を元にER図を書き起こす ● テーブル間の関係性に注目 ○ ECナビの古いテーブルには外部キーが存在しない😭 ■ IDEで出力したりしても何もわからない ○ 命名や、データの入力時の挙動などで関係性を想像して書く

Slide 70

Slide 70 text

03. 具体的な進め方 データのインプット / アウトプットの把握：成果物の例

Slide 71

Slide 71 text

03. 具体的な進め方 システムの変化や時の流れを観察する ● （あれば）Gitのblameをざっと眺める ○ 最近まで変更が加えられている部分 ○ 最初に作られたところからずっと変わってなさそうな部分 ● どこに柔軟性が必要なのかをシステムの変化から学べる

Slide 72

Slide 72 text

⾍の⽬で詳細を把握する

Slide 73

Slide 73 text

03. 具体的な進め方 ⾍の⽬で詳細を把握する ● プリントデバッグとデバッグツール ● リファクタリングをしてみる ● コードの深堀りと枝切りの判断

Slide 74

Slide 74 text

03. 具体的な進め方 プリントデバッグとデバッグツール ● パブリックなインターフェースからさらに一歩踏み込んで処理を追う ● 成果物はプログラムの詳しい挙動を記した文書やシーケンス図など

Slide 75

Slide 75 text

03. 具体的な進め方 プリントデバッグとデバッグツール if文ひとつとっても正しく理解できているか自信が持てない ● 仕様の追従のために条件が追加され組み合わせが膨大だったり どういう意図で追加された？ 今も必要？ ただ読み進めるだけではすぐに迷子になってしまう

Slide 76

Slide 76 text

03. 具体的な進め方 プリントデバッグとデバッグツール ● 脳内インタプリタで実行 ● var_dumpなどを利用して特定の値の遷移を知る ● PsySHやXdebugなどのデバッグツールを利用 読み進めるスピード（や手間）とどこまで詳細を追うかで使い分ける

Slide 77

Slide 77 text

03. 具体的な進め方 プリントデバッグとデバッグツール 使い分けイメージ 詳細度 低 遅 速 高 スピード 脳内インタプリタで実行 手軽で速いが詳細を追ってくと認知負荷が高い

Slide 78

Slide 78 text

03. 具体的な進め方 プリントデバッグとデバッグツール 使い分けイメージ 詳細度 低 遅 速 高 スピード var_dumpなどを利用して特定の値の遷移を知る 少し手間が増えるがより詳細を追うことができる

Slide 79

Slide 79 text

03. 具体的な進め方 プリントデバッグとデバッグツール 使い分けイメージ 詳細度 低 遅 速 高 スピード PsySHやXdebugなどのデバッグツールを利用 プロジェクトによっては下準備が必要 さらに詳細を追うことができる

Slide 80

Slide 80 text

03. 具体的な進め方 プリントデバッグとデバッグツール ● 脳内インタプリタで実行 　　　　　　↓ 頭の中だけでは把握し切れない ● var_dumpなどを利用して特定の値の遷移を知る ↓ 特定の場面の複数の状態が絡み合っている ● PsySHやXdebugなどのデバッグツールを利用 メンタルモデルとズレていればいるほど より詳細を追いすり合わせることが必要

Slide 81

Slide 81 text

03. 具体的な進め方 プリントデバッグとデバッグツール ● 脳内インタプリタで実行 　　　　　　↓ 頭の中だけでは把握し切れない ● var_dumpなどを利用して特定の値の遷移を知る ↓ 特定の場面の複数の状態が絡み合っている ● PsySHやXdebugなどのデバッグツールを利用 使い慣れているツールがあればあまり変わらないかも どの程度メンタルモデルとのずれが生じているかを意識することが大事

Slide 82

Slide 82 text

03. 具体的な進め方 リファクタリングをしてみる 手を動かせそうならリファクタリングをしてコードに触れてみる “試行リファクタリング” レガシーコード改善ガイド P226 - 227

Slide 83

Slide 83 text

03. 具体的な進め方 リファクタリングをしてみる 手を動かせそうならリファクタリングをしてコードに触れてみる “試行リファクタリング” レガシーコード改善ガイド P226 - 227 明らかなデッドコードを削除してみたり リリースは出来なくてもOK。出来たら嬉しいけど

Slide 84

Slide 84 text

03. 具体的な進め方 コードの深堀りと枝切りの判断 どこまでコードを深ぼるか？究極は目的による 自分のイメージでは 意思決定に必要な情報が揃うまで なぜそうなっているのかを「自分の言葉で説明できる」

Slide 85

Slide 85 text

03. 具体的な進め方 コードの深堀りと枝切りの判断 どこまでコードを深ぼるか？究極は目的による 知りたい情報の粒度に合わせて枝切りをする ● 今は〇〇機能の依存関係だけ明らかにしよう → 実装の詳細は気になっても追わない ● 「鳥の目」「虫の目」で自分が今何を理解しようとしているのか？ を常に意識

Slide 86

Slide 86 text

⾏ったり来たりしながら理解を深める

Slide 87

Slide 87 text

03. 具体的な進め方 ⾏ったり来たりしながら理解を深める 鳥の目: ざっとみたときに似たような管理画面が複数ある。なぜ？

Slide 88

Slide 88 text

03. 具体的な進め方 ⾏ったり来たりしながら理解を深める 鳥の目: ざっとみたときに似たような管理画面が複数ある。なぜ？ 虫の目: 詳細なコードを追うと、新たな仕様追加に追従した形跡がある

Slide 89

Slide 89 text

03. 具体的な進め方 ⾏ったり来たりしながら理解を深める 鳥の目: ざっとみたときに似たような管理画面が複数ある。なぜ？ 虫の目: 詳細なコードを追うと、新たな仕様追加に追従した形跡がある 鳥の目: ざっとみたときに似たような管理画面が複数ある。これは、追加 された仕様に新たに対応するために生まれた画面だ。

Slide 90

Slide 90 text

03. 具体的な進め方 ⾏ったり来たりしながら理解を深める 鳥の目: ざっとみたときに似たような管理画面が複数ある。なぜ？ 虫の目: 詳細なコードを追うと、新たな仕様追加に追従した形跡がある 鳥の目: ざっとみたときに似たような管理画面が複数ある。これは、追加 された仕様に新たに対応するために生まれた画面だ。 行き来することで設計思想や変化の過程を読み取ることができる

Slide 91

Slide 91 text

AGENDA 02 古いコードベースを理解するのはなぜ難しい？ 03 04 具体的な進め⽅ ソフトウェア考古学の経験から学んだこと 01 古いコードベースの改善はなぜ必要？

Slide 92

Slide 92 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ソフトウェア考古学の経験から学んだこと ● 規模の大きいシステムは愚直に読んでいくだけでは理解できない ○ 自分の思い込みなどの積み重ねが理解を困難にしたり 誤った理解に繋がる ○ 鳥の目・虫の目を意識したコードリーディングを活用することで 自身のメンタルモデルをすり合わせながら意図や背景を明らかに していく

Slide 93

Slide 93 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ソフトウェア考古学の経験から学んだこと ● 理解しやすいコードを書くコツ ○ 前提としてあるべき姿に常にシステムが追従しているのが一番 ○ 歴史を学ぶ中で変更が多い場所、作ったきり変更されにくい 場所がだんだんわかってくる ■ 最初から変更を考慮した設計にできれば設計思想の乖離 が起こりづらい

Slide 94

Slide 94 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ソフトウェア考古学の経験から学んだこと ● 意思決定の記録が残っているとわかりやすい ○ 常に最新に更新されているドキュメントでなくても良い ○ 詳しく仕様が書いてあるよりもなぜそうしたか？の方が大事 ● メンタルモデルにずれが発生しそうな部分への予防 ○ どうしても根本対応仕切れなかった仕様改修箇所に積極的にコメントを書く

Slide 95

Slide 95 text

最後に

Slide 96

Slide 96 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 最後に 続く調査や新規開発への憧れなどでモチベーションが下がることも... ● 今まで紡がれてきたものをより良い形に直してさらに長く価値を提供 できるようにする大事な仕事 ○ 「レガシー」には後世に引き継がれる価値というポジティブな 意味合いもあるそう ● そもそも考古学が必要になるまで成長しているサービスはすごい

Slide 97

Slide 97 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 最後に ソフトウェア考古学って大変なイメージ（自分がそうでした）ですが、 今回のトークで自分でもできそう！というイメージを持って少しでも やってみようかな〜と思ってもらえると嬉しいです

Slide 98

Slide 98 text

No day but TODAY CARTA HOLDINGSについて 約 53% 電 通 （株） VOYAGE GROUP 約 47% 既存株主 事業例 サービス例 CARTA HOLDINGSについて

Slide 99

Slide 99 text

新卒から 4年間、 20年ものの Webサービスと向き合って学んだソフトウェア考古学 ありがとうございました ● ビジネスの要求に対応するためには古いコードの改善が必要 ● 自身の持つメンタルモデルとのずれがコードの理解を難しくする ● 「鳥の目」で全体把握、「虫の目」で詳細を把握 ● ソフトウェア考古学で変更の傾向を学ぶことができる 学んだことを設計に反映する ● 意思決定についてのスナップショットが有効 メンタルモデルとの乖離や驚きが生まれそうなところに コメントが補足されていると理解しやすい