PowerPoint プレゼンテーション

Size: px

Start display at page:

Download "PowerPoint プレゼンテーション"

ふじよしたかひ
5 years ago
Views:

1 コードレビューとコードメトリクスを活用したコード品質改善活動 ~ 開発エンジニアが高品質なコードを目指す ~ SPI JAPAN 2018 () ソニーネットワークコミュニケーションズ株式会社クラウド & アプリ事業部門 1 部 1 課広石達也 <Tatsuya.Hiroishi@sony.com>

2 Agenda はじめに背景 2014 年 : 我々のコードは高品質なのだろうか? 2015 年 : とりあえずコードレビューをやってみた改善策評価 2016 年 : コード品質の向上を実感してみた 2016 年 : コード品質の向上を可視化してみた 2017 年 : これまでの施策を評価してみた 2017 年 : フィードバックをもらってみたおわりに 2

3 Agenda はじめに背景 2014 年 : 我々のコードは高品質なのだろうか? 2015 年 : とりあえずコードレビューをやってみた改善策評価 2016 年 : コード品質の向上を実感してみた 2016 年 : コード品質の向上を可視化してみた 2017 年 : これまでの施策を評価してみた 2017 年 : フィードバックをもらってみたおわりに 3

4 [ はじめに ] 自己紹介広石達也 ( ひろいしたつや ) Tatsuya.Hiroishi@sony.com / ソニーネットワークコミュニケーションズ株式会社クラウド & アプリ事業部門 1 部 1 課 2013 年にソニー株式会社入社主にコンシューマ向けアプリケーション設計開発を担当趣味は弓道 4

5 [ はじめに ] 部署紹介ソニーネットワークコミュニケーションズ株式会社クラウド & アプリ事業部門 1 部ハードウェアやクラウドと連携したサービスを担当部のメンバ ( 一部 ) 5

6 Agenda はじめに背景 2014 年 : 我々のコードは高品質なのだろうか? 2015 年 : とりあえずコードレビューをやってみた改善策評価 2016 年 : コード品質の向上を実感してみた 2016 年 : コード品質の向上を可視化してみた 2017 年 : これまでの施策を評価してみた 2017 年 : フィードバックをもらってみたおわりに 6

そちらの部署のソースコード品質はこんな感じです危機感外部レビュー文化を育てよう基本的な事から固めて

7 [ 背景 ] 2014 年 : 我々のコードは高品質なのだろうか? 部署内の複数の開発プロジェクトに対して第三者による外部レビューが実施されソースコードの品質に関するいくつかの課題を認識したそちらの部署のソースコード品質はこんな感じです危機感外部レビュー文化を育てよう基本的な事から固めて技術者の底上げを地道にやろう費用対効果が見えにくいからあんまりやりたくないちゃんと品質向上に工数を割こう! 部門長開発エンジニア達そもそも第三者のレビューで俺たちのレベルを測れるの? 部署内でコード品質に対する意識に差があった 7

8 [ 背景 ] 2015 年 : とりあえずコードレビューをやってみた各ソフトウェア開発プロジェクトにコードレビューのプロセスを導入費用対効果が見えにくいからあんまりやりたくないちゃんと品質向上に工数を割こう! 2014 年そもそも第三者のレビューで俺たちのレベルを測れるの? レビューされるとなんとなくコードが良くなった気がするちゃんと品質向上に工数を割こう!!! 俺たちのレビューはどのくらい品質向上に貢献したの? 2015 年開発エンジニア達はレビューの効果をうまく説明できなかった! 8

9 Agenda はじめに背景 2014 年 : 我々のコードは高品質なのだろうか? 2015 年 : とりあえずコードレビューをやってみた改善策評価 2016 年 : コード品質の向上を実感してみた 2016 年 : コード品質の向上を可視化してみた 2017 年 : これまでの施策を評価してみた 2017 年 : フィードバックをもらってみたおわりに 9

10 [ 改善策 ] 施策の目的と対象プロジェクト目的コードレビューが品質向上に対してどのくらい効果があったのかを知りたい対象プロジェクト 2015 年 2016 年 2017 年コード品質の向上を実感する施策コードレビュー導入 ( 前述 ) 施策を評価するコード品質の向上を可視化する施策コンシューマ向けスマートフォンアプリ開発チーム開発メンバ : 3 名 ( アーキテクト 1 名メンバ 2 名 ) 開発期間 : 約 1 年間開発言語 : TypeScript (JavaScript) 開発体制 : GitHub Enterprise を利用して Pull Request ごとに他メンバがコードレビューを実施開発サイクル : 2 weeks / 1 Sprint 10

11 Agenda はじめに背景 2014 年 : 我々のコードは高品質なのだろうか? 2015 年 : とりあえずコードレビューをやってみた改善策評価 2016 年 : コード品質の向上を実感してみた 2016 年 : コード品質の向上を可視化してみた 2017 年 : これまでの施策を評価してみた 2017 年 : フィードバックをもらってみたおわりに 11

