从0到1进行前端架构的总结

    关于前端架构这个主题，思考了很多年，也沉淀了些东西，希望写下来总结一下，查漏补缺。

目录：

一、架构的原则

二、架构的过程

    1、项目信息收集

    2、技术预研及选型

    3、目录结构

    4、自动化构建

    5、基础组件

    6、通用解决方案

    7、迭代方案

三、架构的持续优化

正文：

一、架构的原则

       我们先试想一下建一栋房子，如果给它做技术架构，原则是什么？恐怕第一原则就是安全稳定了，然后就是可以让工人可以快速有序的进行工作（例子有点蹩脚……）。项目进行前端架构，主要目的还是为了提高开发效率，方便维护，前端架构的过程一般都会选择合适的前端框架，框架的原则如安全、稳定、集成、解耦等框架本身已经考虑得比较周到了，这里我主要想强调的是，在前端架构的过程中，不要忘记的几个原则：

1、始于需求：一定要向需求看齐，所有的架构思路要符合实际需要，不要为了“炫技”而写多余的代码。（当然，另一方面，也可以通过好的架构思路去引导需求往更好的方向发展）

2、降低成本：在架构的过程中一定要牢记“成本”二字，包括开发成本、维护成本、时间、精力等等，架构的过程中所做的工作，大部分是要让开发的同学只用专注于业务，其他可能干扰开发的事情要在最开始解决掉，比如目录、打包、发布、以及其他比较麻烦的特定功能。

3、合适的才是最好的：技术是为解决问题而生的，要寻找最符合当下情况的特定解决方案，才是我们最需要的。

        以上三点原则，切记要始终贯穿架构的整个过程。

二、架构的过程

    1、项目信息收集

        在所有的开始之前，首先需要对即将要做的项目有针对性的进行有效信息收集，做一件事情之前一定要先了解这件事情的意义，做项目亦如此。我们需要搞清楚这样几件事情：

    1）这个项目的背景（为什么要做？为了解决什么问题？紧急程度如何？重要性？）

    2）这个项目和现有项目的关联和它所在的位置（这个是为了确定边界和影响）

    3）这项目的用户群体（是toB还是toC？是否有SEO要求？手机端还是PC端？使用设备及浏览器情况？访问高峰期时间？用户规模多大？）

    4）项目涉及的业务的了解（特定业务知识储备、竞品了解、可能遇到的特定难题）

        这个过程主要是为了建立起一个全局观，也引导架构最终所确定的形态，所以不要急于写代码，可以在脑海里先回顾下这些信息有没有了解充足，再有所计划的开展下一步。

    2、技术预研及选型

        在充分掌握了项目信息之后，我们需要选择合适的前端框架来实现我们的项目，并且对所用技术做进一步研究。这个过程，说简单也简单，说复杂也复杂，主要看团队和主导者的经验和能力。

        技术选型大概会考虑这些因素：

        1）PC端还是手机端

        2）toB还是toC

        3）用户规模

        4）浏览器支持情况

        5）项目是否需要支持SEO

        6）团队成员对该技术（或框架）的掌握情况：是否有人可以全局把控、学习成本是否可以接受等

        7）该技术能否可以满足业务需求

        8）该技术（框架）本身的稳定性，它的社区、维护者等

        具体到前端框架的选择，在2018年的当下，比较前沿的选择有React、Vue、Angular，然后是相应的生态延伸（数据流管理、UI框架），三者比较类似，根据团队情况选其一即可。如果为了满足更多浏览器和更复杂的业务场景，选择Sea.js或者Require.js再加上jquery，也是不错的选择，向前看的话，暂时不讨论这种场景。

        说到技术预研，这里展开说几点。如果对所选定的框架不够熟悉，还是不要轻易的用在正式的项目里面，如果无法对框架有比较全局的把控，贸然使用可能会产生灾难性的后果。所以，这种情况下，正确的姿势是做好充分的研究，首先架构者本身需要对框架有足够的学习，然后小规模在不太重要的项目里面实验和实践，有了一定的沉淀之后，再使用到比较重要的项目里面，才是比较保险的和成熟的做法。毕竟“合适的才是最好的”，没有人对框架有足够的把控，很明显是不合适的。

    3、目录结构

        目录结构为什么要单独拎出来说呢？因为每次设计目录的时候，都要考虑很久，有时候也会更变很多次，所以花费时间这么久的这个东西，肯定有一定的重要性。清晰的目录结构，会让整个项目显得有逻辑性，便于管理源代码，也方便开发人员去识别不同的文件夹和文件，这样就可以快速找到特定文件的特定代码，大大降低了对整个项目的理解成本，也让新同学可以快速上手。

        举个例子，之前看到一个别人家的项目，一打开，主目录下上十个文件夹，然后随便点开其中某个文件夹，下面又有十几个文件，顿时一脸懵逼，这大大增加了新同学熟悉项目的成本。具体怎样创建好目录，没有特定的方法，但有约定俗成的命名，比如build、server、assets、src、dist等，我比较推荐主目录下的文件夹不要太多，按照约定俗成的命名方法分好类，不宜分的过细也不宜太粗，总之是让其他同学可以一眼知道这个文件夹、这个文件是做什么的，可以很快的检索出某个页面需要的特定相关文件。这里列出个例子，供参考。

    4、自动化构建

        自动化构建是前端架构过程中非常重要的一环，架构者可以多花点时间和精力在上面，这个过程对整个团队的开发效率以及项目的整理质量有很大关系，可以让开发的同学在开发的过程中只用关心业务逻辑，不会被其他问题干扰。目前自动化构建工具的选择有webpack、grunt、gulp、fis等，各有各的优劣，按照项目实际情况选择一个即可。

        自动化构建过程主要要考虑和解决好以下几个部分：

