程序员技术栈程序员

前端架构那些事儿

2018-02-07  本文已影响66人  神秘者007

1. 主干列表

image.png

2. 前言

image.png
  1. 统帅全军

首先你的人格不能分裂,别人的意见你要能听得进去,别人可能会觉得不合理或者什么意见,你要能虚心的接受,而且能从中去改变一些东西,这是你必须要做的,你的架构需要得到所有人的认可,如果没有你这个架构就失败了,有一句话叫做:不能为了架构而架构,而是为了适配业务适配人。举了一个 地图 项目的案例从开始的使用 PHP 到后来的为了团队选择了 NodeJS,所以说统帅全局需要的是综合素质的自我修养,要有软素质和硬能力

  1. 消息通讯

在我们平时进行开发的时候,大家需要注意的是 消息通讯 的机制,比如说有一种设计模式叫做 观察者--示例来自汤姆大叔,可以监听到别人触发回来的这样一个事件,比如说: a b 两个人,a 做了一件事情,他把这件事情做好之后需要告诉 b,那个 b 要得到这个消息,你要能编写这种消息传递的组件然后来促进整个团队在开发的时候进行这样的融合;再举个例子:做地图的定位,定位成功了,那么需要定位的其他组件能监听到这个定位成功,你怎么去释放呢?用最简单的方法 jquery 里面的三个函数 ontriggeroff 这三个函数就能组成一个非常经典的事件监听器,具体的可以查看上面的 观察者 链接

  1. 插件随组

就是说将整个项目以插件化的形式来生成,比如说:index.html 里面的内容就可以是 render 的其他一些模块的内容,可以随意地去组合,也可以随意地去替换,这样可以将业务更好的扩展

  1. 本地可调

有一个比较专业的名词叫做 mock data (模拟数据),以前的时候我们前端调试代码就要装一堆像 .NET 开发需要的 VS IIS 等等需要启动服务的东西,会特别的繁琐,现在 NodeJS 启个 server 就非常的方便了,用 webpack 、koa、express 等等都可以了,做前端需要做的是前端方面的容错机制、接口规范,这样可以有很好地用户体验

  1. 多端方案

现在的一个方案如果说随着你业务的扩充,一定让你现在所织构的框架能够去容纳多端,就是你开发的组件是可以随意地发布到 Android 、 iOS 甚至是其他硬件(电视)端,所以当你选择这个技术框架的时候,你一定要为了这种多端去准备,现在有好多技术都可以支持跨端,比方说: NW ,它可以让我们的 JS 跨 PC 端,所以一定要为这个做好准备,假设有一天你的客户端突然需要一个同样的组件,这样就可以直接拿来用,不用再重新去写了,你要能把这些东西快速的发布成一个小的 SDK(软件开发工具包),这样是作为一个前端架构师的准备工作,把这个发布成一个小的 SDK 就需要有一定的编程基础了 比如说: Java 。
如果上述的 5 条你都考虑到了,就算是一个比较优秀的工程师了

  1. 代码分模

主要就是模块化,在早期的模块化有很多的处理方案,比如说:CJS(commonJS)、RequireJS (JavaScript 文件和模块的加载器)等等,那么现在的分模呢,已经到了 ES6、import、万物皆模块、webpack 这种的时代了,你要做的就是把这些东西分清,这些模块是怎么组合的,比如说:你一个 css、js、html 组成了一个模块,这样也是一个分模的方法;把所有的 js 组合到一块,也是一种分模的方法;但是一定要注意这些东西得有一个非常详细的模块划分,你需要画出一张图告诉你的老大 你的这些代码预计上线之后将来扩充所有模块该是什么样的,那么你的老大也会清晰的知道你的能力

  1. 雅虎军规

这个是面试里必问的问题,所有的网站、所有的做这种前端构建的时候为的是什么呢 为的就是,其中一个是编译:让代码写的更爽,还有一个就是让这个产品别人用起来更爽,所以呢 雅虎军规的目的就是让代码上线之后更爽,说白了为了性能的,所有的雅虎军规都是为了性能而生的,比如说:把 html 中的 js 文件放到 body 里面怎么怎么的,这就是雅虎军规里第一条非常简单的,就是你要了解整个网页,整个雅虎军规有将近二三十条,那么你做这样一个前端工具的时候如果没有遵循到雅虎军规,比如说:你用 webpack 把所有的 js 文件都编译了,然后你会发现所有的 script 都把页面给堵住了,那你这个架构就没有人会去认可,因为上线之后性能非常差,所以在做这样的前端架构的时候一定要去考虑到雅虎军规,如果你没考虑到这个那么前面 6 条你做的基本上就是废掉的,所以这个是非常重要的

  1. 工业为先

