浅谈前端集成解决方案

[fouber]

每个前端团队都在打造自己的前端开发体系，这通常是一个东拼西凑，逐渐磨合的过程，在技术发展日新月异的今天，这样的过程真的是不可抽象和复制的么？本文希望能够通过系统的拆解前端开发体系为大家提供体系设计思路参考。

什么是前端集成解决方案

前端集成解决方案，英文翻译为 Front-end Integrated Solution，缩写fis，发音[fɪs]

前端集成解决方案并不是一个新词汇，将这个词拆开来看，我们能得到：

• 前端：指前端领域，即web研发中常用的浏览器客户端相关技术，比如html、js、css等
• 集成：将一些孤立的事物或元素通过某种方式改变原有的分散状态集中在一起，产生联系，从而构成一个有机整体的过程。[1]
• 解决方案：针对某些已经体现出的，或者可以预期的问题，不足，缺陷，需求等等，所提出的一个解决问题的方案，同时能够确保加以有效的执行。[2]

总结来说，前端集成解决方案就是：

将前端研发领域中各种分散的技术元素集中在一起，并对常见的前端开发问题、不足、缺陷和需求，所提出的一种解决问题的方案。

前端领域有哪些技术元素

前端行业经历了这么长时间的发展，技术元素非常丰富，这里列举出一般web团队需要用到的技术元素：

1. 开发规范：包括开发、部署的目录规范，编码规范等。不要小瞧规范的威力，可以极大的提升开发效率，真正优秀的规范不会让使用者感到约束，而是能帮助他们快速定位问题，提升效率。
2. 模块化开发：针对js、css，以功能或业务为单元组织代码。js方面解决独立作用域、依赖管理、api暴露、按需加载与执行、安全合并等问题，css方面解决依赖管理、组件内部样式管理等问题。是提升前端开发效率的重要基础。现在流行的模块化框架有requirejs、seajs等。
3. 组件化开发：在模块化基础上，以页面小部件(component)为单位将页面小部件的js、css、html代码片段放在一起进行开发、维护，组件单元是资源独立的，组件在系统内可复用。比如头部(header)、尾部(footer)、搜索框(searchbar)、导航(menu)、对话框(dialog)等，甚至一些复杂的组件比如编辑器(editor)等。通常业务会针对组件化的js部分进行必要的封装，解决一些常见的组件渲染、交互问题。
4. 组件仓库：有了组件化，我们希望将一些非常通用的组件放到一个公共的地方供团队共享，方便新项目复用，这个时候我们就需要引入一个组件仓库的东西，现在流行的组件库有bower、component等。团队发展到一定规模后，组件库的需求会变得非常强烈。
5. 性能优化：这里的性能优化是指能够通过工程手段保证的性能优化点。由于其内容比较丰富，就不在这里展开了，感兴趣的同学可以阅读我的这两篇文章 [1] [2]。性能优化是前端项目发展到一定阶段必须经历的过程。这部分我想强调的一点是 性能优化一定是一个工程问题和统计问题，不能用工程手段保证的性能优化是不靠谱的，优化时只考虑一个页面的首次加载，不考虑全局在宏观统计上的优化提升也是片面的。
6. 项目部署：部署按照现行业界的分工标准，虽然不是前端的工作范畴，但它对性能优化有直接的影响，包括静态资源缓存、cdn、非覆盖式发布等问题。合理的静态资源资源部署可以为前端性能带来较大的优化空间。
7. 开发流程：完整的开发流程包括本地开发调试、视觉效果走查确认、前后端联调、提测、上线等环节。对开发流程的改善可以大幅降低开发的时间成本，工作这些年见过很多独立的系统（cms系统、静态资源推送系统）将开发流程割裂开，对前端开发的效率有严重的阻碍。
8. 开发工具：这里说的工具不是指IDE，而是工程工具，包括构建与优化工具、开发-调试-部署等流程工具，以及组件库获取、提交等相关工具，甚至运营、文档、配置发布等平台工具。前端开发需要工具支持，这个问题的根本原因来自前端领域语言特性（未来我会单独写一篇文章介绍前端领域语言缺陷问题）。前端开发所使用的语言（js、css、html）以及前端工程资源的加载与定位策略决定了前端工程必须要工具支持。由于这些工具通常都是独立的系统，要想把它们串联起来，才有了yeoman这样的封装。前面提到的7项技术元素都直接或间接的对前端开发工具设计产生一定的影响，因此能否串联其他技术要素，使得前端开发形成一个连贯可持续优化的开发体系，工具的设计至关重要。

以上8项，1-3是技术和业务相关的开发需求，4是技术沉淀与共享需求，5-8是工程优化需求。

