React 最佳实践：按领域组织文件夹结构

随着功能的增加，项目会变得越来越复杂。要改善或者解决这个问题，关键就在于：每增加一个新的功能，整个应用程序的复杂度不应该明显上升。

# 软件复杂度的根源：复杂的依赖关系

如果仔细思考就会发现，当某个功能需要层层嵌套的模块依赖，那么即使开发时觉得思路很顺，但是再回头去看，或者要让别人理解某个功能实现，就不得不去翻阅很深的调用链。这就是让觉得复杂的直接原因。

软件复杂度的根源完全来自复杂的依赖关系。

降低依赖，让整个大型应用的复杂度始终在可控范围内？ 只有这样，在团队内，无论是代码写得比较初级的新手，还是总想尝试新技术新方式的探索者，再或者是代码写得很漂亮的老手。他们都能在各自的功能模块内完成业务功能，而且尽可能少地互相影响，从而始终保证整个架构的可扩展。

# 按领域组织文件夹结构

很多时候源代码没有按照业务功能组织在一起，而是从技术角度进行了拆分，产生了开发难度。

对于文件夹的组织，按领域去组织源代码。一个与领域相关的文件夹， 自身包含了自己需要的所有技术模块，这样无论是理解代码实现，还是开发时切换导航，都会非常方便。

那么，在每一个独立的功能下面，无论怎么组织源代码，都不会有太大的问题，因为都是很小的文件夹。

同时，也要尽量扁平化地组织所有代码，而不是再去按小的功能去增加嵌套的文件夹。否则，如果再回头去看代码，或者新加入的成员去看，会增加理解成本。

# 处理模块间的依赖

把依赖从技术层面提升到业务层面，也就是一个业务功能对另外一个业务功能的依赖。

硬依赖：如果功能 A 的实现必须基于功能 B，也就是说没有功能 B，功能 A 就是不可运行的，那么我们可以说 A 硬依赖于 B。

软依赖：如果功能 B 扩展了功能 A，也就是说，没有功能 B，功能 A 自身也是可以独立工作的，只是缺少了某些能力。

有时候，虽然在业务功能上是一个软依赖，但是在代码实现层面，却往往做成了硬依赖。这就导致随着功能的不断增加，整个应用变得越来越复杂，最终降低了整体的开发效率。

必须想办法，让模块之间的交互不再通过硬依赖。

使用扩展点机制：在任何可能产生单点复杂度的模块中，通过扩展点的方式，允许其它模块为其增加功能。