什么是复杂度

软件系统变得复杂的三个成因是规模、结构与变化。

针对三个成因，我们可以通过以下方式简化系统：

分而治之，控制规模
保持结构的清晰与一致
拥抱变化

依据这些原则，我们该如何组织文件结构，管理好前端项目复杂度？

前端项目中，组织文件结构的两种常见方式

File-Type First (FTF)

『按文件类型组织』，这也是前端项目中最普遍的组织方式。例如：

src
├── index.js
├── components
│   ├── index.js
│   ├── footer
│   ├── header
│   ├── posts
│   └── users
│       ├── UserDetail.js
│       └── UserList.js
├── containers
│   ├── home
│   ├── posts
│   │   └── index.js
│   └── users
│       └── index.js
├── actions
│   ├── posts.js
│   └── users.js
├── reducers
│   ├── posts.js
│   └── users.js
└── sagas
    ├── posts.js
    └── users.js

Feature First

『按功能特性组织』。例如：

src
├── components
│   ├── footer
│   ├── header
│   └── index.js
├── features
│   ├── posts
│   │   ├── action.js
│   │   ├── components
│   │   │   └── index.js
│   │   ├── containers
│   │   │   └── index.js
│   │   ├── reducers.js
│   │   └── sagas.js
│   └── users
│       ├── action.js
│       ├── components
│       │   └── index.js
│       ├── containers
│       │   └── index.js
│       ├── reducers.js
│       └── sagas.js
└── index.js

『关注点分离』的差异

两种文件组织方式都是在做『关注点分离』，不同的是对『关注点』的理解。

File-Type First 的『关注点』是技术和手段。
Feature First 的『关注点』是功能和目标。

『语言』分离和『组件』分离

（图片来源：A feature based approach to React development）

『功能特性』分离

（图片来源：Why React developers should modularize their applications?）

你应该采用哪种方式？

File-Type First 的特点是：简洁、直接，符合开发者的直觉。而 Feature First 在管理大规模项目的复杂度上更有优势。

深入 Feature First 的文件组织方式

Feature First 文件组织方式的优势：

代码易于查找、定位代码的组织方式反映了产品结构，与产品需求相对应。
代码更易于维护每个 Feature 隔离，当修改一个 Feature 中的代码修改、重构时，不会影响其它 Feature。多特性并行开发时，更大程度上避免 merge 时产生的冲突。
启用 Feature Flags 机制

Feature Flag 是一种通过配置开功能特性的技术，无须重新部署代码。

像类似 A/B Testing 的需求，也可以借用 Feature Flags 实现。

代码示例：

// features.json
{
  ...,
  portal: true,
  users: true,
  posts: false
}

// index.js
export function isFeatureEnabled(feature) {
  return features[feature] || false;
}

将 Feature First 进行到底

如果某个 Feature 比较复杂，可以将其进行一步细分，形成 Feature 的嵌套结构。例如：将 features/users 细分为

features/users/features/detailView
features/users/features/listView

src
├── features
│   └── users
│       ├── components
│       │   ├── Table.js
│       │   └── index.js
│       └── features
│           ├── index.js
│           ├── detailView
│           │   └── components
│           │       └── Detail.js
│           └── listView
│               └── components
│                   └── List.js
└── index.js

如何组织应用内的共享组件

有的组件跨 Feature 复用，有的组件同 Feature 内跨 Page 复用。为了保证良好的可维护性，共享组件的组织应该遵循明确的规则。

下面是一个供参考的方案。（components 目录下的 index.js 只负责 export 组件，不实现具体功能）

src
├── components
│   ├── Notification.js
│   └── index.js
├── features
│   ├── posts
│   │   └── components
│   │       └── index.js
│   └── users
│       ├── components
│       │   ├── Table.js
│       │   └── index.js
│       └── features
│           ├── index.js
│           ├── detailView
│           │   └── components
│           │       └── Detail.js
│           └── listView
│               └── components
│                   ├── List.js
│                   ├── Title.js
│                   └── components
│                       ├── index.js
│                       ├── Pagination.js
│                       └── components
│                           └── index.js
└── index.js

请思考一下，在上述项目结构中， src/features/users/pages/listView/components/List.js 可以共享使用的组件有哪些？

