本文翻译自FIRST。
组件必须职责单一(Focused)，独立(Independent)，可重用(Reusable)，小(Small)并且可测试(Testable) (FIRST)
无论它是一个客户端或是服务器端的组件，一个Node模块或是一小块视觉设计UI，那些足够大的组件天生就会比那些小组件更加复杂，以至于很难维护。
事实上，高效地构建“大”组件的秘诀一般来说首先就是尽量地避免去构建它。相反，应该将一些更小的，职责更加单一的组件组合成你所需要的“大组件。这样一来就可以更加容易看清楚这些小组件在一个更宽广的视野里如何在一起工作的。这些概念也适用于一些已经存在的构建组件的技术上，包括Web Components。
在Node社区里，职责单一和模块化已经取得一定程度上的成功，并且与我们所知领域的其它东西同等重要，原因如下：
更小的APIs更加容易去学习和教会他人。如果你只做一件事并把它做好，那么这个通常是有帮助的。
代码重用 能够节约你的时间。如果写的代码碰巧是有良好的结构和清晰的逻辑，那么可重用性往往是附带的。与从头开始写组件相比，这个在你接手参与一个已有组件开发时格外有用。也许你会发现原有设计里的错误，并且你会逐渐改善它，但是，当你的组件重用得越频繁，你修复的错误就会越多，同时也提高了可重用性。
更好的组合。这意味着组件可以通过扩展已有的组件来构建。这样一来同时又允许实现大量的代码重用，避免在不同的项目中重新实现同样的功能。
可维护性的增加是有可能的，这也是得益于复杂度的减少。通过拆分一个组件为一些更小的组件，一般来说会更容易测试和文档化。保持你的组件DRY也是有帮助的。
关注分离如果每个组件只负责解决一个特定的问题，这样会简化更新周期，因为一个组件常常不需要知道其它组件的细枝末节。注意，关注分离并常常等同于技术的分离。保持一个系统逻辑上相关的部分在一起能让系统更容易去理解和维护。
简化调试。这个更加贴近特定的实现，那么在粒度上就必须让它更加直接发现问题并解决它，这是通过更加简单地确定错误的根源而达到的。
更加容易理解你的庞大系统，这是因为你把它拆分为更小的，更加细粒度的部分。
总的来说，在构建组件时，时刻谨记模块化和职责单一，可以增加组件重用性，简化维护并且提高可扩展性。
如果你正在构建的组件需要与社区或是仅仅是在你的团队里面分享，那么问问你自己，在你的API里面的这些功能是否会被90%以上的用户使用。如果答案是肯定的，那么它很有可能就是核心功能并且应该保留。如果一个功能将会被10%的启用使用，那么它很有可能就是一个单独的组件或是模块。避免代码膨胀。
某些人也许读到这篇文章时会想，“太好了！…但是从实践上来说，从一开始就实现模块化往往不太现实”。这样说也是有道理的。一些开发者会认为从一开始就构建一个完整的解决方案，然后再抽取出可用的模块，如此这样做会更加容易一些。这样做的话，可以在设计一些公共接口时节约出很多时间，特别是当这些公共接口有可能是往错误方向前进时。但是无论你选择哪种方案，最终都会导致相同的目的：你将拥有一大堆的可以在以后的项目中重用的组件。
当你尝试准备去构建一个组件时，无论它是视觉化的或是非视觉化的组件，请尽量记住以下五件事：
或者简言之，FIRST。