Pull Request が通らない人に足りないのは、たいてい語彙力

この記事は約 6 分で読めます。

レビューで「なんか違う」と言われ続ける

Pull Request を出すたびに大量のコメントがつく。「ここはこうした方がいい」「この設計だと後で困る」「もう少し考えてみて」。指摘の内容は理解できるのに、なぜ自分では気づけなかったのかがわからない。

この状態が続くと、コードを書くこと自体が怖くなります。しかし、問題はコーディングスキルではなく「設計の語彙力」にあることが多い。

設計の語彙力とは何か

自然言語で考えてみてください。語彙が少ない人は、複雑な状況を説明するのに苦労します。「なんかいい感じ」「微妙」「ヤバい」。語彙が豊富な人は、同じ状況を「費用対効果が高い」「トレードオフがある」「技術的負債が蓄積している」と表現できます。

コードも同じです。設計の語彙が少ないと、問題を認識する解像度が低くなります。

「この関数が長い」としか思えない人と、「この関数は単一責任の原則に違反していて、入力のバリデーション、ビジネスロジック、永続化の 3 つの責務が混在している」と分析できる人。後者は問題を正確に言語化できるから、適切な解決策も見えます。

語彙力不足が Pull Request に現れるパターン

パターン 1: 命名が曖昧

processData、handleStuff、doSomething。何をする関数なのか、名前から読み取れない。これは英語力の問題ではなく、その関数の責務を自分自身が明確に理解できていないことの表れです。

設計の語彙があれば、「この関数はバリデーションをしている」「これはデータの変換をしている」「これは外部 API との通信を抽象化している」と責務を特定でき、それに応じた名前をつけられます。

パターン 2: 構造が場当たり的

機能を追加するたびに if 文が増え、関数が肥大化する。リファクタリングの必要性は感じているが、どう直せばいいかわからない。

Strategy パターン、Factory パターン、Decorator パターン。これらの名前と適用場面を知っていれば、「この条件分岐は Strategy パターンで解消できる」と判断できます。パターンの名前を知らなければ、問題を認識しても解決策にたどり着けません。

パターン 3: レビューコメントの意図が読めない

「凝集度が低い」「依存の方向が逆」「インターフェースで抽象化した方がいい」。レビュアーのコメントに含まれる用語がわからず、何を直せばいいのか理解できない。

ソフトウェア設計の入門書を 1 冊読むだけで、レビューコメントの理解度が劇的に変わります。

語彙力を増やす読書法

用語を集める読書

設計の本を読むとき、新しい用語が出てきたら「用語 + 一行定義 + 使う場面」の 3 点セットでメモします。

例:

• 単一責任の原則: クラスや関数が変更される理由は 1 つだけであるべき。関数が肥大化したときに適用
• 依存性逆転の原則: 上位モジュールは下位モジュールに依存すべきでない。外部 API やデータベースとの結合を緩めたいときに適用

このメモが 30 個溜まるころには、コードレビューの景色が変わっているはずです。

レビューコメントから逆引きする

過去に受けたレビューコメントを見返し、理解できなかった用語をリストアップします。その用語を技術書の索引で引き、該当する章を読む。

この方法は、自分に足りない語彙をピンポイントで補えるため、効率が極めて高い。

設計の本を「辞書」として使う

設計の本は最初から最後まで通読する必要はありません。索引を引いて、必要な概念だけを読む使い方でも十分に価値があります。デスクの手の届く場所に 1 冊置いておき、コードを書いていて「この構造、名前がありそうだな」と思ったら引く。

語彙力が上がると起きる変化

設計の語彙が増えると、コードを書く前に「この機能はどういう構造で実装すべきか」を考えられるようになります。書いてからレビューで指摘されるのではなく、書く前に設計を検討できる。

Pull Request のコメント数が減るだけでなく、自分からレビューコメントを書けるようになります。「ここは○○パターンを使った方が拡張性が高い」と具体的に提案できるレビュアーは、チームにとって貴重な存在です。

関連記事

• コードレビューが上手い人は何を読んでいるのか
• 設計の引き出しは本でしか増えない

まとめ

Pull Request が通らない原因の多くは、コーディングスキルではなく設計の語彙力不足です。設計の用語を知らなければ、問題を認識する解像度が低いまま。設計の本を 1 冊読み、用語を 30 個メモするだけで、コードの書き方とレビューの受け方が変わります。