コードベース診断AI:オンボーディング期間とリスクを算出

はい。このレポート生成ツールはブラウザ内で完結して動作します。登録もペイウォールもなく、見積もりの計算のためにサーバーへデータが送られることもありません。

この数式は査読済みモデルではなく、透明性のあるヒューリスティックです。レビューサイズに関する指針(PRはおよそ400行未満に抑える、集中して読めるのは60分程度が目安という点)は、Googleのエンジニアリングプラクティス文書とSmartBear/Ciscoのコードレビュー研究に基づいています。カバレッジと技術的負債のペナルティの大きさは、エンジニアが週の多くの時間を不具合や保守作業に費やしていると報告したStripeのDeveloper Coefficientレポートを参考にしています。意図的に「ヒューリスティック」と呼んでいます。数値は目安として扱ってください。

いいえ。入力内容はすべてブラウザ内にとどまり、計算はお使いのデバイス上のJavaScriptで行われます。唯一のネットワーク通信は、ウィジェットの利用回数を数えるための匿名のping送信のみで、コードベースの詳細は一切含まれません。

いいえ。あくまで計画の出発点となる目安の日数とリスクレベルを示すものです。実際のオンボーディングチェックリスト、担当メンターの割り当て、自分のリポジトリに基づいた最初の週の読書リストと組み合わせて使ってください。

最も影響が大きい要因は3つあります。テストカバレッジが30%未満であること、コードベースが7年以上経過していること、そしてエンジニア1人あたりのコード行数が多いことです。まずこの3つを確認してください。多くの場合、今四半期のうちに実際に手を打てる項目です。

新しく入るエンジニアが実際に最初に触れる言語と領域を基準に数値を出してください。モノレポ全体ではありません。200万行のモノレポでも、ジュニアが触るのが4万行の1サービスだけなら、そのサービス単位でスコアを出すべきです。

部分的には使えます。リスクスコアはレビュー負荷と相関しており、リスクが高いコードベースは概してレビューが遅く、コストもかかる傾向にあります。ただし、自分のチームのPRサイクルタイムを実際に自社のメトリクスダッシュボードで測定する代わりにはなりません。

オンボーディング期間は、1人の新しいエンジニアが戦力になるまでの日数を答えるものです。リスクスコアは、コードベース全体としての脆さを答えるものです。テストカバレッジが低く、コードベースが古く集中している場合、すでに長く在籍しているエンジニアにとってもリスクは高くなります。