经过这些年的工程领域实践，个人觉得以上8项技术元素应该成为绝大多数具有一定规模的前端开发团队的标配。各位读者可以对照自己团队现状来思考一下团队开发体系还有哪些环节需要完善。

攒一套前端集成解决方案

不难发现，其实其他领域工程也基本需要解决上述这些问题。前端由于其领域语言的独特性，使得前端工程在解决这些问题上跟其他工程有很大区别，因此至今也没有形成一套比较好的理论体系指导团队实践前端工程。

仔细观察过一些团队的技术体系形成过程，大家都在努力拼凑上述8项技术元素的具体解决方案。单独观察每一项技术点，你或许会觉得都能各自找到已有的实现，但我要说，把所有8项技术点无缝的串联起来，是一项非常有挑战的工作，你信么？相信真正经历过这样事情的同学能明白我说的串联成本问题。

假设我们希望实践一套完整的前端集成解决方案，好了，如果我们单独去看每一项技术点，都可能会找来一两个现成的东西，假设我们东拼西凑的找全了所有8项技术要素对应的具体实现。接下来要用了，它们能很完整流程的跑起来么？

正如前面的贴图展示的那样，所有的技术点都有一定的内在联系：

• 模块化开发涉及到性能优化、对构建工具又有一定的配套实现要求，也会影响开发规范的定制
• 组件化开发应该基于模块化框架来加载其他依赖的组件，如果组件化框架自带模块管理功能，那么就可能导致工程性的性能优化实现困难
• 组件库应该与组件化开发配套，组件仓库中的组件都应该按照相同的标准来实现，否则下载的组件不具有可复用性、可移植性，就是去了仓库的意义
• 我们设计的开发规范工具是否能很容易的实现，如果部署上有特殊要求，工具是否能很容易的做出调整，而不是修改规范。
• 工具是否能提供接入公司已有流程中的接口，比如命令调用，如果工具需要一些系统环境支持，公司的ci流程中是否能支持等问题。

前端领域语言的特点决定了攒一套集成解决方案有很高的实现成本。因为前端语言缺少包、导入、模块等开发概念，这使得各个技术点的解决方案在设计的时候都是考虑被独立使用的情况下如何工作，因此或多或少的会延伸自己的职责。比如模块化框架要附属构建工具，甚至要求后端服务（比如combo），组件化框架自带模块化框架，构建工具自带部署规范等，这就大大提高了将各个技术要素融合起来的成本。

总之，前述的8项技术要素之间有许多联系，这就为打造一套完整连贯的前端集成解决方案带来了较大的挑战。如何兼顾规范、性能、框架、流程、部署等问题，就不是东拼西凑那么简单的事了。后面我会单独撰文介绍如何实现一套集成解决方案。

[maxzhang]

遗漏了测试，应该是九项

[fouber]

@maxzhang
我之前的想法是测试是流程中的一部分，没有特别列出来讨论，主要是关于前端的测试始终处于一个启蒙状态，感觉还不能大规模的应用上，后续单开一个栏目讨论这个方向，如果觉得有比较成熟的解决方案，那必然应该放到这里面，完善这张图。

[chemdemo]

写的不错 补充点个人见解：

1、关于组件化和模块化，这个粒度实在是不好拿捏，模块可以很大，也可以很小，小到一个函数成一个模块，所以我觉得模块应该主要是通用工具、api、类的封装，而组件更多的是业务功能、UI块的封装

2、关于组件仓库，其实bower、component之类的并不够，还有文档的生成与管理，使用别人写的代码，最快入手的就是看文档，其次才是看代码

3、还有，测试。纯工具和api之类的模块，很容易自动化测试，蛋是到了组件层面，设计业务逻辑、UI什么的，自动化太难了，还得靠人肉

[markyun]

mark

[fouber]

@chemdemo

恩，是这样的，本文只是列出了一些技术要素，介绍前端工程中的基本概念。模块粒度、组件划分、仓库建设以及测试是要各个方向展开来说明。欢迎提供相应的开发经验及总结。

[xufei]

@chemdemo 开发阶段用尽可能小的粒度，发布时候合并

[zack-lin]

组件化应该不是仅限于 UI 功能组件，整个缓存数据结构都可以作为组件 。@chemdemo 粒度很大的组件，比如 SPA 的每个页面都可以作为大组件，每个页面对外的接口只有 show 和 hide，页面的状态内部维护；同样，粒度小的组件也只有简单的 API，状态内部维护。

@fouber 性能优化真的是个工程问题+1。优化研究理论的支撑、复杂环境得出的模拟数据分析、模拟环境的搭建，都需要整一套工具体系，不然成本太高了。

[fanker]

高大上

[kbqncf]

不错，收获挺大的

[supersha]

mark

[haohcraft]

赞

[mingzepeng]

写得很好，收藏一下

[knightuniverse]

