cohesion

用途

这份资料是一份前端代码质量指南，主题是「凝聚度（Cohesion）」。它的核心原则是：一起被修改的代码，应该放在一起。当出现「修改一个功能却要同时改动多个目录」「同一个数字或常量散落在多个文件」「import 路径长到 ../../..」这类信号时，就说明代码的凝聚度可能出了问题。

主要能力

资料给出了两类核心模式：

1. 把一起修改的文件放在同一目录

反例是按「种类」分离，导致依赖关系难以把握：

src/
├── components/UserForm.tsx
├── hooks/useUserValidation.ts
├── types/userTypes.ts
└── api/userApi.ts

推荐做法是按「领域」组织：

src/
├── components/   # 全局共享
└── domains/User/ # User 相关代码集中
    ├── UserForm.tsx
    ├── useUserValidation.ts
    ├── types.ts
    └── api.ts

2. 消除魔法数字

同一个数字出现在多处时，只改其中一处就会产生 bug。

反例（分散）：

// Pagination.tsx
const pages = Math.ceil(total / 20);
// useItems.ts
const offset = (page - 1) * 20;

推荐做法（统一为常量）：

export const PAGE_SIZE = 20;
import { PAGE_SIZE } from './constants';

快速参考

资料提供了一张「代码坏味道 → 改进方法」的对照表：

• 同一个魔法数字出现在 3 处以上 → 抽取为共享常量
• 一个功能要同时修改 components/、hooks/、types/ → 放到 domains/featureName/ 下
• 出现很长的相对路径 ../../.. → 把文件放得更近
• 类型定义离使用处太远 → 与使用它的代码放在一起

适用场景

适合在前端项目中进行目录结构设计与重构时参考，尤其是当项目按技术类型（组件、hooks、类型、API）分层，导致跨目录改动频繁、依赖关系不清晰时。

限制与例外

资料明确指出，并非所有重复都应消除，以下情况「重复反而更好」：

• 两个功能未来很可能朝不同方向演进时
• 共享会引入不想要的依赖关系时
• 共享代码不足 5 行、本身足够简单时

补充说明

资料引用的参考链接为：https://frontend-fundamentals.com/code-quality/cohesive/ 。关于该指南的收费、平台支持范围、具体工具链集成方式等信息，资料中暂未提供。