前端架构

前端重构之路01

折月煮酒 提交于 2020-03-03 20:02:17
在 CodeInsight 开发告一段落之后,CTO 大人找到我说要想一个把 Coding.net 的前端拆分重构的方案,于是我从一个欢脱的开发状态开始切换到要面对一句魔咒的考验。 动态语言一时爽,代码重构火葬场。 不管怎么样,先从梳理现状开始。 Coding 前端使用 Angular 构建,前端工程化还是使用合并文件打包的方式,并没有引入 CommonJS 之类的模块化开发方式,作为一个 SPA 网站,随着网站规模的增大,前端代码开始越来越臃肿,开发体验也直线下降,这是我们考虑重构的原因。 所以首先我们要想清楚重构要解决的问题 代码打包拆分,避免所有功能模块打包到单一的文件 引入 CommonJS 做到更清晰的模块化 边开车边换轮子 要做到最后一点尤其困难,但这也是我们能否顺利重构的关键,重构不是重写,所以如何在现有代码基础上重构,并且还要和当前的开发进度无缝衔接起来就是我们所要面临的一个挑战。 好消息是我们使用了 Angular 保证了我们的代码分 Module 有了一层封装,不至于太过散乱。作为一个 SPA 网站,前端路由已经很好的分离出了各个功能模块。我们用到了 Grunt,虽然有点过时,task 写得有点复杂,但是提供了一个工程化的切入口。 经过小伙伴们几轮讨论之后,最终确定了一套比较靠谱的方案: 按照功能模块重新整理/拆分代码 保持作为一个 SPA 网站

最新出炉的java学习路线

◇◆丶佛笑我妖孽 提交于 2020-03-03 14:57:33
在写这个文章之前,我花了点时间,自己臆想了一个电商系统,基本上算是麻雀虽小五脏俱全,我今天就用它开刀,一步步剖析,我会讲一下我们可能会接触的技术栈可能不全,但是够用,最后给个学习路线。 Tip:请多欣赏一会,每个点看一下,看看什么地方是你接触过的,什么技术栈是你不太熟悉的,我觉得还算是比较全的,有什么建议也可以留言给我。 不知道大家都看了一下没,现在我们就要庖丁解牛了,我从上到下依次分析。 前端 你可能会会好奇,你不是讲后端学习路线嘛,为啥还有前端的部分,我只能告诉你, 傻瓜 ,肤浅。 我们可 不能闭门造车 ,谁告诉你后端就不学点前端了? 前端现在很多也了解后端的技术栈的,你想我们去一个网站,最先接触的,最先看到的是啥? 没错就是前端,在大学你要是找不到专门的前端同学,去做系统肯定也要自己顶一下前端的,那我觉得最基本的技术栈得熟悉和了解吧,丙丙现在也是偶尔会开发一下我们的管理系统主要是 VUE 和 React 。 在这里我列举了我目前觉得比较简单和我们后端可以了解的技术栈,都是比较基础的。 作为一名后端了解部分前端知识还是很有必要的,在以后开发的时候,公司有前端那能帮助你前后端联调更顺畅,如果没前端你自己也能顶一下简单的页面。 HTML、 CSS 、 JS 、 Ajax 我觉得是必须掌握的点,看着简单其实深究或者去操作的话还是有很多东西的,其他作为扩展有兴趣可以了解,反正入门简单

杭州!杭州!问啊W-Time技术分享沙龙,与互联网巨头技术高管零距离!

≯℡__Kan透↙ 提交于 2020-03-02 18:44:40
  问啊W-Time技术分享沙龙-杭州站将于5月15日举行,三位技术大咖相约W-Time杭州站现场与你分享技术那点事儿!活动预留足够的时间可以与技术高管们交流,也许下一个进入互联网巨头公司工作的就是你!活动全程免费!   地点:杭州市西湖区西溪路525号浙大科技园会议中心   时间:2016年5月15日13:00-17:00   官方报名:    http://www.huodongxing.com/event/7332723640500   嘉宾及议题:    赵锦江(勾股),淘宝无线前端架构组负责人   淘宝前端工程师、Weex 项目组成员。    《Weex Live Demo Show》   通过Live Demo的形式演示介绍团队最新研发的移动技术方案Weex特点、用途及团队在研发过程中的一些思考。    施强,LOFTER技术团队负责人   负责LOFTER、网易印象派业的技术管理工作。从事过网易博客的服器、前端以及LOFTER客户端的开发。    《LOFTER的技术架构介绍及团队管理的思考》   LOFTER的技术架构介绍,以及从一线开发慢慢成长的一些个人思考,希望对各位有所帮助。    施德来,有赞前端团队负责人   在淘宝做过后端,在网易写过前端。目前热衷于前端的工程化和性能优化。    《如何打造一个傲娇的前端团队》  

微服务架构介绍

 ̄綄美尐妖づ 提交于 2020-03-02 08:50:50
