后台开发统一化
目前开发项目的管理后台在5个以上,在开发过程中总结出相当一些规律。建议后台对于ui的风格进行一次统一。包括整体的布局,常规操作样式,常规表格样式。
inin同学的原型在功能样式上都很棒,但是几个后台系统的样式风格有较大差距。每次重做样式上需要占有一定时间,同时个人觉得后台之间没有统一风格,也无法展现产品同为技术中心产品的特点。
为了节约开发和原型的构建时间,建议对整个技术中心的后台进行重新规划,然后构建一个统一的模型。这样每次开发的时候只需要从中抽离所需要的组件即可。而inin在原型开发的时候也可以重复利用这些已有组件,化简整个原型构建过程。同时每个新后台的开发都将为整个统一模型积累新的组件和开发过程。因为有统一的模型,所以这些新组件应该是可以顺利的即插即用,而不需要在项目与项目间切换的时候依然需要去做样式上或者数据上的适配。
在以上开发的基础上,统一整个开发过程也可以使得后端同学有一个稳定的开发环境,对于简单的业务修改则变成可以独立完成,使得整个开发效率有较多的提升。对于现有情况,后台的整个前端开发都偏向于工程化,虽然整体环境依然不算重,但是配置环境的过程相对耗时较高。在同一模型的基础上,可以维护一个相对稳定的工程环境(包括其实可以有简单的基于svn的简单的源代码管理环境),将摆脱整个前端开发过程对于前端的依赖。
整个开发过程建议是如此,由前端和产品同学,对现有的后台进行一次大致的过滤,确定其中最常用的一些场景,组件,功能。将其归类合并。再由产品同学对整体UI和后台结构进行统一,产出一个统一模型所需要的内容(整个开发过程可以跟随某一个项目的后台开发过程,然后在整体开发过程中逐步完善所需的额外内容)。后续的维护则是由以上的内容拼装开发,并将其简单的推广给后端同学。最终目标是形成一个规范的前端开发环境。
vue有对应的一些UI库可以使用,可以用来参考,也可以自己制作,在后端开发过程中,我们自己也积累的了一些成熟可用的组件和UI规范。
页面构造和服务端渲染
现有的后端页面,为了节约工作量,都是由前端开发同学做好外部页面,之后加载响应的内容。主要是dgcp和小鱼互动系列的内容。这个部分目前设计的模式结构是,后台对页面内容进行富文本编辑,然后外部页面读取相应数据后,在页面进行拼装和装载。
目前项目按照此流程工作的优势:
编辑对于页面有较高的自定义能力。开发可以将更多的精力投入在非重复性的功能开发和优化上。有比较高效开发效率,项目复用率较高,对于编辑来首也有相对较高的自由度和自由编辑能力。
目前项目按照此流程工作的劣势:
外部页面加载资源较大,页面加载速度依赖后台返回。页面本身逻辑趋向于扁平化,在完成页面与页面之间的交互通信,或者外部的单页面应用,js和css部分会变得越来越臃肿。而且因为需要管理所有模块,所以用户加载资源的时候有可能会加载很多额外的无用资源。影响js的加载和计算速度。
可以开始尝试引入nodejs(python也能实现相同效果)管理目前这一块的内容,并将相应的经验也引入nodejs构建saas小程序。最终实现的效果是由服务器将页面所需要的模块进行拼装构成完成的js和vue,再由前端加载js后载入对应的接口内容。这个主要目标是,管理外部页面的模块化,并提升用户的加载和首屏体验。同时在这个过程中,争取提升外部页面的功能深度,使得外部页面在可配置自由度更高的同时变得轻量。而最终目标是实现外部页面整体的功能的深化效果。
新的数据通信
在现有的ajax模式下,还是应该尝试更多新的前后端交互模式。新模式可以带来更多响应的功能玩法
甚至在离开后台的情况下,可以在前端完成p2p试的交互 解放后端并行压力
websocket个人一直认为是一个优于轮询的即时通信技术。并会在某些场景下替代原有的ajax这个单向通信技术。可以由服务端向客户端推送信息,对于产品而言有着更高的主动性。
这个部分已经有实际引用的案例,应该是多人同时游戏互动所必须的技术基础。虽然对于后端服务器有较高的负载,但是非常想尝试在通信是双工的情况下互动能有什么样的新的突破。比如两人的互动对战游戏,或者多人的团队游戏,以及队列管理的多人聊天。
WebRTC是新的媒体技术,在支持视频音频推流这个方向上可以考虑掌握,而且这个是p2p技术,可以减少对于后台的依赖的同时提供点对点的视频音频交互。
引入可以在前端完成计算的部分
canvas元素是在过往项目中我们组前端都很少使用到的内容。相对于前端组和互动传播组而言,这个部分技术较弱。
这个部分未来最可能应用的部分,因为部门在页面游戏上并不会走的太远,所以这个部分的框架可以暂放。但是个人觉得canvas上可以应用到的主要是对于图像和视频的处理。将一部分图像处理的内容放在canvas进行,提升用户自己创造图片的可能性,然后再将图片保存至后台。
这个部分的可行业务包括图片处理,头像剪切合成等等
网友评论