ルール
ひとつ クラス につき ファイルにつき1クラス。
複数の クラス を a ファイル内の複数のクラス ファイル 作る コード
構成 不明確 そして しにくくする ナビゲートしにくい ナビゲートしにくくなります。
対応言語 45+はじめに
複数のクラスを1つのファイルにまとめると、コードベースをナビゲートするときに特定のクラスを見つけるのが難しくなります。開発者は ユーザーリポジトリ という名前のファイルに埋もれていると、すぐに見つからない。 データベース を他の5つのクラスと並べることになる。これは最小サプライズの原則に反し、チームメンバーがクラスの定義を探すのに時間を浪費するため、開発が遅くなる。
なぜそれが重要なのか
コードの保守性：ファイルごとに複数のクラスがあると、責任の境界が不明確になる。あるクラスを修正する必要がある場合、開発者は関係のないクラスを含むファイルを開かなければならず、認識負荷が増加し、誤って間違ったコードを修正するリスクが高まります。
ナビゲーションと発見しやすさ：IDEやテキストエディタは、複数のクラスがファイルを共有している場合、正確な「定義への移動」を提供するのに苦労します。開発者は、必要なクラスに直接ジャンプするのではなく、ファイル内を検索することに時間を費やします。何百ものクラスがある大規模なコードベースでは、この問題はさらに深刻になります。
バージョン管理のコンフリクト：複数のクラスが1つのファイルを共有している場合、異なる開発者による異なるクラスへの変更はマージ・コンフリクトを引き起こします。ファイルを分けることで、各開発者が自分のファイルで作業するため、調整のオーバーヘッドなしに並行開発が可能になります。
コード例
非準拠：
// database.js
class UserRepository {
async findById(id) {
return db.users.findOne({ id });
}
}
class OrderRepository {
async findByUser(userId) {
return db.orders.find({ userId });
}
}
class ProductRepository {
async findInStock() {
return db.products.find({ stock: { $gt: 0 } });
}
}
module.exports = { UserRepository, OrderRepository, ProductRepository };
なぜそれが間違っているのか： という名前の1つのファイルに、3つの無関係なリポジトリクラスが含まれている。 データベース.検索 注文リポジトリ にあることを知る必要がある。 データベース よりも OrderRepository.js.ファイルの変更は複数のクラスに影響し、不必要なマージの衝突を引き起こす。
✅ 準拠：
// UserRepository.js
class UserRepository {
async findById(id) {
return db.users.findOne({ id });
}
}
module.exports = UserRepository;
// OrderRepository.js
class OrderRepository {
async findByUser(userId) {
return db.orders.find({ userId });
}
}
module.exports = OrderRepository;
// ProductRepository.js
class ProductRepository {
async findInStock() {
return db.products.find({ stock: { $gt: 0 } });
}
}
module.exports = ProductRepository;
なぜこれが重要なのか： 各クラスを独自のファイルにすることで、ナビゲーションを予測しやすくする。IDEは直接 OrderRepository.js でクラスを検索することができます。1つのリポジトリへの変更が他のリポジトリに影響しないので、不要なマージ競合がなくなります。
結論
ナビゲーションを予測しやすくするために、ファイル名は含まれるクラスの後に付けます。この規約は、特定のクラスを素早く見つけることが重要な、大規模なコードベースにも適用できます。余分なファイルは、組織的な明快さを提供する価値があります。
.avif)