这个意思就是说:少去做你人肉的去操作,比如说:一般的 html 上线之前要压缩,那么有很多的压缩方式,你可以上百度去搜索 html 压缩 把 html 复制过去然后压缩,压缩好了在复制回来,这样一个就好了,但是这只是一个,如果是成百上千个肯定不可能再人肉去操作了,所以一定要有一些工程化的东西,为什么会有 Grunt、Gulp 这样的东西呢,实质上它们帮助我们做了这些工业的事,工业化的前端就是说,它像一条流水线一样,把我们这些东西塞进去然后产出一些东西,那么这就是工业为先,一定要注意前端的架构要保持这种工业为先的理念,如果说你没有很好地去利用到当前你手头的编译工具而是发现很多东西自己在手动的去做那么这个架构也是失败的

  1. 持续可扩

我们都知道因为这个产品变化的节奏很快,那么一定要注意哪些东西要有这种长远的打算,不能说这个文件夹先这样吧、把这个文件夹先扔这吧怎么怎么样的,你一定要有长远的考虑,像是这个组件可以扩展、还有一些公用的文件全都提出去,早早地做打算才能让你这个架构越来越并发,否则就造成了在国内软件开发非常严重的问题--重构,你们会经常发现项目被重构了,为什么呢,就是因为之前的很多东西没有想好,没有做好这种持续可扩的准备,那么在持续可扩的技术之前呢,也要做一个非常重要的东西就是 技术选型,那么这个技术选型一定要具有一定的前沿性,就比如说:你现在的项目用 ES6 ,过两年可能浏览器就普遍了,现在我们用 babel 编译,将来呢就不需要 babel 编译,可以直接扔到线上了,这个就是持续可扩一个非常经典的例子

  1. 一键部署

这个需要去了解运维,之前也了解过像 LVS(Linux虚拟服务器)、Keep-Alive 等等这些的东西,因为将来你要把你这个项目实际的放到线上去,运维工程师不了解前面的 9 条前端架构师干的活,他是负责把服务器做好,不让你的服务器崩掉,怎么在服务器上取这些服务需要靠你 一键部署,我们可以用 Yeoman 或者是其他的工具去做,比如说:你用一个 Grunt 定义一个 default tast(默认的任务),只要你执行一个 grunt 项目就编译完了,然后用一句 shell 脚本 把这个项目 SEP 到本地 再到远程服务器,远程服务器自动刷新系统给你一分,这样就完了,但是前提是你一定得按你当前这个目录把整个一个网站全部搞定,就是说运维他不懂你这个前端到底都干了些什么 ,所以说你给运维一个命令让他发布成功,这个项目就算是 OK 了

上面这 10 条只要你能理解透了,那基本的面试官就难不住你了

3. 初入江湖

image.png

在你刚成为一个前端工程师的时候,你需要做的事情就是:压缩
文件 MD5 就是给它加一个戳,我们平时会看到有人在 link 一个 a.css 的时候,后面会加一个 ? 什么的,比如说 a.2015 什么的,这个跟这个戳差不多,主要是为了不让这个 css 文件在本地有太多的缓存,这个是早期的用法,但是现在都做的是这种 MD5 的比较,给这个文件值后面加这么一堆 ,比方说:a.554.js 下次上面就变成了 a.5644.js ,这样上一个文件就不会被缓存调了,这些都是最基础的东西了

image.png image.png

tinypng 是一个压缩图片的网站
慢慢的你就会使用一些简单的框架实现像后台管理这样的简单项目

4. 深不可测

image.png

接下来你会发现有很多的东西还不是很够用,随着需求的增加你的代码变得越来越乱,因为深不可测的原因是你的产品和需求在不停的迭代,所以你会发现很多东西都比较的混乱无章

image.png

深不可测还有一个原因是,你原来在页面里面写单个的 html 会写无数的 ajax ,比如说:你可能写六个或七个为了业务的需求,这个时候如果在移动端就会造成 ajax 直接就断掉了,因为它并发的 ajax 是有限制的,在你请求这个 ajax 的时候,请求就把你干掉了,还有是网络不好的情况下,就死掉了,请求发了十几个也就不行了

image.png

然后就是单个 js ,就比如说: index.js 一直写越来越大 越来越大 这样也是一个问题

image.png

然后就是重复加载,比如说:你的每个页面都会引这个 a.js 就会造成这个问题


image.png

会发现项目中 到处都是 $.ajax function

image.png

domready 是一个非常重要的指标

image.png

如果你还是用的 css 来写,没有引进 sass 或者 less 其他的一些东西,那么你会发现在适应不同设备的时候,自己要写很多的 css

image.png

就是说之前将 a.css 和 c.css 两个页面的 css 合并在了一起,但是后来 a.css 对应的页面不要了,但是 css 还是之前合并在一起的,这样就是一种资源的浪费