1）提高开发效率：热加载、开发和生产代码分离

2）优化性能：代码合并压缩、文件版本号、按需加载、图片优化

3）提高代码质量：模块化、ES6+Babel编译、css预处理、eslint代码检查、无用代码片段过滤

        项目的架构在最开始都会有很多的优化空间，在开发的过程中需要不断对不足的地方进行优化，所以项目的架构过程是一个不断完善的过程。

    5、基础组件

        如果我们引入一些成熟的UI框架，项目的基础组件很大一部分都得到了解决，比如弹框、日期、分页等控件。那这里强调的基础组件，一类是对这些UI控件的二次封装，比如下拉框、多选框等，第二类是公用的组件，比如头部、尾部、加载状态、为空状态等，这些在架构的过程中可以提前考虑下。

    6、通用解决方案

        通用解决方案主要解决项目中大家都会遇到的比较麻烦的问题，提供通用的解决办法供所有开发者调用，避免多次重复解决。不同的项目有不同的通用问题，这里列举些我遇到的问题：

• 样式的基础库
  
• 自定义主题色
• 字体图标的引用
• 移动端屏幕适配
  
• 错误处理
  
• 按需加载
• 图片懒加载
• 多语言支持
• 跨域处理
• 工具类方法封装
• 路由处理
• 加载中状态处理
• 服务端渲染
• 登录状态的判断
• 不同环境的配置文件
• 增量打包发布

          处理通用解决方案是耗时较多的一个过程，虽然业界已有相应的解决方案，但我们架构项目时，需要知道我们要考虑哪些问题，才能引入合适的解决方案。所以最怕的是不知道我们自己不知道，所以我们需要去积累和总结。

7、迭代方案

        很多东西都不是一蹴而就的，互联网项目追求的多大是敏捷开发，小步快跑，不断迭代。所以我们架构时要考虑下迭代方案，一般业界有约定俗成的方案，用branches、trunk、release分别表示分支、主干、发布版本，最新代码放在release，和线上保持同步；测试代码放在trunk，开发代码放在brances，同一项目同一时期有多个版本就在brances里面拉取多个分支，提测时都合并到trunk。  不同的团队根据实际情况，处理方案都有差异，这个跟迭代周期有关。当然还有其他的解决方案，暂不讨论了。

三、架构的持续优化

        还是那句话，很多东西都不是一蹴而就的，架构也没办法在最开始一次把所有问题都解决好，也是在后面的开发中不断优化的。但我们需要一个机制让我们的架构得到优化的同时可以应用到不同的项目中，当我们需要创建新项目时，我们要怎样才可以引用到不断优化的那个项目架构呢？

        有一个比较可行的方案是，把不涉及到业务逻辑的空项目框架（包含通用解决方案）发布到npm上，也就是适用于当前团队项目的特殊的项目脚手架，我们需要优化时就修改完发布，有新项目要用时，拉下来即可用。这样，所有人的优化成果都可以得到体现，也可以受益于所有项目。这里有个需要强调的地方，就是要确保发布出去的东西完全没有问题，这就需要一个监控和审核机制，确保解决方案的可靠性。

结语：

        断断续续写了些天，思考到了一个点，关于前端架构，网上并没有查询到太多“具体怎么去做”的文章，可见，架构的过程是没有什么模子去复制的，架构是跟着项目走的，是在具体的项目实践中衍生的。我目前能想到的最好的解决办法是，创建适用于自己项目的脚手架，并不断优化。以上我总结的前端架构过程主要适用于我所遇到的项目，当然也还有些共性的东西，仅供参考。