1 「コードがむずかしい」からの脱却 2023/11/22 コード品質向上のいろは 先達に学ぶ実践例 Lunch LT @jimpei

2 
 SIer -> Yahoo! JAPAN -> mercari (2021/08) 
 
 Help Center Team
 Software Engineer / Tech Lead
 
 福岡に住んでます
 
 濱村 甚平(@jinpeih)


3 「コードがむずかしい」は伝わるか 今日話すこと 「コードがむずかしい」と向き合う 02 01

4 「コードがむずかしい」と 思ったことありますか？

5 コードがむずかしいととにかくツラい 苦しんでいるのは自分だけか・・・？ 仕様理解に時間がかかる 壊れないか心配 むずかしいコードは テストもむずかしい あたらしいプロジェクト、チーム、案件に入ったとき どこに手を入れたら いいのかわからない

6 コードがむずかしくてツラいのは自分だけか ● 不具合：15倍 ● 問題解決にかかる時間：124% ● サイクルタイムは最大：9倍 “By analyzing activity in 30,737 files, we find that low quality code contains 15 times more defects than high quality code.” 
 
 “Furthermore, resolving issues in low quality code takes on average 124% more time in development. ” 
 
 “Finally, we report that issue resolutions in low quality code involve higher uncertainty manifested as 9 times longer maximum cycle times. ” 
 Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases 
 コードがむずかしいと生産性が低くなる

7 エンジニアもツラい(定性) ビジネス影響も出ている コードがむずかしいとみんなつらい では改善だ!

8 エンジニアもツラい(定性) ビジネス影響も出ている コードがむずかしいとみんなつらい では改善だ! → 伝わる...?

9 「コードがむずかしい」は伝わるか → 指標が必要...! ＞「やばいので改善時間をください！」 どれくらい むずかしいの？ やる意味あるの？ そう思ってるだけでは？ いつまでやるの？

10 コードがむずかしいを指標化する ● LOC(Lines Of Code)や循環的複雑度(Cyclomatic Complexity)など様々 ● 認知的複雑度(Cognitive Complexity)を使う ○ 簡単に言うと、人がコードを理解する難しさの尺度 ○ 循環的複雑度がロジカルな難しさ ■ メソッドを完全にカバーするために必要なテストケースの最小数 ○ 簡単にいうと、ネストに重きをおいて加算されていく https://www.sonarsource.com/resources/cognitive-complexity/

11 認知的複雑度を計測する ● 方法はたくさんある ○ SonarQube, CodeClimate, gocognit… 自チームの事例
 ●CI(golangci-lint)で循環的・認知的複雑度が30以上だと落ちるようにしている 
 ●golangci-lintのdefaultは30. 推奨は10-20(1functionあたり 
 ●自チームだとほぼ10以下に収まっている 


12 認知的複雑度を計測する ● 方法はたくさんある ○ SonarQube, CodeClimate, gocognit… 自チームの事例
 ●CI(golangci-lint)で循環的・認知的複雑度が30以上だと落ちるようにしている 
 ●golangci-lintのdefaultは30. 推奨は10-20(1functionあたり 
 ●自チームだとほぼ10以下に収まっている 
 数値をGETしたぞ！これが「むずかしさ」の正体だ！

13 認知的複雑度を計測する ● 方法はたくさんある ○ SonarQube, CodeClimate, gocognit… 自チームの事例
 ●CI(golangci-lint)で循環的・認知的複雑度が30以上だと落ちるようにしている 
 ●golangci-lintのdefaultは30. 推奨は10-20(1functionあたり 
 ●自チームだとほぼ10以下に収まっている 
 数値をGETしたぞ！これが「むずかしさ」の正体だ！ → ほんとか...?

14 注意：定量化すると急に目線が近くなってしまう ● まずは数値を見ながら、課題を探してみる ○ 「大量のif文がたくさん並んでる！分割だ！」ではない 数値化されたからといって、いきなり数値を下げようとしない それよりもネストして理解しづらいコードと向き合う ● LOCも一緒に見れるとよいかもしれない バグが起こりやすく更新頻度の高いホットスポットから見ていくのが効率 ● めったに触らないコードを改善してもうまみは少ない

15 注意：指標はハックできる ● 下げようと思えば、関数を分割しまくればよい ● ただし、そうしてできるのは ○ 「複雑度の低いとても複雑なコード」 複雑度もハックできる

16 指標との向き合い方 ● 複雑度の数値が低くすることが目標ではなく、コードがむずかしいことからの脱 却が目標 ■ そして、コード品質をあげて早く安全に開発する ● あくまでなりたい姿が大事 ○ 数値は健康診断や補助に使う ● その上でコミュニケーションに使う 目標を取り違えない グッドハートの法則 　「ある指標が目標になると、それは良い指標ではなくなる」 https://en.wikipedia.org/wiki/Goodhart%27s_law

17 「コードがむずかしい」と向き合う

18 コードがむずかしいのはなぜか ● その言語化がむずかしいなら、そもそもコードもむずかしい ○ 説明仕様が長いなら、テストコードも複雑になる ● 仕様を言語化してみて、違和感を探る ○ その仕様はどこに書かれているべきなのか ○ その関数内で粒度が揃っているか(適切な抽象化ができているか ○ 過不足なく知ることで、テストも変わる その関数・メソッドの仕様、詳細に言語化できますか？

19 コードがむずかしいのはなぜか ● コメントと関数名で何を表したいのか ● コメントを残すのを恐れない ○ 挙動の説明だなと思うのなら関数名でも表現できるかも ○ なんでその挙動をする必要があるんだっけ？が知りたい ■ その挙動をリファクタしていいのかのヒントにもなる コードに意図はあるか

20 コードがむずかしいのはなぜか ● ふたりでやることによってより明確に意図を共有するようになる ● 意図が共有されれば少なくとも二人の中ではむずかしさは消える ○ その場にいない人や、未来の自分のために意図はコードに埋め込む なんだかんだペアで設計を議論するのが一番効く ひとりで書くのはむずかしい

21 すでにとてもコードがむずかしい状況の場合は？ ● ひとりで取り組まない ○ まずはチームと現状の認識を揃える ● 数値化やホットスポットを見つけて、モブリーディング ○ 共有知識を増やす ○ 意図をコードに残していく(コメントだけでも ● チームの設計力の底上げが必要なら勉強会もあり いきなりリファクタって結構たいへん... これまでの説明って改善策ではなく回避策では

22 まとめ ● 「コードがむずかしい」では伝わらない ○ 認知的複雑度などを定量化してみよう ■ 数値があると話しやすい ■ 数値に囚われすぎない、目標にしない ● 数値を目標にすると、良い目標でなくなる ○ 数値を見ながらコードに向き合い、なりたい姿を定義しよう ● 「コードがむずかしい」状態にならないために ○ 数値を見ながら、理由を探ろう ■ 仕様の言語化 ■ 意図を残す ■ ペアプロで設計について議論する ○ できるところから意図を残していこう ●

23 おわり ありがとうございました！