接下来，我们一一来看：

src/components 内放置的是应用范围内的共享组件，所以，List 可以使用其中的所有组件。
src/features/posts/components 跟 List 属于不同 Feature，所以，无法使用其中组件。
src/features/users/pages/detailView/components，虽然跟 List 属于同一个 Feature，如果允许从listView 到 detailView的『同层引用』，也会增加 Feature 内的文件引用复杂度。所以，这类引用也是要被禁止的。
src/features/users/pages/listView/components/components （与 List 同级的components 目录），List 的子组件就放在同级的 components 目录中，所以，允许访问。
src/features/users/pages/listView/components/components/component （与 List 同级的 components 目录的子级 components），『跨层引用』也会增加复杂度，所以，也不允许此类引用。

把上述情况，归结成一句话就是：

除了同目录文件，组件只能引用其所在文件各级路径下的 components 目录。

将 src/features/user/pages/listView/components/List.js 按照上述规则展开：

src/features/user/pages/listView/components/components
src/features/user/pages/listView/components
src/features/user/pages/components
src/features/user/components
src/features/components
src/components

看到这，可能找个了一个熟悉的身影。是的，它跟 CommonJS 中的模块查找规则很类似。

components 目录里放什么？components 目录的严格意义是，放置仅供同级组件复用的子组件。例如：上述与 List 同级的 components 目录，应该存放仅供 List、Title 复用的子组件。

超越 Feature 的项目复杂度

新的逻辑层次

在人才管理、财务管理等企业级应用中，仅有 App 和 Feature 已经不能如期地对应上产品结构了。

这时，我们需要一个新的逻辑层次，如：Solution。一个 Solution 包含若干个 App，每个 App 有多个 Feature。

有了 Solution 新的逻辑层次，根据内聚性，可以把原来的 Feature 分拆到不同的 App 中。相比于 Feature，App 间的耦合性更小，甚至可以当作独立的部署单元。

从多模块（multi-module）到多包（multi-package）

项目的规模大了，依赖管理上的挑战也出现了。 Feature 之间要减少依赖， App 之间更要进一步隔离，跨 App 复用的模块，就不能简单地 import 了。

为了减少 App 之间的耦合，需要将复用单元需要封装成 package，然后，各个 App 在 package.json 中声明依赖。同样，在 Solution 的眼中，各个 App 也是 package。

通过从 multi-module 到 multi-package 的转变，耦合减小了，但给开发也带了新的成本，这些问题可借助于 Lerna 等工具解决。

使用 Lerna 可以解决依赖和版本管理的问题，除此之外，还要做好 package 的分层设计。

多包管理中的分层设计

App 是一个 package，App 依赖的模块也是一个 package，但是，两类 package 是不同『质』的。

为了让项目结构更清晰、易理解，我们需要区分这些 package，进行分层设计。例如：

packages
├── solutions
│   ├── login.sln
│   ├── finance.sln
│   └── people.sln
├── apps
│   ├── portal.app
│   ├── financial-management.app
│   ├── recruting.app
│   └── global-search.app
├── biz-libs
│   ├── workflow-engine
│   ├── rendering-engine
│   └── network
├── base-libs
│   ├── ui-components
│   └── animations
└── vendor-libs
    ├── router
    └── state-manager

总结

与 File-Type First 的文件组织方式相比， Feature First 在提升大规模项目的可维护性上有着明显的优势。

更易于查找、定位代码文件；
重构、修改代码时，更好地控制影响范围；
更利于使用 Feature Flags；

在组织应用内的共享组件时，可以遵循跟 CommonJS 类似的模块查找方式：组件只引用其所在文件各级路径下的 components 目录。

在企业级应用等大规模项目中，可以通过引入新的逻辑层次和多包管理，进一步控制项目复杂度。

参考资料

深入分析软件复杂度
feature-u: Feature Based Project Organization for React
A feature based approach to React development
How to better organize your React applications?
How to use Redux on highly scalable javascript applications?
The 100% correct way to structure a React app (or why there’s no such thing)

文章作者：孔常柱

BDEEFE 在全国各地长期招聘优秀的前端工程师，招聘需求了解下？