「良いコード」を探し求めて

2024/12/11開催
~モノタロウ式~ドメインモデリングとリアーキテクチャ Vol.2

Transcript

1. 「良いコード」を探し求めて ～開発現場からお伝えします～ 頼(らい)　SWE@株式会社MonotaRO 1 2024.12.11 LT@MonotaRO Tech Talk © 2020 MonotaRO Co., Ltd. All Rights Reserved.
2. 🥅ゴール 2 みなさんがチーム内で 良いコード 保守性 設計原則 について話し合うきっかけになれたら
3. 今日の話 3 そうだ、 について認識を合わせよう 良いコード 保守性 設計原則 私たちのチームが とした話
4. 🙋「良いコード」を書きたいですか？ 4
5. 🙋リファクタリングしていますか？ 5
6. 私たちもリファクタリングしています 6
7. 🤔そういえば、私たちは何を目指して リファクタリングしているんだっけ 7
8. 󰳕私たちは「良いコード」を目指して リファクタリングしています 8
9. 🤔私たちが目指している「良いコード」とは？ 9
10. 🤔 10
11. 🤔 11
12. 🤔 12
13. 🚩そうだ、「良いコード」について認識を合わせよう 13
14. 私たちが目指している良いコードとは？ 14 リファクタリング しやすい テストしやすい 疎結合
15. ソフトウェアの品質特性から考えてみる 15 • システム・ソフトウェア製品品質モデル（JIS X 25010） ◦ 機能適合性 ◦ 性能効率性 ◦ 互換性 ◦ 使用性 ◦ 信頼性 ◦ セキュリティ ◦ 保守性 ◦ 移植性 📖参照:　IPA『つながる世界のソフトウェア品質ガイド』
16. ソフトウェアの品質特性から考えてみる 16 • システム・ソフトウェア製品品質モデル ◦ 保守性 ▪ モジュール性 / 再利用性 / 解析性 / 修正性 / 試験性 変更しやすい テストしやすい 疎結合
17. 🤔保守性の良いコードとは？ 17
18. 🤔 18
19. 🤔 19
20. 🤔 20
21. 💡そうだ、保守性について認識を合わせよう 21 🚩「良いコード」 ↑
22. 保守性の良いコードとは？ ちょっと寄り道 ➥パフォーマンスの良いコードとは？ 22
23. 線形探索と二分探索を例に 23 def 線形探索(arr: list[int], target: int) -> int: for i in range(len(arr)): if arr[i] == target: return i return -1 def 二分探索(arr: list[int], target: int) -> int: left, right = 0, len(arr) - 1 while left <= right: mid = (left + right) // 2 if arr[mid] == target: return mid if arr[mid] < target: left = mid + 1 else: right = mid - 1 return -1 🎨 Colors: Catppuccin Latte from https://github.com/catppuccin/catppuccin
24. パフォーマンスを解析してみる 24 20ms ⏱ 1ms👑 O(N) ✏ O(logN)👑 実行してみる vs 計算量を 分析してみる
25. パフォーマンス 動的解析 ◯（実行時間） 静的解析 ◯（計算量） パフォーマンスは解析できる 25
26. パフォーマンス 保守性 動的解析 ◯（実行時間） △ 静的解析 ◯（計算量） 🤔 保守性は解析できる？ 26 フィードバック ループが長い これを探したい
27. 保守性は解析できそう 27 パフォーマンス 保守性 動的解析 ◯（実行時間） △ 静的解析 ◯（計算量） 💡設計原則（との適合度）
28. 設計原則 28 • 保守性につながる設計の経験則 ◦ 保守性を分析し、言語化するツール ◦ 保守性を高める指針 • いろいろある📚 • 抽象度が高い🌀
29. 💡そうだ、設計原則について認識を合わせよう 29 🚩「良いコード」 ↑ 保守性 ↑
30. • 読み合わせ式 ◦ 社内研修資料の振り返り ▪ テストとリファクタリングのワークショップ[1] ◦ 解説記事など ▪ SOLID原則完全に理解した！になるための本 ▪ 7つの設計原則とオブジェクト指向プログラミン グ 30 勉強会を開いた 👉 [1] ワークショップの様子はこちらの記事で紹介されています リファクタリングを文化にする 〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog
31. • 抽象度の高い原則を読み解くため、できるだけ掘り下 げた • 自分たちのコードベースと業務に照らし合わせてみた 31 設計原則の読み合わせ方 なにがうれしい？ つまり？ 例えばこのコードのこと？ ここは単一責任原則を守ら れていない？
32. • 読んだだけでは「さじ加減」がわからない ◦ 単一責任の原則 → 責任の単位は？ ◦ DRY → 重複の判定基準は？行数？[1] • 感覚を身につけるには実践が必要 ◦ リファクタリング！ 32 原則から実践へ ⛳ 🏌 💪? 📖[1] Read more: Google Testing Blog: Don't DRY Your Code Prematurely
33. • 違和感を感じたら「リファクタリングチケット」に追記 • 例えば ◦ テストが長い ▪ 💡テスト対象が責任を持ちすぎ？密結合になってい る？ ◦ 機能追加するのに変更しないといけないレイヤーが多い ▪ 💡レイヤーの分け方が不適切？抽象化しすぎ？ 33 リファクタリングの対象を追跡する
34. • 定期リファクタリング ◦ リファクタリングチケットにストーリーポイントを 割り当てる • 予備のためのリファクタリング[1] ◦ 綺麗にしてから拡張/変更を加える 34 リファクタリングの時間を作る 📖[1] Read more: リファクタリング（第 2版） 既存のコードを安全に改善する
35. まとめ • 「良いコード」→保守性→設計原則 ◦ という道をたどって認識を合わせた • 設計原則🔁リファクタリング ◦ 設計原則がリファクタリングの指針となった ◦ リファクタリングで設計原則の理解を深めた 35
36. 36 みなさんもチーム内で について話し合ってみませんか？ 良いコード 保守性 設計原則
37. 37 Thank you!
38. 38 © 2020 MonotaRO Co., Ltd. All Rights Reserved.