12 [ 改善策 ] 2016 年 : コード品質の向上を実感してみた GitHub 上の開発プロセスで 2 つのルールを導入 1. Pull Request のタイトル 2. コメントのリアクション prefix 種類 reaction 意味 feat: fix: docs: style: refactor: test: chore: 新機能修正ドキュメントコーディングルールリファクタリングテストコードビルド系 [+1] 良いと思ったコードやコメントへの賞賛 [laugh] コードの意図などの補足説明 [heart] 改善部分などの指摘 KARMA (OSS) の Git Commit Msg ルールを参考にした GitHub には他にも reactions が存在するが今回は未使用 12

13 [ 改善策 ] 2016 年 : コード品質の向上を実感してみたルールその 1 Pull Request は種類に応じてタイトルに prefix を付与する 1. Pull Request のタイトル主な狙い PR による変更の意図を明確にしたい後の振り返りで集計しやすくしたい PR の例 prefix feat: fix: docs: style: refactor: test: chore: 種類新機能修正ドキュメントコーディングルールリファクタリングテストコードビルド系 KARMA (OSS) の Git Commit Msg ルールを参考にした 13

14 [ 改善策 ] 2016 年 : コード品質の向上を実感してみたルール 1 Pull Request は種類に応じてタイトルに prefix を付与する PR 数の集計まだ機能開発が続いている? 変更行数の集計 Sprint 24 で検証開始コンフリクトが発生した対応 fix は PR 数に対して変更行数が小さい出来事や傾向の振り返りは次へ活かす材料となる 14

15 [ 改善策 ] 2016 年 : コード品質の向上を実感してみたルールその 2 レビューコメントは意味に応じてリアクションを付与する 2. コメントのリアクション主な狙いレビューが役に立ったのか反応が欲しいコメントの意図を一目で理解したいリアクションの例 reaction 意味 [+1] 良いと思ったコードやコメントへの賞賛 [laugh] コードの意図などの補足説明 [heart] 改善部分などの指摘 GitHub には他にも reactions が存在するが今回は未使用 15

16 [ 改善策 ] 2016 年 : コード品質の向上を実感してみたルール 2 レビューコメントは意味に応じてリアクションを付与する [ 賞賛 ] : 良いレビューを振り返られるようになりモチベーションアップにつながった [ 補足 ] : コミュニケーションコストを抑えることができた [ 指摘 ] : 設計開発段階で品質向上を意識してレビューできた [ 指摘 ] が増加検証開始で品質を意識? [ 指摘 ] のレビューコメントの例 16

17 [ 改善策 ] 2016 年 : コード品質の向上を実感してみた開発エンジニアが実感した効果レビュールール 1 の効果レビュー前 : 変更内容をあらかじめ推測できたレビュー後 : 変更内容の傾向を振り返ることができたレビュールール 2 の効果する側 : どのように役立ったかフィードバックを得られたされる側 : 品質向上に対するモチベーションアップコードレビューに対する納得感が向上した! 17

18 Agenda はじめに背景 2014 年 : 我々のコードは高品質なのだろうか? 2015 年 : とりあえずコードレビューをやってみた改善策評価 2016 年 : コード品質の向上を実感してみた 2016 年 : コード品質の向上を可視化してみた 2017 年 : これまでの施策を評価してみた 2017 年 : フィードバックをもらってみたおわりに 18

] 0 100 [ 保守性高 ] [1] https://github.com/es-analysis/plato [2] https://blogs.

19 [ 改善策 ] 2016 年 : コード品質の向上を可視化してみたソースコードのメトリクスを計測して可視化する OSS のメトリクス計測ツール plato [1] を導入して保守性に関するパラメータである maintainability [2] の推移を継続的に観測ファイル単位でメトリクスを計測 [ 保守性低 ] [ 保守性高 ] [1] [2] 19

[ 改善策 ] 2016 年 : コード品質の向上を可視化してみた気づき 1 : コードメトリクスの変化を時系列で観測できたコード変更量 : 開発フェーズでは一定の割合で増加検証フェーズでは収束 maintainability : 開発フェーズでは不規則に増減検証フェーズでは収束

default theme and icons. moved: fes.protocol.ble library from FES-ProtocolTestBed repository. Update dependency modules added: BLE device lib. fixed: fes.

20 [ 改善策 ] 2016 年 : コード品質の向上を可視化してみた気づき 1 : コードメトリクスの変化を時系列で観測できたコード変更量 : 開発フェーズでは一定の割合で増加検証フェーズでは収束 maintainability : 開発フェーズでは不規則に増減検証フェーズでは収束検証開始以降は傾斜が緩やか大工事は発生していない 1PR 当たりのコード増加量は一定 PR の単位が適切検証開始 Updated dependency modules Added purchase sources コード変更量 Add open setting plugin added: jqm default theme and icons. moved: fes.protocol.ble library from FES-ProtocolTestBed repository. Update dependency modules added: BLE device lib. fixed: fes.dev.functions dependency. Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 青印は OSS の追加 Sprint 11 Sprint 12 Sprint 13 Sprint 14 Sprint 15 Sprint 16 Sprint 17 Sprint 18 20

