$30 off During Our Annual Pro Sale. View Details »

「コードがむずかしい」からの脱却

jimpei
November 22, 2023

 「コードがむずかしい」からの脱却

コード品質向上のいろは - 先達に学ぶ実践例 Lunch LT
https://findy.connpass.com/event/300912/

jimpei

November 22, 2023
Tweet

More Decks by jimpei

Other Decks in Programming

Transcript

  1. 2 
 SIer -> Yahoo! JAPAN -> mercari (2021/08) 


    
 Help Center Team
 Software Engineer / Tech Lead
 
 福岡に住んでます
 
 濱村 甚平(@jinpeih)

  2. 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 
 コードがむずかしいと生産性が低くなる
  3. 10 コードがむずかしいを指標化する • LOC(Lines Of Code)や循環的複雑度(Cyclomatic Complexity)など様々 • 認知的複雑度(Cognitive Complexity)を使う

    ◦ 簡単に言うと、人がコードを理解する難しさの尺度 ◦ 循環的複雑度がロジカルな難しさ ▪ メソッドを完全にカバーするために必要なテストケースの最小数 ◦ 簡単にいうと、ネストに重きをおいて加算されていく https://www.sonarsource.com/resources/cognitive-complexity/
  4. 12 認知的複雑度を計測する • 方法はたくさんある ◦ SonarQube, CodeClimate, gocognit… 自チームの事例
 •CI(golangci-lint)で循環的・認知的複雑度が30以上だと落ちるようにしている

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

    
 •golangci-lintのdefaultは30. 推奨は10-20(1functionあたり 
 •自チームだとほぼ10以下に収まっている 
 数値をGETしたぞ!これが「むずかしさ」の正体だ! → ほんとか...?
  6. 16 指標との向き合い方 • 複雑度の数値が低くすることが目標ではなく、コードがむずかしいことからの脱 却が目標 ▪ そして、コード品質をあげて早く安全に開発する • あくまでなりたい姿が大事 ◦

    数値は健康診断や補助に使う • その上でコミュニケーションに使う 目標を取り違えない グッドハートの法則  「ある指標が目標になると、それは良い指標ではなくなる」 https://en.wikipedia.org/wiki/Goodhart%27s_law
  7. 18 コードがむずかしいのはなぜか • その言語化がむずかしいなら、そもそもコードもむずかしい ◦ 説明仕様が長いなら、テストコードも複雑になる • 仕様を言語化してみて、違和感を探る ◦ その仕様はどこに書かれているべきなのか

    ◦ その関数内で粒度が揃っているか(適切な抽象化ができているか ◦ 過不足なく知ることで、テストも変わる その関数・メソッドの仕様、詳細に言語化できますか?
  8. 21 すでにとてもコードがむずかしい状況の場合は? • ひとりで取り組まない ◦ まずはチームと現状の認識を揃える • 数値化やホットスポットを見つけて、モブリーディング ◦ 共有知識を増やす

    ◦ 意図をコードに残していく(コメントだけでも • チームの設計力の底上げが必要なら勉強会もあり いきなりリファクタって結構たいへん... これまでの説明って改善策ではなく回避策では
  9. 22 まとめ • 「コードがむずかしい」では伝わらない ◦ 認知的複雑度などを定量化してみよう ▪ 数値があると話しやすい ▪ 数値に囚われすぎない、目標にしない

    • 数値を目標にすると、良い目標でなくなる ◦ 数値を見ながらコードに向き合い、なりたい姿を定義しよう • 「コードがむずかしい」状態にならないために ◦ 数値を見ながら、理由を探ろう ▪ 仕様の言語化 ▪ 意図を残す ▪ ペアプロで設計について議論する ◦ できるところから意図を残していこう •