小小商城的一次前端架构演变

  博主第一次开发商城类的项目,目前商城已上线,这里就不打广告了。商城的架构主要为yii2+backbone,还有一些其他blablablabla......的插件。

商城有PC端和微信端,先上线的PC端后上线微信端。

  第一版的开发模式是,前端同学设计好界面原型,切好图,做完静态页面交给后端人员。后端人员使用基于MVC模式的yii2框架,将静态页面写成动态的

.php页面。很好,这样的开发方式前端同学甚是轻松,只要做好静态页面就完事,其他全交给后端人员。如果做好的页面,一旦需要修改点小样式,前端同学

就直接在原来的静态页面做修改,然后再提交给后端人员,后端人员就比较修改的地方去修改动态的.php页面,页面嵌套着一堆堆php代码。

  立马发现这种方式不妥,所以开始升级。第二版的开发模式是,后端人员不套页面,直接交给前端同学来实现动态的效果。前端同学设计好界面原型,切

好图,做完静态页面。同时后端人员设计开发完接口,给前端同学调用。前端同学一堆堆的ajax调用方式,一个个在success方法里for循环渲染标签。是的,

这样整个项目下来,几十个页面每个页面都是通过ajax来动态请求数据。用ajax渲染界面的写法尤其难看,小范围的加入了模板。不过这样的开发模式够用了。

  第三版来了,高大上的开发模式是,使用前端框架了,比如backbone,前端的MVC模式框架。前端同学设计好界面原型,切好图,做完静态页面,使用

backbone自带的template一个个套成模板,配好router,采用单页面模式。前端同学的压力越来越大,逼着一个个要修炼升级了。

  整个项目开发过来,每次的前端升级,都把工作一步步转到前端了。第一个版本是一开始大多数会用的做法,前端任务“轻”,技术难度“低”,大部分任务都

在后端,后端人员表示鸭梨山大。第二个版本也是大多数会用的做法,这样前端同学在设计页面的时候,就不会漫天遐想了,会从实际实现的效果和难度来考虑

问题。因为最终设计出来的效果,是要他们自己来实现的。第三个版本就是瞎折腾,不断给前端人员升级,逼迫他们学习MVC模式,使用各种框架插件,不在

只是简简单单做个静态页面,写个ajax而已。

  有的人会问,为什么博主不直接用第三种方式来开发?博主带的电商技术团队,人力资源有限,服务端人员占多数,前端人员大多都是设计人员和页面开发

人员,真正前端大神类的木有。所以为了一边能使商城成功上线一边又能锻炼到团队的前端能力。所以博主就先从简单的大多数人都能接受的方式和流程和开发,

这样通过三个版本的演变,博主的电商技术团队的前端能力已经可以独当一面了。如果直接给他们说第三版的开发模式有多么多么好,有什么什么优势,有什么

什么好处的时候,对初次接触的他们来说会一头雾水,最终开发出来的东西不敢直视,甚至连商城都没办法上线。采用演变的开发模式,一是技能保证商城能够

成功上线,二是一个很好案例使他们自己发现现在这个版本开发模式上有什么不足和缺陷,口头上说再多也没用,不如亲自动手实践实践。自己领会到知识总比

别人告诉你来的理解深。

时间: 2024-10-25 05:25:29

小小商城的一次前端架构演变的相关文章

大型网站架构演变史(含技术栈与价值观)

这篇文章是参考李智慧的<大型网站技术架构:核心原理与案例分析>和现蘑菇街CTO曽宪杰的<大型网站系统与Java中间件实践>写的一篇读书笔记. 前言 何谓大型网站?大型网站的特点是什么?大型网站架构发生演变的源动力是什么?大型网站的架构演变经历了哪些阶段?在演变的某个具体阶段使用到常用技术有哪些,为什么要使用这些技术,同时这些技术又解决了什么问题?笔者在初次接触大型网站时思考了以上几个问题,本着缘木求鱼的方式,我打算详细的扒一扒大型网站的演变史.如果对以上的几个问题都理解透彻了,那么

从单一WAR到多活, 记述一个创业公司的架构演变