21 [ 改善策 ] 2016 年 : コード品質の向上を可視化してみた気づき 2 : メトリクスの相対値の変化から大きなコード変更を観測できた下図の赤枠のタイミングで何か大きな変更があったかも maintainability 値が急落したときに何か不都合な変更が入った可能性がある maintainability 値ファイル平均 average maintainability ファイル総和 total maintainability 21

22 [ 改善策 ] 2016 年 : コード品質の向上を可視化してみた気づき 3 : 品質を評価する指標として単純にメトリクスを使うことは難しい複雑な機能の実装は保守性が高いコードでも maintainability 値が下がりやすい偉い人このコードの maintainability は低いから改善しなさい絶対ダメ! 新規機能 A 空実装新規機能 A 本実装既存機能 B リファクタリング maintainability 値ファイル平均 average maintainability ファイル総和 total maintainability 22

23 [ 改善策 ] 2016 年 : コード品質の向上を可視化してみた開発エンジニアが考えたコードメトリクスの使いどころ使いたい / 使ってほしい使いたくない / 使ってほしくない同じプロジェクトでメトリクスの変化を観測する違うプロジェクトでメトリクスの値を比較する開発プロジェクトの目標値としてメトリクスの値を設定する開発プロジェクトのノルマとしてメトリクスの値を設定するコードの変化に気づくきっかけとしてメトリクスの値を使用する人事評価の指標としてメトリクスの値を使用する開発エンジニアのモチベーションに大きく影響するためメトリクスは前向きな気づきを得るために活用すべし 23

24 Agenda はじめに背景 2014 年 : 我々のコードは高品質なのだろうか? 2015 年 : とりあえずコードレビューをやってみた改善策評価 2016 年 : コード品質の向上を実感してみた 2016 年 : コード品質の向上を可視化してみた 2017 年 : これまでの施策を評価してみた 2017 年 : フィードバックをもらってみたおわりに 24

25 [ 評価 ] 2017 年 : これまでの施策を評価してみた他の開発プロジェクトへ前述の施策を展開レビューコメントこのファイルはコード量が多すぎるから分割しようレビューの指摘がメトリクスに対してどのように影響するか 25

26 [ 評価 ] 2017 年 : これまでの施策を評価してみたリファクタリングの実施前後でコードメトリクスを比較してみた対象ファイル単体で見るとコード量は大きく減少したファイル分割した maintainability は低くなった依存関係が増加した全ファイルを結合 (PJ 全体 ) で見るとコード量は増加したファイル数が増えた maintainability は高くなった品質が向上!? コード行数 ( ファイル ) maintainability ( ファイル ) コード行数 (PJ 全体 ) maintainability (PJ 全体 ) Before After レビューの実感がメトリクスにも表れた! 26

継続的に品質改善活動に取り組んでほしいコードレビューが役に立っていることを実感できた! 簡単な施策で品質向上に貢献できた!

27 [ 評価 ] 2017 年 : フィードバックをもらってみた第三者や上長から好意的なフィードバックを得ることができた引き継いだソースコードは読みやすく保守しやすいです安心感協業者具体的なアクションを起こして結果を出せたのは良かった継続的に品質改善活動に取り組んでほしいコードレビューが役に立っていることを実感できた! 簡単な施策で品質向上に貢献できた! 部門長コード品質を良くするための気づきを得ることができた! 開発エンジニア達部署内の他プロジェクトへ施策を展開中 27

28 Agenda はじめに背景 2014 年 : 我々のコードは高品質なのだろうか? 2015 年 : とりあえずコードレビューをやってみた改善策評価 2016 年 : コード品質の向上を実感してみた 2016 年 : コード品質の向上を可視化してみた 2017 年 : コード品質の向上を評価してみた 2017 年 : フィードバックをもらってみたおわりに 28

29 [ おわりに ] まとめ背景開発エンジニアはコードレビューの効果を実感したい改善策 Pull Request とレビューコメントのルール化品質向上への貢献を実感コードメトリクスの継続的観測コード品質の変化に対する関心が向上評価コードレビューの指摘がコードメトリクスに影響することを確認できた第三者やマネージャから好意的なフィードバックを得ることができた 29

30 [ おわりに ] ROCRO の紹介開発者向けサービス群様々な言語でコードメトリクスの取得が可能! GitHub / Bitbucket と連携現在 ROCRO の INSPECODE を plato と併用して活用中 30

31 SONY はソニー株式会社の登録商標または商標です各ソニー製品の商品名サービス名はソニー株式会社またはグループ各社の登録商標または商標ですその他の製品および会社名は各社の商号登録商標または商標です

PowerPoint プレゼンテーション

PowerPoint プレゼンテーションソフトウェア品質シンポジウム 15 継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析 15/9/18 荻野恒太郎 kotaro.ogino@mail.rakuten.com Test Engineering Team Service Support Section Group Core Service Department http://www.rakuten.co.jp/