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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

🥅ゴール 2 みなさんがチーム内で良いコード保守性設計原則について話し合うきっかけになれたら

Slide 3

Slide 3 text

今日の話 3 そうだ、について認識を合わせよう良いコード保守性設計原則私たちのチームがとした話

Slide 4

Slide 4 text

🙋「良いコード」を書きたいですか？ 4

Slide 5

Slide 5 text

🙋リファクタリングしていますか？ 5

Slide 6

Slide 6 text

私たちもリファクタリングしています 6

Slide 7

Slide 7 text

🤔そういえば、私たちは何を目指してリファクタリングしているんだっけ 7

Slide 8

Slide 8 text

󰳕私たちは「良いコード」を目指してリファクタリングしています 8

Slide 9

Slide 9 text

🤔私たちが目指している「良いコード」とは？ 9

Slide 10

Slide 10 text

🤔 10

Slide 11

Slide 11 text

🤔 11

Slide 12

Slide 12 text

🤔 12

Slide 13

Slide 13 text

🚩そうだ、「良いコード」について認識を合わせよう 13

Slide 14

Slide 14 text

私たちが目指している良いコードとは？ 14 リファクタリングしやすいテストしやすい疎結合

Slide 15

Slide 15 text

ソフトウェアの品質特性から考えてみる 15 ● システム・ソフトウェア製品品質モデル（JIS X 25010） ○ 機能適合性 ○ 性能効率性 ○ 互換性 ○ 使用性 ○ 信頼性 ○ セキュリティ ○ 保守性 ○ 移植性 📖参照:　IPA『つながる世界のソフトウェア品質ガイド』

Slide 16

Slide 16 text

ソフトウェアの品質特性から考えてみる 16 ● システム・ソフトウェア製品品質モデル ○ 保守性 ■ モジュール性 / 再利用性 / 解析性 / 修正性 / 試験性変更しやすいテストしやすい疎結合

Slide 17

Slide 17 text

🤔保守性の良いコードとは？ 17

Slide 18

Slide 18 text

🤔 18

Slide 19

Slide 19 text

🤔 19

Slide 20

Slide 20 text

🤔 20

Slide 21

Slide 21 text

💡そうだ、保守性について認識を合わせよう 21 🚩「良いコード」 ↑

Slide 22

Slide 22 text

保守性の良いコードとは？ちょっと寄り道 ➥パフォーマンスの良いコードとは？ 22

Slide 23

Slide 23 text

線形探索と二分探索を例に 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

Slide 24

Slide 24 text

パフォーマンスを解析してみる 24 20ms ⏱ 1ms👑 O(N) ✏ O(logN)👑 実行してみる vs 計算量を分析してみる

Slide 25

Slide 25 text

パフォーマンス動的解析 ◯（実行時間）静的解析 ◯（計算量）パフォーマンスは解析できる 25

Slide 26

Slide 26 text

パフォーマンス保守性動的解析 ◯（実行時間） △ 静的解析 ◯（計算量） 🤔 保守性は解析できる？ 26 フィードバックループが長いこれを探したい

Slide 27

Slide 27 text

保守性は解析できそう 27 パフォーマンス保守性動的解析 ◯（実行時間） △ 静的解析 ◯（計算量） 💡設計原則（との適合度）

Slide 28

Slide 28 text

設計原則 28 ● 保守性につながる設計の経験則 ○ 保守性を分析し、言語化するツール ○ 保守性を高める指針 ● いろいろある📚 ● 抽象度が高い🌀

Slide 29

Slide 29 text

💡そうだ、設計原則について認識を合わせよう 29 🚩「良いコード」 ↑ 保守性 ↑

Slide 30

Slide 30 text

● 読み合わせ式 ○ 社内研修資料の振り返り ■ テストとリファクタリングのワークショップ[1] ○ 解説記事など ■ SOLID原則完全に理解した！になるための本 ■ 7つの設計原則とオブジェクト指向プログラミング 30 勉強会を開いた 👉 [1] ワークショップの様子はこちらの記事で紹介されていますリファクタリングを文化にする〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog

Slide 31

Slide 31 text

● 抽象度の高い原則を読み解くため、できるだけ掘り下げた ● 自分たちのコードベースと業務に照らし合わせてみた 31 設計原則の読み合わせ方なにがうれしい？つまり？例えばこのコードのこと？ここは単一責任原則を守られていない？

Slide 32

Slide 32 text

● 読んだだけでは「さじ加減」がわからない ○ 単一責任の原則 → 責任の単位は？ ○ DRY → 重複の判定基準は？行数？[1] ● 感覚を身につけるには実践が必要 ○ リファクタリング！ 32 原則から実践へ ⛳ 🏌 💪? 📖[1] Read more: Google Testing Blog: Don't DRY Your Code Prematurely

Slide 33

Slide 33 text

● 違和感を感じたら「リファクタリングチケット」に追記 ● 例えば ○ テストが長い ■ 💡テスト対象が責任を持ちすぎ？密結合になっている？ ○ 機能追加するのに変更しないといけないレイヤーが多い ■ 💡レイヤーの分け方が不適切？抽象化しすぎ？ 33 リファクタリングの対象を追跡する

Slide 34

Slide 34 text

● 定期リファクタリング ○ リファクタリングチケットにストーリーポイントを割り当てる ● 予備のためのリファクタリング[1] ○ 綺麗にしてから拡張/変更を加える 34 リファクタリングの時間を作る 📖[1] Read more: リファクタリング（第 2版）既存のコードを安全に改善する

Slide 35

Slide 35 text

まとめ ● 「良いコード」→保守性→設計原則 ○ という道をたどって認識を合わせた ● 設計原則🔁リファクタリング ○ 設計原則がリファクタリングの指針となった ○ リファクタリングで設計原則の理解を深めた 35

Slide 36

Slide 36 text

36 みなさんもチーム内でについて話し合ってみませんか？良いコード保守性設計原則