image.png image.png

上述的问题都是一些在企业中遇到的一些不可避免的常见性问题。

下图这些就是上面的很多问题的一些解决方法

image.png
  1. BACKBONE.JS

是一个 MVC 的解决方案,把代码分成对应的区块,不把所有的代码放在一个里面了,分成 m(model) v(views) c (controller)

  1. Underscore.js

可以硬生生的帮我们去拼 html ,比如说我们从后台取回来一个 json 对象,然后 for 生成一大堆的 table 追加到页面里,这样有了 Underscore 之后可以提前在页面里写好这个 table ,然后把后台的变量 灌进去他自己就会拼,这样就不用 js 再去做了

  1. Sea.js

可以让我们所有的 js 按照模块化的方式去处理

  1. Less 或者 Sass

会让我们所有的 css 像编程一样,有各种各样的模式去用

  1. pushstate + ajax + hash

pushstate 可以让 url 变,但是页面不切换,pushstate 可以使路由变然后页面不变,再配合 ajax 做一个单页的系统,这样就可以节省掉很多很多

上述的五个方法虽然解决了一些问题,但是还是有解决不了的

image.png

剩下了三个问题

image.png

但是这个时候出现了一个非常严重的问题,你会发现前面的 js 逻辑越来越多,引了很多的库,加载页面的时候会一直 loading 加载你引得一堆的库

image.png

带来的问题就是

image.png

这个时候还要考虑到各种各样的终端设备


image.png
image.png

4. 返璞归真

image.png

smarty(php)
上面的这些方面是直接将后台的变量渲染到页面里了,就像早期的 asp .NET 控件,可以把一些东西直接拖到控件里,我们可以先把一些主要的东西直接通过我们的模板去给他生成,把 js 的东西相当于后移,不让页面对 js 有太大的依赖了,比如:现在我们的项目中有一个 layout - > 相关的配置,但是模板的东西也不能太重,如果把所有的信息都渲染到模板里那等待的时间就长了,需要等待后台的处理,所以后台输出多少 留给前台多少 需要你对业务的一个把量的,比如说:后台只要输出顶部剩下的留给 ajax ,那么这个就要看你真正的怎么去对待这个项目了,然后去拆分这个项目

image.png

这个回到我们前端我们可以不通过后台,直接用 NodeJS 以及上图的其他一些框架来实现

5. 破茧成蝶

image.png

如果是上面的东西你都可以自行去解决了,就说明你的技术已经不错了


image.png
image.png

当你发现自己可以造出来一套前端框架的时候,你可以去看下 FIX 、Yeoman、yogurt 或者其他的组装框架,看下人家的源码,他们是怎么做的,什么测试吖什么的一套项目完整的流程
那么把这些所有的零散的技术结合到你的项目里边完成最终的 test ,这个就是你的终极的目标了,也就是说能做一套对当前的项目自动压缩、打包、合并、处理好路由、处理好组件、处理好性能,那这样就成功了

image.png
  1. 自动化性能检测平台

这样可以收集到前台的用户的信息,你能知道你的项目在每分每秒有什么样的这样的阶段:首页加载多长时间、某一个 js 耗时多久,谁耗时了,为什么耗时了,哪个模块引用了这个 js ,这个时候就需要你有一定的算法知识,把这些东西收集回来

  1. 自动化控制高清图

有些东西要做到自动化的控制高清图,比方说:我们有 1倍 2倍 3倍或者是其他的图,适配(在顶部加一个缩放比率),比如像淘宝的那种高清适配,这些东西都是需要考虑自动化的

  1. 自动化 inlinecss js

还有一些 js css 给它们加一些尾缀,比方说:是把这个加成 inline 还是 outline ,加到内部还是外部这些都是需要自动化去处理的

  1. 自动化功能测试平台

这个可以防止和 QA 撕,还有就是把自己的东西,如果是在 github 上有非常多的 start 或者是 flow 的话一定要对你的项目负责,但是这个不一样,这个是实际的生产项目,你要做很多的 keys ,真正的交给 QA 之前要通过你自己的 自动化功能测试平台 ,如果说你把这个 自动化功能测试平台 做了出来,让公司大大提升了项目的效率和减少了 QA 的测试时间,那么这个也是体现到了架构师真正功能的地方

总结:实际上,后面来的人只要按照指定的区块添东西,剩下的你来统筹全局,这样你在公司的地位、工资自然就高了,从进入到一家公司到把这样的东西产出,你也要去抓时机,而且要找一个好项目,尤其是在大公司就业的时候一定要选一个好项目,如果你的项目很烂,那你这个人也会慢慢地烂下去了

上一篇下一篇

猜你喜欢

热点阅读