1 主要的工作任务
在腾讯实习的期间,截止到现在,主要的工作任务主要有两块
1 投放端性能监控上报系统
2 内部实验系统前端页面改版优化
投放端性能监控上报系统
背景:
广告投放端上面有很多的上报项,主要用于投放端的运行性能监测,在没有做这个项目之前, 内部的人员要是想查看投放端的一些上报数据, 需要在here系统输入的sql语句从hermers中查询 ,同时 ,开发人员想添加一个上报的配置的话, 还得配置xml文件,过程繁琐
主要功能:
1 用户只需要在下拉选择框选中对应的上报项, 就可以查看相关上报项的上报信息,主要以趋势图和表格的形式展示, 表格具有模糊搜索,准确搜索, 点击排序等功能, 方便运营或者开发人员快速定位到某一条上报的信息
2 集中式的配置管理, 拥有配置权限的用户可以进入该页面, 快速新增配置,或者 编辑已经存在的配置,
3 下载报表或者订阅报表
我主要的工作内容:
1 设计数据库表, 编写后端php代码,在原有的here系统的框架下面,开发一个新的monitor模块, 提供整个性能监控上报系统的cgi接口,包括趋势图和表格的数据,上报配置信息数据等
2 使用require.js模块化的方式 组织 监控上报系统的前端代码架构, 使用DataTable的表格组件做table展示, 同时 重写了 datatable的ajax模块, 可以支持自定义的数据接口格式, 不必受限于datatable本身的对数据格式的限制,提高了数据展示的灵活性
3 编写配置管理的前端页面,该页面主要的工作就是对上报配置进行增删查改管理, 以个单页应用的形式, 涉及到很多前后端的数据交互.
4 由于 上报cgi需要每次从 db拉取配置,会影响性能,也可能出现从db拉取数据失败的情况, 所以开发一个缓冲层, 当从数据库读取配置数据失败时,就从缓冲的文件中拉取配置
该项目从数据库设计,到后台的编写, 再到前端的页面设计,交互和业务逻辑,都是一个人完成,很锻炼人的能力, 同时也进一步发现自己不足的地方
内部实验系统前端页面改版优化
这是广告定向组的一个需求,由于试验系统需要将查询的维度从原本的一维拉伸到多维 ,需要对原来实验系统的前端页面做改版
我主要的开发任务有如下:
1 开发多维的分类选择组件
2 由于table的数据较多,往下滚动参考table数据时 需要将table的表头固定显示
3 实验系统后端只提供原始数据, 许多delta和 delta+alpha数据需要前端对数据进行计算处理并table个性化展示,
4 重新规划 实验系统的指标选择模块, 并对后台返回的 多维数据进行解析处理
2 优势和劣势
优势:
技术面广, 从底层的DB,到后台的php或者python以及各种mvc框架,再到前端,客户端,均有涉猎,特别擅长于网络方面的内容
做事情比较积极,会主动的去推进项目的进度,遇到问题马上会解决, 不懂的就会一直去把它弄懂为止.
喜欢钻研技术问题,勇于去探究新的技术,有较强的学习能力和自我改正能力
劣势:
技术面广,但是缺少精通的一面, 需要在工作中不断的累计学习
沟通能力有待提高,在需求评审的时候,需要较强的沟通能力, 才能确保双方都正确的理解对方的意思
工作效率有待提高, 需要合理的使用各种高效的工具
缺乏团队合作编码的经验,需要更多的阅读他人优秀的代码,编码风格有待提高
3 综合评价
在腾讯实习的这段时间, 在技术上面 ,我从一个学生开发者的慢慢的向团队协作靠齐,慢慢的纠正自己的编码规范,熟悉公司内部的各种开发流程, 理解 公司前后端框架每一层的作用和设计的理念和目的
在编写性能监控上报项目的后端代码中, 我发现了一开始看来多此一举的 业务字段和数据库字段映射层是为了提高 数据库字段的的灵活性,特别是针对于上报配置这种多变的且种类复杂的业务
在实验系统页面改版的过程中, 由于缺乏项目经验和对项目本身的理解, 导致前后端接口对接有问题,吸取教训,以后多多注意这些细节问题. 在做实验系统页面的改版过程中, 也学习了广告定向的一些知识概念
总结: 对于公司的工作生活适应良好,还需多努力,多学习
项目中遇到的问题
前端:
1 项目刚开始, 使用了大量的全局变量,(解决方案, 使用require.js 重新组织代码结构)
在说table展示的时候, 自己有做过一套方案,就是普通的tbale外上加分页按钮,使用ajax拉取table数据 , 但是功能仅限于 做数据的展示 ,十分有局限性
后来使用 使用datatable 组件, 这是一个很好用的开源table组件, 文档的完整性,项目的社区活跃性,开源组件现阶段版本迭代的稳定性,还有该组件对开发者开放的api等方面, 都特别符合在本项目长使用,有现成的搜索,本地或者全局排序功能,自带体验不错的分页功能, 可以引入官方的table样式, 提高开发效率.
遇到的问题:
在使用DataTable的过程中,由于dataTable本身的功能的限制,无法与后台配合使用ajax实现分页数据的更新
如果使用DataTable默认的ajax交互功能，对传给后台和从后台获取的数据都有命名格式要求，这样一来耦合度较高，不利于后期扩展
不能直接适用于需要跟多种不同前端或其他业务交互的项目。
解决方案 将DataTable中ajax拉取数据部分抽取出来重写,并做好封装, 也就是说调用该封装从服务器拉取数据, 该封装将会调用datatable提供的api ,将数据写入, 等同于将datatable 的数据拉取与渲染 分离出来,
3 PHP插入中文数据乱码（数据库建表的时候没有设置表的编码格式）
4 在开发投放端性能监控上报系统的时候, 由于老的上报cgi是一直从xml配置中读取上报的数据, 但是在新的上报系统中将配置存储在数据库中,也就是意味着每次上报都要从数据库拉取配置,这样无疑是回影响性能的, 所以这里有一个折中的方法就是将数据中的配置文件化,每次更新的时候把数据更新到票文件上就是了
6 开发实验系统的前端页面优化的过程中
主要遇到的问题有两个:
表头冻结功能,实现上我尝试了两种 方案了,
第一种: 检测页面的滚动事件,当table head被隐藏的时候 ,复制一个table head 使用fixed 固定在页面中, 但是这样的问题有如下几个
一是性能不是很好, 二. 实验系统的表格比较复杂,会随着指标的变换会经常发生变动,在样式上面不一定能够百分百的还原出原本head的样式,偶尔会不可预测的发生位置偏移
后来打算直接从css的入手, 通过监听 滚动事件, 计算 页面y轴滚动的距离与tablehead的位置之差, 实时设置 tablehead的 top参数,
这样做的好处是,tablehead还是那个tablehead, 我们只是通过posittion的属性将其y轴固定住了
7 页面分页问题
由于实验系统的改版之后,用户可以选择多个维度来查询, 所以返回的数据量可能会很大.
这是要考虑分页的问题, 但是有个问题是在分页的同时,不能将一天的数据切割到两个页面中去,也就是说我们不能再在用简单的 sql limit分页的方法了, 所以我这这里提出一个动态分页的方案目前还没有 运用在实验系统的 (这个还是不要讲了)
8 关于di出错问题: 在一次开发的过程中, 由于修改了数据表的字段, 后端的很多代码也做了很多改动, 后来调试一直报错, 我以为是我的代码出了问题就是一直在检查自己的代码, 但是后面一直找不到问题出在哪里, 后来我的把关注的点转移到数据库那边, 后来的确认数据库也没有问题
最后通过查看php框架的底层socket 会话层 的代码,发现php连接di出错才就报这个错误
本来就是一个简单的连接错误, 也花费了很多的时间去排查, 所以在使用框架之前对框架有个整体的认识, 这样子出了问题就可以快速定位到错误点