Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • 不要なコードを消すことの意義
  • dead code 検出方法
  • simplecov viewer
  • 実装
  • 計測方法
  • 集計方法

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. 開発ツール

Code Coverage

不要なコードを消すことの意義

不要なコード (以下 dead code) が存在するとプロダクトにも開発体験にも悪影響を及ぼします。 例として下のようなものがあります。

  • プロダクト

    • 不要な処理によるバックエンドの速度劣化

    • 不要な asset のダウンロードによるフロントエンドの体験劣化

  • 開発体験

    • build 時間の増加

    • 影響範囲推定の困難化

発見が簡単なものとそうでないものがありますが、ある dead code が他の dead code から参照されている場合、 前者の発見はより困難になります。 したがって dead code を減らしていくというアクションは継続的に行わないと簡単に対応が難しい状態になってしまいます。

dead code 検出方法

ここでは社内で作った本番環境から取得できるログをもとにした dead code 検出方法について解説します。 2023 年 6 月時点で一部の Rails のアプリケーションのみしか対応していないので主に Rails を前提にします。

simplecov viewer

下のフォーマットで社内のエンジニアに coverage を公開しています。

https://internal-only-static-files.wantedly.com/coverages/repos/<app_name>/<env>/<date>/index.html
  • <app_name>: repository 名 (例: wantedly/wantedly の場合は wantedly)

  • <env>: production, qa, sandbox, test

  • <date>: YYYY-MM-DD のフォーマット、もしくは latest

Ruby における実装方法の背景上、ステートメントカバレッジのみ、つまりある行が実行されたかどうかしか記録していません。 このため、各行について少なくともその一部が実行されていることのみがわかります。

例

注意

この手法で検知できない dead code が存在し、また逆にここで hit していないと判定されても実際には dead code でない場合があります。 したがって実際に削除する場合には Pull Request に他の根拠を示してください。 理由としては下のようなものがあります。

  • 「hit していない => 不要なコード」は成り立たない

    • 定期実行 job なども測定対象だが、測定期間内に呼び出されなかっただけの可能性もある

    • Rails の場合 initializer など測定開始前に実行されるコードは検出できない

  • 「検知されている => 消すことができない」は成り立たない

    • 表示に影響のない HTML 要素や無駄な処理など仕様に影響のないコードもありえる

  • 正確でない/勘違いしやすい場所がある

    • Rails の view は実装の制約上 render されたかどうか しか確認できない

    • ActiveRecord の scope などを 1 行で定義した場合 scope が定義されたこととその中の proc が実行されたことの区別はできない

実装

計測方法

集計方法

集計期間をできる限り長くするために次のような集計方法をとっています。

  • file ごとに期間を決めてその間に各行が hit したかどうかを集計する

  • 期間

    • 終了時点: <date> の日付

    • 開始時点: 終了時点と file の内容が変わっていない最も古い日付 (ただし最大 6 ヶ月前)

話を聞きに行きたい

もっと知りたい

前へkube次へKubefork

最終更新 1 年前

役に立ちましたか?

Rails では を利用しています。 view についてはこの手法では計測できないため、ActiveSupport::Notifications.subscribe を用いて render されたかどうかのみを検知しています。 詳しい実装は wantedly/wantedly に存在する view_coverage.rb を確認してください。

ここで検出されたものを の EventLogger で BigQuery に保管しています。

Slack:

wantedly/wantedly
oneshot coverage
servicex
#dx
不要な style 検知ツール unused-classes について (internal)
oneshot coverage を誰でも使いやすくする (internal)
テスト環境の Code Coverage (internal)