或许说这个有点不合适，但是这个集成方案，只适合产品型的前端团队。很多做企业软件项目的公司里，基本都是后端程序员兼做前端工作的，这个时候，前端不会很重视。

[fouber]

@knightuniverse 前端的概念确实非常广泛，做企业软件项目的公司不在这个讨论之列，因为没有严格意义上的前端。这篇文章的适用范围主要是互联网公司。

[WenTao-Love]

菜鸟，问一下，前端包括那些切图的事儿吗？

[fouber]

@WenTao-Love

当然包括啦。不过光关注切图恐怕很难应对大型互联网公司的集团军开发需求。十几个甚至几十个工程师团队问题蛮多的

[bubkoo]

看了两遍，也许还会看更多遍，好文常读读，结合自身在开发中遇到的问题，每次都有新的体会

[fouber]

@bubkoo 多谢关注！

[boiawang]

这样的流程对小公司是个很大的挑战，对于小公司来说，没有多余的人手和时间去做组件化或单元测试

[fouber]

@boiawang

恩，除了组件化需要借助大公司的产出之外，其他是很需要的。

[opoo]

文章不错啊，收藏了！

ps:把GitHub的Wiki当作博客用，其实挺有创意的。

[fouber]

@opoo

我也是看到别人这么做的

[Hao-Wu]

写的不错。但是这样不利用积累传播啊。比如我想订阅你的博客，就无解了。不如用github pages + octopress搭blog吧。

[opoo]

@Hao-Wu 你只要watch这个库，就能收到新内容的邮件通知了，多好。

广告：用java的童鞋，可以考虑用GitHub Pages+OpooPress搭建博客。 ：）

[jia58960]

对我们这些搞前端的很有启发性。期望云龙兄能出更多更好有关前端集成的文章。watch！

[fouber]

@jia58960

多谢关注

[ghost]

mark

[webfing]

高大上

[itbainianmei]

道理是非常到位的，就是觉得达到整体流程的流利运作或者说无缝串联是个难于上青天的事！部门与部门之间有技术、职责、以及个人责任感的局限性，达不到完全统一的效果。只能说做到最优的最大化，这个最大化实际上也是很小的。

[youngwind]

看了好几次了，每次看一遍就有更深的认识。没看完一回就会研究一小部分，感觉要完全实现还有很长的路要走呢！

[mishe]

收藏转帖mishe/blog#78

[xuess]

不错。。

[boxizen]

赞，时隔两月再次阅读，对文章中讲的很多东西有了更深的理解。

[zhangqiusheng]

最近在学习前端集成构建。了解过fis3，感觉很是不错，有些遗憾的是没有把测试加进去。不知道测试这块有计划加入？

[qqqzhch]

mark

[CaroseKYS]

龙哥一下子铺开了前端工程应该掌握的知识体系，非常感谢。前两天还在为前端工程的事情发愁，看了龙哥的文章觉得努力方向灰常明确了。

[turnerguo]

不得不赞一个，Github还可以这么用，当博客了~

[haledeng]

@nimojs 你这里的流程是前端定义数据接口（前端驱动型），完善文档，然后后台接口返回对应的数据。
其实好多公司的流程正好和这个相反，后台定义接口（和前端会有一些约定），然后更新接口文档，前端根据接口文档来调试，或者mock数据等

[nimoc]

@haledeng

1. 后端定义接口 + 最终前端提出修改意见
2. 前端定义接口 + 最终后端提出修改意见

选哪种方式根据公司时间情况决定，谁来主导也不重要，只要大致流程是

1. 先阅读接口并编写文档
2. 前端根据接口文档调试模拟 ajax 模拟后端模板渲染，后端根据接口文档coding 测试。

就可以了

[nimoc]

@haledeng
最好是前后端共同在一个在线平台编写接口文档，最终接口文档系统生成一个本地 node 环境，供前端测试模拟。

在线平台可记录修改记录和强制编写修改原因。
有时候还需要对接口的修改做版本控制

[tianxiaofeng747]

mark

[VigourJiang]

学习了，两年过去了，读了之后仍然很有收获

[TongDaDa]

文中提到的工程角度，能否具体描述一下，谢谢

[hyram6]

读过之后还是很有收获的，来学习了，谢谢

[junekee]

学习哈！谢谢分享！

---

http://www.laoguo.xyz/

[Yan2603]

mark

[YonSunZhen]

666

[YangPengFe1]

菜鸟，问一下，前端包括那些切图的事儿吗？

你成功的逗笑了我。

[ericzzhou]

图裂了

[wuweikd]

14的你还是程序员，19年的你已经是创始人

[mzh0922]

不知道现在2019年了，也结束了，还会更新什么呢？还会维护这里的github么？

[kbqncf]

那么多年过去了，希望大家还是不忘初心，年轻&热泪盈眶