【转载】前端项⽬开发流程及技术选型
喂喂喂，那个切图的，把页⾯写好就发给研发⼯程师套模板吧。
你好，切图仔。
不知道你的团队如何定义前端开发，据我所知，时⾄今⽇仍然有很多团队会把前端开发归类为产品或者设计岗位，虽然⾝份之争多少有些⽆谓，但我对这种偏见还是⼼存芥蒂，酝酿了许久，决定写⼀个系列的⽂章，试着从⼯程的⾓度系统的介绍⼀下我对前端，尤其是Web前端的理解。
只要我们还把⾃⼰的⼯作看作为⼀项软件开发活动，那么我相信读过下⾯的内容你也⼀定会有所共鸣。
前端，是⼀种GUI软件
现如今前端可谓包罗万象，产品形态五花⼋门，涉猎极⼴，什么⾼⼤上的基础库/框架，拽炫酷的宣传页⾯，还有屌炸天的⼩游戏……不过这些⼀两个⽂件的⼩项⽬并⾮是前端技术的主要应⽤场景，更具商业价值的则是复杂的Web应⽤，它们功能完善，界⾯繁多，为⽤户提供了完整的产品体验，可能是新闻聚合⽹站，可能是在线购物平台，可能是社交⽹络，可能是⾦融信贷应⽤，可能是⾳乐互动社区，也可能是视频上传与分享平台……
从本质上讲，所有Web应⽤都是⼀种运⾏在⽹页浏览器中的软件，这些软件的图形⽤户界⾯（Graphical User Interface，简称GUI）即为前端。
如此复杂的Web应⽤，动辄⼏⼗上百⼈共同开发维护，其前端界⾯通常也颇具规模，⼯程量不亚于⼀般的传统GUI软件：
尽管Web应⽤的复杂程度与⽇俱增，⽤户对其前端界⾯也提出了更⾼的要求，但时⾄今⽇仍然没有多少前端开发者会从软件⼯程的⾓度去思考前端开发，来助⼒团队的开发效率，更有甚者还对前端保留着”如玩具般简单“的刻板印象，⽇复⼀⽇，⼑耕⽕种。
历史悠久的前端开发，始终像是放养的野孩⼦，原始如斯，不免让⼈慨叹！
前端⼯程的三个阶段
现在的前端开发倒也并⾮⼀⽆所有，回顾⼀下曾经经历过或听闻过的项⽬，为了提升其前端开发效率和运⾏性能，前端团队的⼯程建设⼤致会经历三个阶段：
第⼀阶段：库/框架选型
前端⼯程建设的第⼀项任务就是根据项⽬特征进⾏技术选型。
基本上现在没有⼈完全从0开始做⽹站，哪怕是政府项⽬⽤个jquery都很正常吧，React/Angularjs等框架横空出世，解放了不少⽣产⼒，合理的技术选型可以为项⽬节省许多⼯程量这点⽏庸置疑。
第⼆阶段：简单构建优化
选型之后基本上就可以开始敲码了，不过光解决开发效率还不够，必须要兼顾运⾏性能。前端⼯程进⾏到第⼆阶段会选型⼀种构建⼯具，对代码进⾏压缩，校验，之后再以页⾯为单位进⾏简单的资源合并。
前端开发⼯程化程度之低，常常出乎我的意料，我之前在百度⼯作时是没有多少概念的，直到离开⼤公司的温室，去到业界与更多的团队交流才发现，能做到这个阶段在业界来说已然超出平均⽔平，属于“具备较⾼⼯程化程度”的团队了，查看⽹上形形⾊⾊的⽹页源代码，能做到最基本的JS/CSS压缩的Web应⽤都已跨⼊标准互联⽹公司⾏列，不难理解为什么很多前端团队对于前端⼯程构建的认知还仅停留在“压缩、校验、合并”这种程度。
第三阶段：JS/CSS模块化开发
分⽽治之是软件⼯程中的重要思想，是复杂系统开发和维护的基⽯，这点放在前端开发中同样适⽤。在解决了基本开发效率运⾏效率问题之后，前端团队开始思考维护效率，模块化是⽬前前端最流⾏的分治⼿段。
很多⼈觉得模块化开发的⼯程意义是复⽤，我不太认可这种看法，在我看来，模块化开发的最⼤价值应该是分治，是分治，分治！
（重说三）。
不管你将来是否要复⽤某段代码，你都有充分的理由将其分治为⼀个模块。
JS模块化⽅案很多，AMD/CommonJS/UMD/ES6 Module等，对应的框架和⼯具也⼀⼤堆，说起来很烦，⼤家⾃⾏百度吧；CSS模块化开发基本都是在less、sass、stylus等预处理器的import/mixin特性⽀持下实现的。
虽然这些技术由来已久，在如今这个“⾔必及React”的时代略显落伍，但想想业界的绝⼤多数团队的⼯程化落后程度，放眼望去，毫不夸张的说，能达到第三阶段的前端团队已属于⾼端⾏列，基本具备了开发维护⼀般规模Web应⽤的能⼒。
然⽽，做到这些就够了么？Naive！
第四阶段
前端是⼀种技术问题较少、⼯程问题较多的软件开发领域。
当我们要开发⼀款完整的Web应⽤时，前端将⾯临更多的⼯程问题，⽐如：
⼤体量：多功能、多页⾯、多状态、多系统；
⼤规模：多⼈甚⾄多团队合作开发；
⾼性能：CDN部署、、、缓存复⽤、请求合并、按需加载、同步/异步加载、移动端、HTTP 2.0服务端。
扩展阅读：
这些⽆疑是⼀系列严肃的系统⼯程问题。
前⾯讲的三个阶段虽然相⽐曾经“茹⽑饮⾎”的时代进步不少，但⽤于⽀撑第四阶段的多⼈合作开发以及精细的性能优化似乎还⽋缺点什么。
到底，缺什么呢？
没有银弹
读过《》的⼈应该都听说过，软件⼯程 。没错，前端开发同样没有银弹，可是现在是连™都没有的年⽉！（刚有了BB弹，摔）
前端历来以“简单”著称，在前端开发者体中，⼩⽽美的价值观占据着主要的话语权，甚⾄成为了某种信仰，想与其他⼈交流⼀下⼯程⽅⾯的⼼得，得到的回应往往都是两个字：太重。
重你妹！你的脑容量只有4K吗？
⼯程⽅案其实也可以⼩⽽美！只不过它的⼩⽽美不是指代码量，⽽是指“规则”。到问题的根源，⽤最少最简单明了的规则制定出最容易遵守最容易理解的开发规范或⼯具，以提升开发效率和⼯程质量，这同样是⼩⽽美的典范！
2011年我有幸参与到 项⽬中，与百度众多⼤中型项⽬的前端研发团队共同合作，不断探索实践前端开发的⼯程化解决⽅案，13年离开百度去往UC，⾯对完全不同的产品形态，不同的业务场景，不同的适配终端，甚⾄不同的⽹络环境，过往的⽅法论仍然能够快速落地，为多个团队的不同业务场景量⾝定制出合理的前端解决⽅案。
这些经历让我明悟了⼀个道理：
进⼊第四阶段，我们只需做好两件事就能⼤幅提升前端开发效率，并且兼顾运⾏性能，那就是——组件化开发与资源管理。
第⼀件事：组件化开发
分治的确是⾮常重要的⼯程优化⼿段。在我看来，前端作为⼀种GUI软件，光有JS/CSS的模块化还不够，对于UI组件的分治也有着同样迫切的需求：
如上图，这是我所信仰的前端组件化开发理念，简单解读⼀下：
1. 页⾯上的每个 独⽴的 可视/可交互区域视为⼀个组件；
2. 每个组件对应⼀个⼯程⽬录，组件所需的各种资源都在这个⽬录下就近维护；
3. 由于组件具有独⽴性，因此组件与组件之间可以 ⾃由组合；
4. 页⾯只不过是组件的容器，负责组合组件形成功能完整的界⾯；
5. 当不需要某个组件，或者想要替换组件时，可以整个⽬录删除/替换。
其中第⼆项描述的就近维护原则，是我觉得最具⼯程价值的地⽅，它为前端开发提供了很好的分治策略，每个开发者都将清楚的知道，⾃⼰所开发维护的功能单元，其代码必然存在于对应的组件⽬录中，在那个⽬录下能到有关这个功能单元的所有内部逻辑，样式也好，JS也好，页⾯结构也好，都在那⾥。
组件化开发具有较⾼的通⽤性，⽆论是前端渲染的单页⾯应⽤，还是后端模板渲染的多页⾯应⽤，组件化开发的概念都能适⽤。组件HTML 部分根据业务选型的不同，可以是静态的HTML⽂件，可以是前端模板，也可以是后端模板：
不同的技术选型决定了不同的组件封装和调⽤策略。
基于这样的⼯程理念，我们很容易将系统以独⽴的组件为单元进⾏分⼯划分：
由于系统功能被分治到独⽴的模块或组件中，粒度⽐较精细，组织形式松散，开发者之间不会产⽣开发时序的依赖，⼤幅提升并⾏的开发效率，理论上允许随时加⼊新成员认领组件开发或维护⼯作，也更容易⽀持多个团队共同维护⼀个⼤型站点的开发。
结合前⾯提到的模块化开发，整个前端项⽬可以划分为这么⼏种开发概念：
| 名称 | 说明 | 举例 |
| JS模块 | 独⽴的算法和数据单元 | 浏览器环境检测(detect)，⽹络请求(ajax)，应⽤配置(config)，DOM操作(dom)，⼯具函数(utils)，以及组件⾥的JS单元 |
| CSS模块 | 独⽴的功能性样式单元 | 栅格系统(grid)，字体图标(icon-fonts)，动画样式(animate)，以及组件⾥的CSS单元 |
| UI组件 | 独⽴的可视/可交互功能单元 | 页头(header)，页尾(footer)，导航栏(nav)，搜索框(search) |
| 页⾯ | 前端这种GUI软件的界⾯状态，是UI组件的容器 | ⾸页(index)，列表页(list)，⽤户管理(user) |
| 应⽤ | 整个项⽬或整个站点被称之为应⽤，由多个页⾯组成 | |
以上5种开发概念以相对较少的规则组成了前端开发的基本⼯程结构，基于这些理念，我眼中的前端开发就成了这个样⼦：
| ⽰意图 | 描述 |
angular和angularjs
|  | 整个Web应⽤由页⾯组成 |
|  | 页⾯由组件组成 |
|  | ⼀个组件⼀个⽬录，资源就近维护 |

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。