コード品質向上のいろは – 先達に学ぶ実践例 Lunch LT
https://findy.connpass.com/event/300912/
に参加した聴講メモです。
LT①『「コードがむずかしい」からの脱却』 株式会社メルカリ 濱村甚平(@jinpeih )
資料
https://speakerdeck.com/jimpei/kodogamuzukasii-karanotuo-que
途中から参加したので、メモは途中から
「コードが難しいから改善したいので時間ください」だけだと、相手には伝わらない。
そのため
- それはどのくらい悪くて
- 改善するとどのくらい効果があって
- どのくらいの時間が必要なのか
などの指標が必要。
複雑度の指標
SonarQube 等のツールがあるのでそういうのを活用した
ただ、だからといって数値が悪いイコール絶対改善！というわけでもない
複雑度が高いからといって、そのコードを滅多に変更しないなら改善してもあまり嬉しくない
また、複雑度はやり方によっては回避できる。
例えばネストさせない代わりに関数を分割させまくると複雑度の数値は下がるが、
それは複雑度の低い複雑なコードなだけである。
指標を下げることが目的ではないので、あくまで補助的な使い方。
ひとりで書くのは難しい
ペアプロで意図を共有しながらコードを書くと、少なくとも二人の間では意図が通じてる
Q&A
Q1
他の人や他のチームの数値が見えすぎると、良い部分はある反面少し競争のような形になってしまうなとも感じています。
どこまでの人と数値を共有するかなど、意識されたりしていますか？
A1
比較するものではないので、競争とかにならないように数字数字という扱いにしていない。
共有は広く共有したほうが、参考になるのでいいと思う。
Q2
認知的複雑度を数値化してからは、やはり不具合は減ったのでしょうか？
A2
これは簡潔に yes/no かは言えない。というのも、数値化した後にチームを離れることもあるし、
まだ数値化したあとに不具合の数がそれによってどうなったかを追っていないというのもある。
不具合が減った要素はいろいろあるので、そこまで追うのも難しいかも。
ただ、将来的には、不具合を減らしたいから数値化しているというのも目的の1つにはある。
LT②『なぜリアーキテクティング専任チームを作ったのか』 株式会社アンドパッド 白土慧(@kei_s)
資料
https://speakerdeck.com/kei_s/naze-riakitekuteinguzhuan-ren-timuwozuo-tutanoka
現状のアーキテクチャ
中心となる Rails に付随する形で各プロダクトが存在
Rails は8年選手
Rails のライブラリアップデートが滞っていた
- ライブラリの開発が停止してたりしたが、そのままだった
- アップデートしようにも、そのライブラリは複数のチームに跨っているので、1つのチームで責務を持ちにくい
これによって、古いライブラリに依存したコードを書かなければならなく、メンテナンス性が低下。
OSSのメリットもあまり受けられない状態に。
リアーキチームの発足
- 特定のサービス等には責任は持たない。そこは既存のチームが担当する
- その代わり、チーム目線だと難しい全体目線で考える部分を担当
- 共通利用されているところとか担当
- 逆に、特定のチームでのみ使っている部分とかは対応しない
さじ加減
「ライブラリアップデートは、リアーキチームの仕事」としない。
特定の人の仕事ではなく、改善意識は全員が持つべき
Q&A
Q1
お話であったように、エンジニア全員で改善をするというマインドが失われないようにするための取り組みはありますか？
専任チームを作ることで、各自から課題が出てこなくなるリスクもあるなーと
A1
わいわいと「ここ改善したいよね」みたいな話をしたり
リアーキチームに限らず、改善活動するのは良いことである、みたいなのを浸透させるようにしている
Q2
ライブラリアップデート時の影響範囲調査の進め方など、専任だからできるメリットをもう少し聞きたいです
A2
専任チームのいい例は、専門でそこの領域に調査の時間とかとれたり知見がたまるのが良いと思う。
逆にプロダクトチームほど知見がないので、「この挙動ってどうなってる」「こういうテストを考えてるけど抜け漏れないかな？」
みたいなコミュニケーションを取るようにしている。
LT③『10年モノのAndroidアプリのコード品質を改善していく、3つの取り組み』 Chatwork株式会社 奥澤 俊樹(@okuzawats)
資料
https://speakerdeck.com/okuzawats/4de89f92-6dff-4d77-8701-10882ff27be7
なんでコード品質を改善したいのか
- メンバーやチームが増えた
- コード品質が開発速度に直結
- 改善したい
コードレビュー
「自分がコード品質について誰よりも考えレビューすればよい」と思っていた。
が、自分が門番になってしまうと開発速度が落ちると思ったので、そうはしなかった。
自動レビュー
静的解析ツール
- danger
- ktlint
- android lit
- sonarcloud（今日の話はこれに着目）
メリット
- コードが怪しいところ（Code Smells）の検出
- 複雑度を出してくれる
- 閾値を満たさないと CI が落ちる
勉強会をするようにした
https://creators-note.chatwork.com/entry/code-readability
ガイドラインの作成
Kotlin のスタイルガイドみたいなのを参考にした
できれば Lint がスタイルガイド通りに反応してくれたら嬉しいので、検討中
Q&A
Q1
SonarCloud検討しているのですが、他に検討したツールや自作していたものなどありますか？
また、どういう観点で使う判断をしたか参考に聞きたいです
A1
もともとある程度SonarCloudの知見があったから使った
Q2
ストリームアラインドチームメンバーをどうアサインしたか気になります
A2
それぞれのエンジニアがどういう仕事やキャリアにしたいか等で検討した
LT④『DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実』 合同会社DMM.com pospome(@pospome)
資料
レガシーシステムのリプレイスをするよ
コードの品質を高く保って、開発速度を改善したい。
品質を高く保つための持論
リファクタリングや静的解析ができても、設計スキルが高くないと品質は上がらない
が、設計スキルが高いエンジニアを雇うのも育てるのも難しい
そこで、レビューシステムの導入
各チームのコードを設計スキルの高いエンジニアがチーム外レビューする取り組み
うまくいく自信があった
が、それだけだとうまくいかなかった
なぜなら、チームによって課題が様々だから
- リファクタリングの時間確保
- 良し悪しの判断が難しい
- 意思決定権持ってる人への、品質に対する理解
まとめ
組織が大きいとコード品質改善は大変。
特に意思決定の部分が大変なので、戦略を持ってやらなければ。
Q&A
Q1
pospomeさんの考える「設計スキルが高いエンジニア」の基準をお伺いしたいです！
業務知識に詳しく、アーキテクチャ図を描ける人、静的解析に詳しい、など
A1
SOLID 原則とか分かってたり、もちろん業務知識も必要
図を書くためのスキルみたいなのはあまり必要ないかも。
Q2
専任チームを作る話が本日多数ありましたが、
最初にチームを組成した時に、他のチームへどのように介入したか、より失敗談や工夫した点などがあれば聞きたいです。
A2
まずはレビューやらせてくれという姿勢で入った。
失敗談の話になるが、結局チームのテックリードや意思決定者を巻き込まないといけないので難しかった。
参加しての感想
各社、ある種似たような悩みを抱えていて、それに対して社内の状況に合わせたアプローチを試行錯誤しているんだなぁと感じた。
そういう意味でも、今回のような会は各社の知見を共有して自社に活かすことに繋がるので良いなぁと感じた。
各社概ね共通していることは
- 現在の状態を整理
- 課題は何か
- 必要であれば静的解析ツール等を使って数値化、見える化
- 対策を検討
- どこまで対応するか
- 専門チームの立ち上げ
- コードレビュー
- 品質意識の浸透
- 対策を実行したり、更にブラッシュアップしたり
- 指標に対する考え方
- やること・やらないことを明確に
- より活用にするためにどうするのが良いか
- チームの課題に合わせて動くように
などがあるなぁと思った。
当たり前かもだが「これが最近流行ってるやり方！」「とりあえずこれやっとけ！」みたいなのがある訳ではなく
課題が何で、どういうゴールを想定していて、理想の状態にするために何をすればよいかを考え、改善し続けるという、課題解決の基本的な考え方と同じだよなぁと思った。
その中で、テクニカルな部分や参考になる手段として静的解析ツールの導入や、専門チームの設立などがあるなぁと思った。
SonarCloudは触ったことないけど、コードの怪しそうな部分（Code Smells）を教えてくれるのが気になった。
