# コードレビュー {#code-reviews}

プルリクエストのレビューは、一般的な貢献の形です。継続的インテグレーション（CI）によってコードが期待通りに動作することは保証されますが、それだけでは不十分です。デザイン、コード構造とアーキテクチャ、テストの品質、タイプミスなど、自動化できない貢献の要素があります。以下のセクションでは、コードレビューのプロセスにおけるさまざまな側面を取り上げます。

## 可読性 {#readability}

コードはその意図を明確に表現していますか？ **コードの動作を理解するのに多くの時間がかかる場合、その実装は改善が必要です。** コードをより理解しやすい小さな抽象化に分割することを提案してください。代替案として、最後の手段として、その背後にある理由を説明するコメントを追加することもできます。プルリクエストの説明などの周囲のコンテキストなしで、近い将来にそのコードを理解できるかどうかを自問してみてください。

## 小さなプルリクエスト {#small-pull-requests}

大きなプルリクエストはレビューが難しく、詳細を見落としがちです。プルリクエストが大きくなりすぎて管理できなくなった場合は、作者に分割を提案してください。

> [!NOTE]
> **例外**
>
> 変更が密結合していて分割できない場合など、プルリクエストを分割することが不可能なシナリオはほとんどありません。そのような場合には、作者は変更内容とその背後にある理由を明確に説明する必要があります。


## 一貫性 {#consistency}

変更がプロジェクトの残りの部分と一貫していることが重要です。一貫性の欠如はメンテナンスを複雑にするため、避けるべきです。ユーザーへのメッセージ出力やエラー報告のアプローチがある場合は、それに従うべきです。作者がプロジェクトの標準に同意しない場合は、さらに議論できるイシューを開くことを提案してください。

## テスト {#tests}

テストにより、自信を持ってコードを変更できます。プルリクエストのコードはテストされ、すべてのテストに合格する必要があります。良いテストとは、一貫して同じ結果を生成し、理解と保守が容易なテストです。レビュアーはレビュー時間の大部分を実装コードに費やしますが、テストもコードであるため同様に重要です。

## 破壊的変更 {#breaking-changes}

破壊的変更は、Tuist のユーザーにとって悪いユーザーエクスペリエンスとなります。貢献では、厳密に必要な場合を除き、破壊的変更を導入しないようにすべきです。Tuist のインターフェースを進化させるために、破壊的変更によらずに活用できる言語機能は多くあります。変更が破壊的かどうかは明らかでない場合があります。変更が破壊的かどうかを確認する方法の一つは、fixtures ディレクトリ内のフィクスチャプロジェクトに対して Tuist を実行することです。これは、ユーザーの立場に立ち、変更が彼らにどのような影響を与えるかを想像することを要求します。