Pythonソースコードの構造可視化とそれがもたらすもの

Transcript

1. Pythonソースコードの 構造可視化 とそれがもたらすもの PyCon JP 2020 #pyconjp_2
2. 自己紹介 @yosu 2 years Web App & Crawler 今月まで @ お手伝い @
3. 本日お話すること 背景 見えてくるもの 構造 と その重要性 可視化の 必要性
4. 背景 見えてくるもの 構造 と その重要性 可視化の 必要性 本日お話すること
5. 背景 500ファイル以上あるPythonアプリケーションのPython2/3移行プロジェクト に参加 最初に移行するべき対象を見つけ出すため、簡易的なスクリプトで各パッケージ 間の依存関係を明らかにした。 うまく対象を選び、最初の移行は大きなトラブルもなく無事完了。 他にも、実際に可視化して見ると循環参照のような望ましくない構造や、依存が 多すぎるモジュールなど改善に生かす手がかりが得られることに気づいた。
6. 背景 見えてくるもの 構造 と その重要性 可視化の 必要性
7. 構造とは？
9. 一つの全体を構成する 部分同士の関係性 部分はそれぞれが 役割・責務を持つ
11. 屋根 窓 床 天井 階段
12. 屋根 窓 床 階段 天井 雨を防ぐ
13. 屋根 窓 床 階段 天井 光を通す 雨を防ぐ
14. 屋根 窓 床 階段 天井 光を通す 雨を防ぐ 1階と2階 をつなぐ
15. Python アプリケーション の場合
18. PI = 3.1415926535
19. PI = 3.1415926535 def area(radius): return PI * radius ** 2
20. PI = 3.1415926535 class Circle: def __init__(self, radius): self.radius = radius def area(self): return PI * self.radius ** 2
21. import sys from figure import Circle def main(): radius = float(sys.argv[1]) circle = Circle(radius) print(circle.area())
22. area() PI main() Circle figure 参照 参照 参照 所有 所有 呼出し
23. area() PI main() Circle figure 依存 依存 依存 依存 依存 依存
24. area() PI main() Circle figure 名前が 役割・責務 を表す
25. 依存関係の 特徴
26. A B 依存先 がないと機能しない ❌
27. A B 依存先 の変化で影響を受ける
28. 今回のスコープ
29. 全体を捉えるために、 モジュール同士の 依存関係をみていく
30. jig-py ⚒
31. github.com/levii/jig-py
32. イメージ
33. jig-pyの由来 Java製のコードによる設計支援ツール Jig（irofさん作）に由来。 https://github.com/dddjava/jig 三層+ドメインモデルの アーキテクチャを想定し、 様々な可視化ができる。
34. jig-pyはまだ モジュール関係のみ 可視化
35. 話を戻して ↩
36. なぜ構造に 着目するか？
37. ソフトウェア だから
38. ソフト =柔軟に変化できる ここに価値がある
40. つまりソフトウェアの優位性は、開発サイクルが短く、 アイデアを出してからプロトタイプを作り、エラーを 発見して修正するまでが短時間かつローコストでできる ことにある。 もし設計プロセスで技術者が絶対にミスを犯さないのな ら、ハードウェアもソフトウェアもコストはさほど変わ らないかもしれない。だが実際にはミスは避けられない のだから、何か特別な理由でもない限り、ソフトウェア のほうが好ましいことになる。 ソフトウェアの優位性
41. つまりソフトウェアの優位性は、開発サイクルが短く、 アイデアを出してからプロトタイプを作り、エラーを 発見して修正するまでが短時間かつローコストでできる ことにある。 もし設計プロセスで技術者が絶対にミスを犯さないのな ら、ハードウェアもソフトウェアもコストはさほど変わ らないかもしれない。だが実際にはミスは避けられない のだから、何か特別な理由でもない限り、ソフトウェア のほうが好ましいことになる。 ソフトウェアの優位性 構造が影響を及ぼす
43. リファクタリングとは ソフトウェアの 外部的振る舞いを保ったままで、 内部の構造を改善していく作業のこと。 リファクタリングを行なえば、以前に書いたコードの 設計が向上することになる。
44. わるい構造
45. よい構造 わるい構造
46. よい構造 わるい構造 リファクタリング
47. よい構造 リファクタリング 変更が危険で やっかい 機能追加・バグフィクス が容易 開発スピードが安定 わるい構造
48. よい構造 リファクタリング 変更が危険で やっかい 機能追加・バグフィクス が容易 開発スピードが安定 わるい構造
49. どうやって 構造を みていくか
53. そのままでは 見えにくい
54. 背景 見えてくるもの 構造 と その重要性 可視化の 必要性
56. 単純に可視化 してみると
59. うまく可視化する必要
60. Google Earth
64. Python アプリケーション を探索
75. を使って 探索的に可視化する
76. ① 初期状態
77. ステップ1: 解析・情報収集 "common.bind" -> "common.group.application"; "common.context.builder" -> "common.context.domain"; "event.application.event_history" -> "framework.paginator"; "event.application.repository" -> "event.domain"; "feedback.application.announcement" -> "common.exceptions"; "feedback.application.idea" -> "framework.logging"; "feedback.domain.idea" -> "event.domain"; "feedback.domain.idea" -> "notify.domain.email_builder"; "framework.paginator" -> "framework.logging"; "integration.bind" -> "event.domain.event_handler_setting"; "main" -> "framework"; "main" -> "task.routes"; "notify.application" -> "common.user.application"; "task.domain.notification" -> "common.system_setting.application"; "test_helpers.feedback" -> "common.user.domain";
78. ステップ2: トップレベルに集約 "common.bind" -> "common.group.application"; "common.context.builder" -> "common.context.domain"; "event.application.event_history" -> "framework.paginator"; "event.application.repository" -> "event.domain"; "feedback.application.announcement" -> "common.exceptions"; "feedback.application.idea" -> "framework.logging"; "feedback.domain.idea" -> "event.domain"; "feedback.domain.idea" -> "notify.domain.email_builder"; "framework.paginator" -> "framework.logging"; "integration.bind" -> "event.domain.event_handler_setting"; "main" -> "framework"; "main" -> "task.routes"; "notify.application" -> "common.user.application"; "task.domain.notification" -> "common.system_setting.application"; "test_helpers.feedback" -> "common.user.domain";
79. ステップ2: トップレベルに集約 "common" -> "common"; "common" -> "common"; "event" -> "framework"; "event" -> "event"; "feedback" -> "common"; "feedback" -> "framework"; "feedback" -> "event"; "feedback" -> "notify"; "framework" -> "framework"; "integration" -> "event"; "main" -> "framework"; "main" -> "task"; "notify" -> "common"; "task" -> "common"; "test_helpers" -> "common";
80. ステップ3: 重複の除去 "common" -> "common"; "common" -> "common"; "event" -> "framework"; "event" -> "event"; "feedback" -> "common"; "feedback" -> "framework"; "feedback" -> "event"; "feedback" -> "notify"; "framework" -> "framework"; "integration" -> "event"; "main" -> "framework"; "main" -> "task"; "notify" -> "common"; "task" -> "common"; "test_helpers" -> "common";
81. "common" -> "common"; "event" -> "framework"; "event" -> "event"; "feedback" -> "common"; "feedback" -> "framework"; "feedback" -> "event"; "feedback" -> "notify"; "framework" -> "framework"; "integration" -> "event"; "main" -> "framework"; "main" -> "task"; "notify" -> "common"; "task" -> "common"; "test_helpers" -> "common"; ステップ3: 重複の除去
82. ステップ4: セルフループの削除 "common" -> "common"; "event" -> "framework"; "event" -> "event"; "feedback" -> "common"; "feedback" -> "framework"; "feedback" -> "event"; "feedback" -> "notify"; "framework" -> "framework"; "integration" -> "event"; "main" -> "framework"; "main" -> "task"; "notify" -> "common"; "task" -> "common"; "test_helpers" -> "common";
83. ステップ4: セルフループの削除 "event" -> "framework"; "feedback" -> "common"; "feedback" -> "framework"; "feedback" -> "event"; "feedback" -> "notify"; "integration" -> "event"; "main" -> "framework"; "main" -> "task"; "notify" -> "common"; "task" -> "common"; "test_helpers" -> "common";
84. ステップ5: ビジュアライズ（初期状態準備完了）
85. ② 探索
86. 見たくないものを除去
87. 見たくないものを除去
88. 見たくないものを除去
89. 詳しく見たいものを掘り下げる
90. 詳しく見たいものを掘り下げる
91. 注意
92. 前提として 人に優しい粒度で パッケージ（階層）化 されてないと厳しい
93. デモ
94. 背景 見えてくるもの 構造 と その重要性 可視化の 必要性
95. 特徴的なパターン 依存しかしない： エントリーポイント/ルーター
96. 特徴的なパターン 依存しかしない： エントリーポイント/ルーター 他のモジュールの 呼び分けを行う。 機能的な依存をしない ようにすると、変化の 影響を直接受けない ので怖くない。
97. 特徴的なパターン 依存されるが他への依存が少ない（しない）： アプリケーション基盤、共通部品
98. 特徴的なパターン 依存されるが他への依存が少ない（しない）： アプリケーション基盤、共通部品 変化させにくい部分。 必要とされる概念を きちんとモデリング、 一度作れば変化しなく て済むようにする。
99. 特徴的なパターン 依存されるし、他への依存も多い： ビジネスロジック/コアドメイン
100. 特徴的なパターン 依存されるし、他への依存も多い： ビジネスロジック/コアドメイン アプリケーションの 中核となる部分。 環境やビジネスの変 化に応じて変化して いく。
101. 変 更 頻 度 依存されている数 多 い 少 な い 多い 少ない
102. 変 更 頻 度 依存されている数 多 い 少 な い 多い 少ない アプリケーション基盤 エントリーポ イント ビジネス ロジック
103. 変 更 頻 度 依存されている数 多 い 少 な い 多い 少ない アプリケーション基盤 ビジネス ロジック エントリーポ イント ここを 他と隔離しつつ きちんと保つ ことが重要
104. ☠不吉な匂い
105. 相互依存 / 循環参照 A B
106. 相互依存 / 循環参照 A B
107. 相互依存 / 循環参照 A B
108. 相互依存 / 循環参照 A B
109. 相互依存 / 循環参照 A B
110. 相互依存 / 循環参照 A B
111. 相互依存 / 循環参照 A B
112. 相互依存 / 循環参照 A B
113. 相互依存 / 循環参照
114. 相互依存 / 循環参照
115. 相互依存 / 循環参照
116. 相互依存 / 循環参照
117. 相互依存 / 循環参照
118. たいていは 責務違反
119. 名前がない 隠れた役割を持つ
120. まとめ
121. まとめ 1. 構造とは一つの全体を構成する部分の関係・役割 2. 構造のあり方がソフトウェアの柔軟性に影響を及ぼす　　 （リファクタリングはよい構造を作るための活動） 3. うまく可視化することで構造を捉える 4. 構造の特徴・パターンから中核となる場所を見つけ、そこを きちんと保つことが重要