コードレビューのカスタム指示を設定する

カスタム指示は、Rovo Dev Standard プランのユーザーのみが利用できます。30 日間無料トライアルが用意されています。

プルリクエスト作成者の Rovo Dev Standard プランは、プルリクエストが作成される Bitbucket ワークスペースまたは GitHub 組織に接続されている Jira サイトで利用する必要があります。

カスタム指示を使用して、プルリクエストに対する Rovo Dev のフィードバックを調整できます。チーム独自の標準、パターン、好みを追加することで、チームにとって最も都合の良いコメントのみを受け取ることができます。

リポジトリのカスタム指示を設定する

リポジトリのルートに .rovodev フォルダーを作成します。
.rovodev フォルダーに .review-agent.md ファイルを追加し、リポジトリ内のプルリクエストをレビューする際に Rovo Dev が従うべき明確かつ具体的な指示を追加します。
ファイルを保存する。

効果的なカスタム指示の書き方

明確で焦点が絞られており、Rovo Dev が簡単に従うことができるカスタム指示を記述します。

一度に 1 つのトピックを扱うシンプルで実行可能なルールを使用します。
ファイルパターン、命名規則、コード構造などの具体的な詳細を含めます。
良いプラクティスと悪いプラクティスの両方の例を提示します。
各指示には改行や箇条書きを使用するなど、書式を一貫させます。
「Code quality (コード品質)」、「Architecture (アーキテクチャ)」、「QA」などのカテゴリを使用して、関連する指示をグループ化します。
リンターによって処理されるフォーマット問題など、無視すべきトピックに言及します。

最初は膨大な指示を追加することは避けます。少しずつ段階的に追加し、指示の効果をテストしてください。

カスタム指示の例

カスタム指示を使用してチームのカスタム標準を Rovo Dev に学習させることで、より具体的で的を絞った提案が行われるようになります。

これらはカスタム指示の成功例です。チーム向けに独自の指示を記述する際に参考にしてください。

コーディング標準を徹底するためのコードレビューガイドラインを指定するには、次のようにします。

# Code Review Guidelines: Anti-Patterns and Better Solutions

## Code Quality & Structure

### Naming Conventions

**When you spot unclear or abbreviated variable names**, you should **suggest the author use descriptive, meaningful names that follow camelCase convention** instead of abbreviations or generic names.

### Code Organization

**When you spot functions exceeding 50 lines**, you should **suggest the author break them into smaller, single-purpose functions** instead of having one large function.

**When you spot nested conditional statements exceeding 3 levels**, you should **suggest the author use early returns and guard clauses** instead of deep nesting.

### Error Handling

**When you spot empty catch blocks or silent error suppression**, you should **suggest the author implement proper error logging with context** instead of ignoring errors.

**When you spot generic Error objects being thrown**, you should **suggest the author create specific error classes with meaningful messages** instead of using generic errors.

### Performance Standards

**When you spot expensive operations inside loops**, you should **suggest the author move calculations outside loops or use array methods** instead of recalculating values repeatedly.

**When you spot missing cleanup in useEffect hooks**, you should **suggest the author add cleanup functions for event listeners and subscriptions** instead of leaving resources attached.

## Architecture & Design

### Design Patterns

**When you spot classes or functions with multiple responsibilities (God Object anti-pattern)**, you should **suggest the author separate concerns into focused, single-purpose modules** instead of having one module handle everything.

### API Design

**When you spot inconsistent API response structures**, you should **suggest the author use a standardized response format** instead of different structures for different endpoints.

**When you spot missing input validation**, you should **suggest the author implement proper validation schema** instead of trusting user input.

### Security Standards

**When you don't sanitize user input**, you should **validate and sanitize all inputs** instead of trusting user data.

## Quality Assurance

### Monitoring & Observability

**When you use console.log for debugging**, you should **implement proper logging with levels and context** instead of cluttering code with console statements.

---

# Review topics to exclude

Below are the topics you should avoid from commenting in your code reviews.

## Avoid providing feedback on formatting

**When you find non-critical code formatting issues**, you should **avoid leaving any suggestions** because we have linter rules in place to cover these issues.

## Avoid providing feedback on inline comments

