广告前端工程从无规律到模块化、从技术架构到业务逻辑
温馨提示:这篇文章已超过556天没有更新,请注意相关的内容是否还可用!
链接:
近几个月我仍然都在处理公司广告系统后端展示的代码。几个月出来见证着广告前端工程从无到有、从无规律到组件化、从科技架构到业务逻辑,收获颇多,故此记录一下我与广告的点点滴滴。
一、事件原因:
我所在的房产网站有两条大的业务线(业务线甲、业务线乙代替),分别由两个大的队伍管理,基本没有交集。之前两条业务线都是用的广告方案同样(本文用老代码代替)。2015年初,由于这套老代码因为维护成本降低、与页面耦合高、并且稍一改动频频出bug等弊端。广告组和业务线甲一同商议、打算在业务线甲首页改版以后,重构这套后端展示用的代码(本文中称为ad甲.js)并先由首页试用ad甲.js。
二、原来的老代码是哪个样的?为什么要重构它?
广告在页面上展现是分广告类别的,每个种类对应多个广告位(例子)。我们一般是在页面布码(默认隐藏),页面加载后再用js动态加载。那么老代码是如何做的呢?老代码中把向个广告位(id)中加入广告的行为封闭成多了及时执行变量,每个例子单独处理,没有类的概念。如果有相同的广告类别,就ctrlCV;多人维护代码风格迥异;依赖页面中采用的脚本。简单来说,就是以广告位为单位的多个js片段。那么这种的代码怎么使用呢?后台同学根据页面广告位的使用,将这种广告位分别打包成多个js文件,分别引用。对于一些可变的数据。就将js通过标签吐到页面上,并借助PHP变量的方法设置展示用的数据。
虽然,这样的结构对于前端同学来说是很难受的,pv统计要分别copy到每个例子的js片段中、无法统一设置公用的个别、没有可复用的逻辑、大量使用with和eval函数、不仅js依赖页面环境,而且没有逻辑性、复用性、和可读性和统一性。看来老代码的解构是很难导致了。
三、临危受命、时间紧、任务重。
时间只有一个多月。在的指导下,我起初了这段代码的阐释,也就是从这一刻起我与广告结下了不解之缘。
其实重构的不只是是全栈代码。后端的逻辑也要变。原先的后台不仅要给js碎片打包,还要负责吐在页面中的广告数据。这样维护业务线甲的前端就和广告的后端耦合在了一起。新的架构中业务线甲的前端只负责页面相关的逻辑。而广告组的后端只提供一个能访问到对应于页面的Ajax接口。前端也成为一个专门处理广告渲染的js文件。
其实在这样短的时间下重构的代码仍然解决了不少的难题,但依然有众多的不足之处广告任务网php源码,下一篇文章会具体表明。
四、前端代码构建之后的构架
1、单一的js文件
重构之后将原有的多个js片段改为一个js文件,业务线甲的每个页面只要引用同一个js文件就可以了。在加上一些语句。这样js负责按照中的变量推断是什么城市及其哪个页面,并按照这种向后台获取广告数据。广告的渲染与广告数据冗余。使得数据与显示分离。每个页面对js的引用形式更加统一。
2、jsonp异步获取数据
在页面的词语中获得页面的特点参数,异步的获得广告数据。当然这少不了广告组提供的ajax的接口。考虑到业务线甲和广告业务的服务器存在跨域的弊端。我们引入jsonp的方法从广告的后端获取数据。通过1、2这两个方法,广告的后端和业务线甲的前端就解耦了。
3、模块管理
使用和对应的r.js打包,一些通用的软件函数也抽象成工具箱组件。将每个广告的类别分别定义成对应的模块。模块间还有了继承关系,我可以在父类处理一些统一的东西(例如pv统计),也可以在子类加入一些特征化的东西。
4、对页面的js库的依赖。
如果使用了,那么不妨将所需的依赖加入到项目,一同打包。就不应该每个页面都判定一遍了。比如和,相信我会一直用到后面强大的API。但不见得业务线甲上每个宿主页面都有很多东西以及是我想要的版本。
5、复用老代码中的特型逻辑
老代码中而是有众多的特点处理逻辑可以复用,由于时间非常紧,完全的重构也很有风险。我们可以用来复用一个别,并封装成AMD风格的组件。
总结出来我们这一次还仅仅代码结构上的重塑,很多的广告展示上的代码并没有完全更改,一开始强调的难题被一一解决。但是基本的结构有了,剩下的就一步一步来吧。
五、这条路还在继续
就这么广告任务网php源码,在短短一个多月的时间里我们的ad甲.js重构完成了。但是它仍有一些的弊端需要不断地建立。目前也并非在首页加入ad甲.js,后期就要在业务线甲的全站对接未知的宿主页面环境或者各个页面带来的历史性的加码合理性问题,将不断的考验着我和我的广告前端代码。我与广告的故事还没结束。
专栏作者简介()
尘钥:前端广告人,偏前的前端开发。奋斗在浏览器的战场微博:技术博客:
【今日微信公号推荐↓】
本文来自网络,如有侵权请联系网站客服进行删除
还没有评论,来说两句吧...