摘自: https://www.cnblogs.com/mrhelloworld/p/12388859.html 技术架构演变         随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进。       单一应用架构 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。 此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 缺点:随着应用功能的增多,代码量越来越大,越来越难维护,那怎么解决代码一体化的问题? 垂直应用架构 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。 此时,用于加速前端页面开发的 Web框架(MVC) 是关键。 缺点:垂直架构中相同逻辑代码需要不断的复制,不能复用。每个垂直模块都相当于一个独立的系统。 分布式服务架构 当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。 此时,用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 缺点:服务越来越多,需要管理每个服务的地址,调用关系错综复杂,难以理清依赖关系,服务状态难以管理,无法根据服务情况动态管理。 流动计算架构

前端优化点总结

安稳与你 提交于 2020-03-02 01:34:29
PC 浏览器前端优化策略 PC 端优化的策略很多,如 YSlow(YSlow 是 Yahoo 发布的一款 Firefox 插件,现 Chrome 也可安装,可以对网站的页面性能进行分析,提出对该页面性能优化的建议)原则,或者 Chrome 自带的 Audits 等,总结起来主要包括网络加载类、页面渲染类、CSS 优化类、JavaScript 执行类、缓存类、图片类、架构协议类等几类,下面逐一介绍。 网络加载类 1.减少 HTTP 资源请求次数 在前端页面中,通常建议尽可能合并静态资源图片、JavaScript 或 CSS 代码,减少页面请求数和资源请求消耗,这样可以缩短页面首次访问的用户等待时间。通过构建工具合并雪碧图、CSS、JavaScript 文件等都是为了减少 HTTP 资源请求次数。另外也要尽量避免重复的资源,防止增加多余请求。 2.减小 HTTP 请求大小 除了减少 HTTP 资源请求次数,也要尽量减小每个 HTTP 请求的大小。如减少没必要的图片、JavaScript、CSS 及 HTML 代码,对文件进行压缩优化,或者使用 gzip 压缩传输内容等都可以用来减小文件大小,缩短网络传输等待时延。前面我们使用构建工具来压缩静态图片资源以及移除代码中的注释并压缩,目的都是为了减小 HTTP 请求的大小。 3.将 CSS 或 JavaScript 放到外部文件中,避免使用

何崚谈阿里巴巴前端性能优化最佳实践

末鹿安然 提交于 2020-02-29 15:14:57
大家好,我现在在阿里巴巴园区采访阿里巴巴中文站架构师,兼B2B网站优化领域的负责人何崚。何崚你好,请简单介绍一下你自己。 我叫何崚,2006年加入阿里巴巴。之前一直在中科院下属的两个基因方面的研究所,从事一些基因方面的研究。加入阿里巴巴对我来说是一次转行。我在加入阿里巴巴以后,主要是负责中文站的一些架构设计。 我们知道何崚是阿里巴巴B2B网站优化领域的负责人。首先关于页面前端优化这部分,请谈一谈你的主要经验以及针对一些难点问题的解决方案。 目前我们网站页面前端优化主要有两个方向。第一个方向是对网站核心页面基于Wise load的原则做定点性能优化,这方面无外乎就是减少HTTP请求,减少DNS请求时间,减少页面DOM的数量,做一些图片压缩等,大家的思路基本是一样的。值得一提的是,针对特定方向前端优化,阿里巴巴社区开发了一些自动化性能调优工具,例如刚才提到的减少HTTP请求的问题我们开发了一个自动合并CSS和JS静态文件的框架,对于刚才提到的减少页面DOM数这方面我们也有一个前端延迟加载框架,主要负责在页面加载时只加载首屏,用户滚动页面时才去加载二屏或三屏,这样对于网站的性能包括流量都是很大的提升和节约。 我们知道Web I/O也是一个优化很重要的方面,有没有需要特别注意的或是有哪些好的解决方案? Web I/O在我们网站高并发的应用场景下会有明显的瓶颈。为了提高网站高并发处理能力

前端总结挺全面的

…衆ロ難τιáo~ 提交于 2020-02-28 12:14:59
前端UI框架组件库: 说到前端框架我第一印象中想起React、Vue和Angular,不知道你是否与我一样想到这些,现在常用的有:Bootstrap、jQuery UI、BootMetro、AUI常用的还有很多、就不一一跟大家举例出来了,因为很多朋友认为在不同项目开发中用到的前端框架不一样,其实也有一款可以适用于多种项目开发的前端框架,只是没发现。 用前端框架开发项目的原因? 这个应该是最好解决的问题,首先就是减少造轮子的想法,能够快速的开发一款web应用对于公司来说都是非常愿意开到的,在时间和成本之间就能够节约很多的时间,这是其中一点,另外一点就是使用前端框架的组件功能,只要组件功能强大,什么样的项目都能够开发(前提是:要熟悉前端框架的功能!),时间成本问题就能够轻松解决。 没有设计师也能做出精美页面效果的前端框架 虽然市场中有很多的前端框架,但部分UI框架是属于组件库,然而QUICK UI跟当下流行的三大底层框架React、Vue和Angular不同,QUICK UI提供了一整套前端解决方案,包括前后端分离的开发框架、100多种功能强大的UI控件、几十套精美的皮肤模板和近16万字的开发文档,满足你所以开发项目都不是问题。 前端框架库: 1.Node.Js 地址: http://www.runoob.com/nodejs/nodejs-tutorial.html (中文网) 描述

