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

Posted 2020-06-14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

别人告诉你来的理解深。