从单一WAR到多活, 记述一个创业公司的架构演变 本故事纯属虚构,如有雷同,实属巧合 程 是一个爱折腾,喜欢交朋友的程序员. 某一天,程一个朋友介绍了另外一个朋友 创 给他,创说他有个点子,可以改变世界,现在就差一个程序员.程看了创的PPT,觉得还不错,反正也没妹子,平时下班回家或者周末也没事干,就答应创,做他的合伙人,给他开发网站. 单一垂直架构 程把他自己在大学的时候做的基于Java的考试管理系统,拿来改了改,又自学了一些前端,三个月后,第一个版本的网站上线了.这个东西的后台大概这个样子,所

大型网站应用中MySQL的架构演变史

没有什么东西是一成不变的,包含我们的理想和生活!MySQL作为一个免费的开源的关系型数据库,深受大家喜爱,从最初的无人问津到当下的去IOE,都体现出了MySQL举足轻重的作用.今天我们就从淘宝的发展来阐述MySQL在大型网站下的架构演变史! MySQL的可扩展性 架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展性的架构,这里对可扩展性进行简单介绍一下,常用的扩展手段有以下两种 Scale-up : 纵向扩展,通过替换为更好的机器和资源来实现伸缩,提升服务能力Scale-

大道唯简----存储架构演变之剖析

随着云计算和大数据的发展,传统的基于主机的存储架构已逐渐向网络化.虚拟化.海量云存储发展,从分散走向集中,存储的性能.效率和扩展性.灵活性被企业普遍关注.从更高层次看,存储不仅需要提供数据的管理.数据复制.快照.镜像.迁移等例行性事物,更要能处理数据的灾难恢复.数据一致性.虚拟化融合.弹性计算与资源扩展等工作,这些都依赖于良好的存储架构来满足. 结合企业的IT建设,我们可以把存储架构的演变归纳为三个阶段. 第一个阶段是存储基本架构的演进过程. 在企业建立初期,用户的数据规模并不大,存储需求也相对

Mysql在大型网站的应用架构演变

原创文章,转载请注明: 转载自http://www.cnblogs.com/Creator/本文链接地址: Mysql在大型网站的应用架构演变 写在最前: 本文主要描述在网站的不同的并发访问量级下,Mysql架构的演变 可扩展性 架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展性的架构,这里对可扩展性进行简单介绍一下,常用的扩展手段有以下两种Scale-up :  纵向扩展,通过替换为更好的机器和资源来实现伸缩,提升服务能力Scale-out : 横向扩展,  通过加节

Web集群实现共享存储的架构演变及MogileFS

本篇博客从Web集群中亟需解决的大容量存储问题引入,分析了几类常用的共享存储架构,重点解析了分布式存储系统的原理及配置实现: =================================================================== 1 共享存储的架构演变 2 分布式存储系统 2.1 基础知识 2.2 分类 2.3 CAP理论 2.4 协议 3 MogileFS 3.1 特性 3.2 架构 3.3 组成 3.4 服务安装及启动 3.5 配置部署 3.6 配置前端代理N

从100PV到1亿级PV网站架构演变

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 一个网站就像一个人,存在一个从小到大的过程.养一个网站和养一个人一样,不同时期需要不同的方法,不同的方法下有共同的原则.本文结合我自已14年网站人的经历记录一些架构演变中的体会. 1:积累是必不可少的 架构师不是一天练成的. 1999年,我作了一个个人主页,在学校内的虚拟空间,参加了一次主页大赛,几个DREAMWEAVER的页面,几个TABLE作布局,一个DB连接,几行PHP的代码嵌入在HT

[转]大型网站架构的优化与架构演变(整理)

=============大型网站架构的优化===================== 一个小型的网站,比如个人 网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构.性能的要求都很简 单,随着互联网业务的不断丰富,网站相关的技术经过这些年的发展,已经细分到很细的方方面面,尤其对于大型网站来说,所采用的技术更是涉及面非常广,从硬 件到软件.编程语言.数据库.WebServer.防火墙等各个领域都有了很高的要求,已经不是原来简

大型网站架构演变和知识体系

之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的.ebay的,都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术,于是有了写这篇文章的想法,在这篇文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系,希望能给想从事互联网行业的同学一点初步的概念,文中的不对之处也请各位多给点建议,让本文真正起到抛砖引玉的效果. 架构演变第