发布网友 发布时间:2022-05-09 10:30
共2个回答
热心网友 时间:2024-01-30 00:29
作为空间前端老司机,看到大家讨论那么激烈。也想分享一下自己的经验,作为空间06年到11年的前端开发,或许可以给大家分享一些当时的技术选型让大家看到空间的技术演进(至于现在为什么变成这样,我不去做评价对错)。
1. 06年,还是一个前端技术萌芽的年代,虽然04年google把ajax概念让更多人看到了前端的重要性,但是前端技术还是非常没有标准化的年头。刚接手空间的前端代码,前辈们为了极致的体验,十几号开发(前端,后台,甚至运营开发都有)都在同时改一个文件G4.js,文件数量可达200k(自己脑补有多少行)。当时没有像现在那么多框架,那么多解决方案,更加没有node.js,你从何下手? 如果你们都觉得文件请求合并为基本原则,那么这个做法是不是就是对的?
2. 对于那么大的文件,代码本身的问题就非常多。所以接下来的事情,我想的方式是拆开,模块化。做这个事情,后来就到了07年,为了让模块化开发方式简单,自己写了压缩合并工具,自己定义模块加载的方式。然而当时能想到最简单的优化就是,把首页用户不需要的内容尽量异步加载。如果回想起来,当时最遗憾的是,并没有把模块化的工作方式,抽象成设计模式。后来做DO分离的时候,我们把前端的工具也慢慢推动形成了公司级的工具,包括发布和压缩,其实也是最早期的前端工程化雏形。当然工程化还包括了最早的公司web端性能的测速平台
3. 抓包中你们还能看到qzfl,这个是最早期为了解决开发规范,解决浏览器兼容的产物。这个框架为空间做了非常多的深度定制,同时也从整个团队来说,让前端开发在生产环节获得效率的提升(当然始终没有提升效率到,我们有时间去做开源,这个深表遗憾)。当然到现在同时看到多个基础库,其实是让我觉得非常痛心的一点,在现在提倡去框架的时代,在空间依旧看到了很多基础库。这个确实需要后辈们想办法,qzfl已经发挥了它最大的价值,是否还能带来更大的价值?
4. 前端优化,这个很古老又很赞新的问题。怎么做都没有对错,虽然前端优化也能有一些常规的设计模式去驱动,但是设计模式不见得都是全对的。空间的优化原则是基于数据分析的基础去做的,所以我们会去关注真实用户端的使用情况。空间多首屏加载做了非常多调整,以及对10%的用户,在网络接入,运营商,使用习惯上做更多的分析。所以我们并不会说直接套用xxx优化原则就认为我们做了优化,优化随着时间推移,随着用户硬件的升级,也在不断调整着策略。
当然以上这些优化其实只解决了用户访问的速度问题,并没有解决卡顿的问题。所以我在12年的velocity china上提出了前端的渲染性能优化的分析方法(有兴趣可以百度搜索16毫秒的优化),希望前端开发通过渲染问题的分析,去优化空间的卡顿。因为空间长期都在和网络较量,对于复杂前端性能,确实看得不够多,特别是运行时的性能。
空间的前端技术,也许在现在很多人看起来技术很古老。但是它已经是一个大象级别的项目。另外在业务面前,一个理性的程序员会考虑,我的重构是否对现在的优化还有价值? 空间当年从10万到百万,到千万访问量的提升的时间段内,各种优化都是值得的。然而到了现在顶峰阶段,去做天翻地覆的改动价值是否得以放大?
所以,也建议大家不要以新技术的运用作为判断前端技术是否NB的唯一标准。回想04年ajax诞生,算是新技术?其实只是一个新的设计模式。最后空间前端团队,虽然在开源上没有太多的贡献,但是在腾讯内,给大家创造了非常大的成长空间,创建了腾讯的web前端通道,让前端技术真正在公司内受到重视,做到这点已经足够。心存感激。
热心网友 时间:2024-01-30 00:30
线上代码如何并不直接反应团队技术水准,这个在大公司干过的应该都懂,不信你们去看看新浪博客的前端js,那代码是04年的时候做的架构,就不说有多nb了,放到现在一些公司也是做不到的,但是博客现在基本已经毁了,这并不是技术能控制的,产品不ok,技术没办法发力,很多事情没有契机去做,比如优化,大改版,技术升级等。因为产品过于复杂,很多新人不敢动老代码,历史问题等,铁打的营盘流水的前端,谁care呢。
所以看了很多qq空间的技术说了一些问题,我体会也很深,有时候有些项目,真的身不由己,技术选型一开始很重要,但是10年前的产品的选型必然和今天主流不一致,但这并不能说明技术团队技术不行.
缓存利用根据流量峰值做不同策略的尝试,我在10年就知道腾讯在做,这个也是qq空间团队主导的,10年啊,不吹不黑,当时淘宝和现在的淘宝应该都没有做起来。