微前端在美团外卖的实践

橙三吉。 提交于 2020-02-27 23:10:02
背景 微前端是一种利用微件拆分来达到工程拆分治理的方案,可以解决工程膨胀、开发维护困难等问题。随着前端业务场景越来越复杂,微前端这个概念最近被提起得越来越多,业界也有很多团队开始探索实践并在业务中进行了落地。可以看到,很多团队也遇到了各种各样的问题,但各自也都有着不同的处理方案。诚然,任何技术的实现都要依托业务场景才会变得有意义,所以在阐述美团外卖广告团队的微前端实践之前,我们先来简单介绍一下外卖商家广告端的业务形态。目前,我们开发和维护的系统主要包括三端: PC系统:单门店投放系统PC端 H5系统:单门店投放系统H5端 KA系统:多门店投放系统PC端 如上图所示,原始解决方案的三端由各自独立开发和维护,各自包含所有的业务线,而我们的业务开发情况是: PC端和H5端相同业务线的 基本业务逻辑一致 ,UI差异大。 PC端和KA端相同业务线的 部分业务逻辑一致 ,UI差异小。 在这种特殊的业务场景下,就会出现一个有关开发效率的抉择问题。即我们希望能复用的部分只开发一次,而不是三次。那么接下来,就有两个问题摆在我们面前: 如何进行 物理层面的复用 (不同端的代码在不同地址的Git仓库)。 如何进行 逻辑层面的复用 (不同端的相同逻辑如何使用一份代码进行抽象)。 我们这里重点看一下物理层面的复用,即:如何在物理空间上使得各自独立的三端系统(不同仓库)引入我们的复用层?我们尝试了NPM包

Web前端作为移动互联网时代的前沿技术,就业前景怎么样 ?

被刻印的时光 ゝ 提交于 2020-02-27 06:52:49
信息技术的迅速发展,使IT技术者们赶上了一个百年难遇的好机会,尤其是国家出台了“互联网+”的政策后,更是催生了IT行业的就业空间,使其呈现爆发性增长。如今,微信逐渐成为了大家主要的交流工具,随着各种小程序游戏风靡朋友圈之后,其从业人员Web前端开发工程师的薪资可谓是一路高涨。细心观察下大家不难发现,就目前来看,Web前端作为移动互联网时代的前沿技术,不仅在电脑端,而且在手机端也得到了广泛的应用。 早期互联网时代,电脑端的网站页面主要以静态为主,相对来说也没那么复杂。而现在随着网络信息逐渐丰富,网页发生了很大的变化,企业更加注重用户交互,各种产品层出不穷,好产品想要长久发展,用户体验就变得尤为重要,特别是移动端产品。 学完Web前端开发后,可以从事网站前端工程师、网页制作工程师、前端制作工程师、网站重构工程师、前端开发工程师等工作,这些方向算是一个网站前端最基本的选择了。也可以从事资深网站架构师,对于一个大局观好、悟性好、知识面广的前端工程师来说,走网站架构师是一个非常好的路线。当然,你也可以自己创业,或转岗管理和其他岗位。 大家熟知的Facebook就是Web前端技术的产物,完全基于前端框架打造出来的平台。另外,外卖平台饿了么旗下的部分产品也是基于Web前端技术的。像淘宝,百度,阿里等等,都已经将Web前端技术打入到了自己的产品中。 很多人在没有接触过Web前端之前

为什么要学习Vue——前端框架角度

元气小坏坏 提交于 2020-02-26 16:45:39
什么是框架 框架(Framework)是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一种定义认为,框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。 可以说,一个框架是一个可复用的设计构件,它规定了应用的体系结构,阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程,表现为一组抽象类以及其实例之间协作的方法,它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。 构件领域框架方法在很大程度上借鉴了硬件技术发展的成就,它是构件技术、软件体系结构研究和应用软件开发三者发展结合的产物。在很多情况下,框架通常以构件库的形式出现,但构件库只是框架的一个重要部分。框架的关键还在于框架内对象间的交互模式和控制流模式。 框架比构件可定制性强。在某种程度上,将构件和框架看成两个不同但彼此协作的技术或许更好。框架为构件提供重用的环境,为构件处理错误、交换数据及激活操作提供了标准的方法。 应用框架的概念也很简单。它并不是包含构件应用程序的小片程序,而是实现了某应用领域通用完备功能(除去特殊应用的部分)的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类(该子类属于框架的默认行为)或组装对象来支持应用专用的行为。