**When you find inline code comments**, you should **avoid leaving any suggestions regarding its validity, content or formatting** because inline comments are NOT in scope for code reviews

カーディナリティの高い値に対して構造化ロギングを強制するには、次のようにします。

#Logging
KotlinLogging is the preferred logging library. Avoid using println for logging purposes.
Use structured logging to separate log values from messages:
logger.atInfo {
    message = "User logged in"
    payload = mapOf("userId" to user.id) 
}

リスクの高い変更に機能ゲーティングを強制するには、次のようにします。

# Feature Gate
Confirm changes to existing code are feature gated using the utils/FeatureService.kt and tested on and off.
Minor changes such a non-intrusive, self-contained and inactive changes do not require feature gates.

または、特定の種類のセキュリティリスクについて警告するには、次のようにします。

Look at the files names in the commit. This analysis applies to Poco policy files which describe authorization rules and generally named `policy*.json`.

The content of the file will be similar to:
Example 1:
```
{
  "allow": [
    {
      "description": "allow unauthenticated requests through the global edge",
      "methods": [
        "GET"
      ],
      "paths": [
        "/api/some/path"
      ],
      "principals": {
        "asap": {
          "issuers": [
            "micros/edge-authenticator"
          ]
        }
      },
      "runtime": {}
    }
  ]
}
```
Example 2:
```
{
  "allow": [
    {
      "description": "Allow access to /handle",
      "paths": [
        "/handle"
      ],
      "methods": ["POST"],
      "principals": {
        "open": {
        }
      }
    }
  ]
}
```
In this case path require proper authorization and are not public.
Example 3:
```
{
  "description": "Allow only authenticated services to our activate/cancel endpoint",
  "paths": ["/entitlements/activate",
            "/entitlements/cancel"],
  "methods": ["GET"],
   "principals": {
      "asap": {
        "issuers": [
          "micros/marketplace-demand-service",
          "micros/marketplace-amkt-fe-server",
          "micros/sandbox-service",
          "micros/enterprise-gatekeeper",
          "micros/id-org-manager",
          "pollinator-check/d3f187a2-2b22-4554-8795-559f707fc1f3",
          "pollinator-check/fd9a2908-7d2f-4a76-965e-121bec464e9b",
          "micros/cosmos"
        ]
      },
      "staff": {
        "groups": [
          "micros-sv--pls-orchestration-adapter-dl-admins"
        ]
      }
},
```

In order to be publicly accessible, poco policy usually need to have corresponding path opened to public in the service descriptor file named `service-descriptor.yml`

If poco policy is properly secured and service descriptor has path opened, resulting policy may not be public.

In example below has /api/some/path opened to public in the service descriptor file:

```
resources:
- type: globaledge
  name: internet
  attributes:
    routes:
      - match:
          prefix: '/api/some/path'
          ip_whitelist:
            - public
```

Warn when a path is open publicly in `service-descriptor.yml`.
Warn when a poco policy is not properly secured.

また、Rovo Dev にコードベースの具体的な詳細 (フレームワークやバージョンなど) を伝えて、無関係な提案が行われないようにすることもできます。

# UI Components
The Flex component is a basic mapping to the CSS Flexbox API. It can be used as a less richly-configured Inline or Stack.
Like Stack and Inline, Flex exclusively supports token-backed gap properties to ensure layouts using Flex match the Atlassian Design System spacing scale.
Props: justifyContent, alignItems, wrap, direction
# Atlassian Design System Spacing
The 8px base unit also forms the basis of our space token system, as the base unit space.100. Every space token is a multiple of this base unit, the number suffix representing the percentage of the base unit.
For example, space.200 is 200% of the size of the base unit, therefore represents 16px.
Each space token should be used in place of the raw pixel or REM values when adding space between components or objects on a page.

この内容はお役に立ちましたか?

正確ではなかった明確ではなかった関係なかった

さらにヘルプが必要ですか?

アトラシアンコミュニティをご利用ください。

コミュニティに質問

コード レビューのカスタム指示を設定する

リポジトリのカスタム指示を設定する

効果的なカスタム指示の書き方

カスタム指示の例

さらにヘルプが必要ですか?

コードレビューのカスタム指示を設定する