コード・レビュー

プルリクエストをレビューすることは、一般的な貢献の一種である。継続的インテグレーション（CI）は、コードがやるべきことを確実に実行することを保証するが、それだけでは十分ではない。自動化できない貢献の特徴があります: デザイン、コード構造とアーキテクチャ、テストの品質、タイプミスなどです。以下のセクションは、コードレビュープロセスのさまざまな側面を表しています。

読みやすさ

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

小さなプルリクエスト

大規模なプルリクエストはレビューが難しく、詳細を見落としやすくなります。もしプルリクエストが大きすぎて管理できなくなったら、作者に分割するように提案してください。

例外情報

プルリクエストの分割が不可能なシナリオもあります。たとえば、変更が緊密に結合していて分割できない場合などです。そのような場合、作者は変更内容とその理由を明確に説明する必要があります。

:::

一貫性

変更がプロジェクトの他の部分と一貫していることが重要だ。矛盾はメンテナンスを複雑にするので、避けるべきだ。ユーザーにメッセージを出力したり、エラーを報告したりする方法があるのなら、それに従うべきです。もし作者がプロジェクトの標準に同意しないのであれば、issueを開くよう提案し、そこでさらに議論しましょう。

テスト

テストによって、安心してコードを変更できる。プルリクエストのコードはテストされるべきであり、すべてのテストはパスすべきである。良いテストとは、一貫して同じ結果が得られるテストであり、理解しやすく保守しやすいテストである。レビュアーはレビュー時間のほとんどを実装コードに費やしますが、テストもコードなので同様に重要です。

ブレークチェンジ

破たん的な変更はTuistのユーザーにとって悪いユーザーエクスペリエンスです。コントリビューションは、それが厳密に必要でない限り、ブレークチェンジを導入することを避けるべきである。壊れるような変更に頼らずにTuistのインターフェイスを進化させるために活用できる言語機能はたくさんあります。変更が壊れるかどうかは明らかではないかもしれない。変更が壊れるかどうかを検証する方法は、fixturesディレクトリのfixtureプロジェクトに対してTuistを実行することである。それにはユーザーの立場に立って、その変更が彼らにどのような影響を与えるかを想像する必要がある。