架构师速成6.12-开发框架-前端封装

做一个网站不只有写后端代码,为了更好的用户体验以及更优雅的代码实现,我们也需要对前端进行封装。但是在谈封装之前还是要先提一下统一的规范,前端统一的规范尤为重要,这是给用户一致性体验最核心的关键点。我举一个反面的例子,大家可能一下就明白前端规范的重要性了。之前做过一个网站,流程如下:

  1. 设计给图片
  2. 前端照图片进行静态页面生成
  3. 后端再加入代码,最终成为一个网站

这个流程没有什么问题,但是设计没有统一的规范,他给出的每一页文字大小,表单,分页几乎都不太一样,都有些许的区别。前端做页面的同学,也严格要求自己,每一页都做的很符合原图。后端同学发现不能重用,那也只好每页单独做分页,做表单,做js校验,严重的是光用户头像就7个size,我们到最后都要哭了。最后做出的网站给人感觉不太像一个网站,因为每页有些相似,但是又有细微不同。而且css,js超多,几乎每页都对应一个单独的css和js。维护起来很费劲,比如加一些字段,还得设计再修改原图,前端再照着切,否则有些地方就不美观。设计,前端,后端每个人都疲于奔命,结果还是工期大大延后。

所有前端规范非常重要:

  1. 除首页外,统一定义列表页,详情页,表单维护页的模板,全站使用一套。
  2. 模板要抽取公用部分,统一头,统一尾,统一头像(大,中,小),统一翻页
  3. 字体大小统一(大,中,小),网站所有的输入框,标题,错误提示都规范等等
  4. 统一颜色,不能超过3个配色
  5. 页面其他元素也要统一,例如 提示,弹框等等
  6. 业务相关的元素也要统一设计,举个例子:比如当当的图书,淘宝的商品
  7. 其他需要统一的部分

后来统一之后,设计只需要设计好那几个关键模板就可以了,有了新的业务元素设计一下,非常轻松。前端统一样式之后,css就只有一个也是无比轻松,而且也不需要切页面了。后端同学也轻松了,拷贝一个模板,改改里面信息项就ok了。这个要向bootstrap学习。

另外前端需要的文件也很多,css,js,html,img等等,文件夹规范也是很重要的。必要时请考虑动静分离,使用nginx加载静态资源,你会觉得爽多了。

说完规范,再说一下其他的关键点:

  1. 前端模块化开发 例如:SeaJS,RequireJS,如果要进行前端规模化开发,必须要考虑。如果只有一个前端,也尽量使用模块化开发方式。好处自己google。
  2. 采用统一的底层类库,JQuery目前是使用率最高的了。不要张三说我用A,李四说我用B,结果互不妥协。必须只能选一个,就像后端你不能选了spring,又选nutz。
  3. UI类库封装,弹框,消息,tooltip,翻页,form校验,tab页,日期,图表等等与界面相关的
  4. 功能类库封装:ajax,异常处理,前端计算,模板加载等等
  5. 无js化,参见angularjs jui(国内前端框架),毕竟写js对初学者还是有些难,如果不需要写js,而只是加上一些属性,就可以实现js效果,初学者还是很喜欢的。

网站开发一前一后是必备的,必须进行完美的封装,让初学者也能很快上手。

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-11-07 19:59:34

架构师速成6.12-开发框架-前端封装的相关文章

架构师速成6.4-开发框架

经历了非常多公司,看过好多代码. 传统行业公司普遍都有自己一套统一的开发框架,封装的非常傻瓜化.门槛极低,便于不同的项目高速开发上线.比方有一个银行业框架封装到开发者仅仅须要在界面上拖拽就完毕大部分工作,然后在拖拽好的模块里面加入一些业务代码就ok了.用友.华为也是类似.当然传统行业缺点是.一套框架用n年,老掉牙了也在用.有时候跟不上时代. 小的互联网公司有时候就不太注重,基本就以高速上线为主.草草完毕功能就能够了.阿里巴巴在开发框架封装方面做的也不是非常好.跟发展历史有关.也跟商业驱动有关,这

架构师速成-架构体系

经过这段时间的反思和整理,终于对架构有了一个较为明确的理解.架构是产品从无到有以及慢慢壮大过程中所需要的全部技术体系总称,架构过程: 配置.编码.测试.运维.监控分析.安全.运营等一系列技术体系的选型.取舍 技术选型基础上进行规划.设计.实现.迭代.制定相关规范 相关技术及规范运用到产品开发的整个过程中,并在产品迭代过程中对架构进行迭代优化 架构不止包含技术的框架,比如有人用了spring就觉得我已经是架构师了,其实架构并不是这么简单.我们以做一个新浪微博类似产品为例,现实应该是这样的: 产品初

架构师速成5-小学

很高兴你很快的进入了小学,小学的东西会让你更加的耀眼. 阶段: 小学 学时:2-3个月 升学标准 能自己制定目标及计划,get thing done. 可以轻松制作一个让你身旁人惊叹的ppt 能做一个简单的网站(或者客户端软件),数据能保存到数据库. 实践经验干货来了. 先说ppt吧,这个上一期已经讲了,如果你ppt做到出神入化,基本不需要做架构这么苦逼的事情了.因为你很容易成为老板的心腹,军师,走上人生正道.作为一个苦逼的小学程序员,很羡慕吧.那就再努力学一下,不用多久,你就会升职加薪,当上总

架构师速成4.4-我该学什么语言

该学什么语言好呢?很多人都很纠结,其实我建议学习java,为什么呢?文档多,上手容易,教程也多. 当然一开始最好学这样的语言,但随着你知识的增长,我的建议是能学多少学多少,但是有几个是必须的,如下: 前端html,js,css sql 至少会一门脚本语言,python,ruby等等 shell 至少会一门后端语言,类似java,scala是个不错的选择 语言学的越多越好,你可以总结各个的优缺点,另外最后你发现语言都是想通的,学一门新语言很容易. 当然上面的语言是为了你做架构师准备的,如果你说我想

架构师速成6.6-知识的收集整理学习

知识如何学习前面已经讲了2节,这节主要讲知识的整理和沉淀. 其实我之前也一直没有好好的思考过这个问题,今天在整理自己的wiz知识库的时候突发灵感,所以有了这一节. 其实知识获取的过程分为搜索->收集->整理->精化->应用->分享,前一部分跟时间管理的收集也很相近吧.知识获取的思路适用于有目的的知识收集和日常的备忘性的知识收集.当然你随机收集一些资料记录下来其实效果并不是很理想,重要的是你要有目的的学习才能最大的发挥你的心智以及潜意识.当你主动要学习一项知识时,你的潜意识会主

架构师速成8.2-架构师要懂产品

产品和架构两个截然不同的职业,好像风马牛不相及,其实不是这样的.产品的思想需要经过技术的手来成为现实,在成为现实之前,需要技术理解.评估.碰撞.优化.把控.验证等等.当然架构师就承担了这一系列技术的责任,而且在一个产品的实现过程中,技术架构并不是很重要的,前期可以没有架构,简单快速验证,只有在用户多了之后,架构才有真正的用处.在初创公司,很多架构师都等不到用户多了的那一天,来实现自己的架构梦.所以产品这一关架构一定要把好,只有你把好了,后面才有机会让你去架构. 当然架构师的懂产品,是懂产品的生命

架构师速成7.3-devops为什么很重要

evops是一个很高大上的名字,其实说的简单点就是开发和运维本身就是一个团队的,要干就一起把事情干好.谁出了问题,网站都不行.作为一个架构师,必须要devops,而且要知道如何推行devops. 首先要自动化,举个阿里的例子,阿里通过aone系统来实现半自动化部署: 开发人员开发代码先自测通过后,提交代码到git. 在aone中一键部署到日常环境.部署是自动化扫描依赖冲突,系统安全等问题. 测试接到部署成功的通知,进行测试,如果测试通过,则审批通过,可以线上发布. 线上运维人员一键部署到线上,部

架构师速成8.3-架构师必须要了解的规则(转)

作为一个架构师,有些规则是必须要掌握的,这就想软件的公理,如果你学物理不知道牛顿定律,那就不要学了.在软件行业也有类似的东西,我称之为软件定律.例如: ACID,CAP,BASE ACID 传统数据库系统中,事务具有ACID 4个属性 (1)原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行. (2)一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态.这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性:事务

架构师速成4.2-幼儿园要学会如何高效学习

<如何高效学习>,这本书的作者是scotthyoung,最知名是的1年内自学完成4年麻省理工学院计算机科学的33门课程,同时也写了一个学习方法的Blog,他使用费曼技巧来加强理解和学习. 费曼技巧有很多种理解,最简单的是: 拿张白纸; 在白纸顶部写上你想理解的某想法或某过程: 用你自己的话解释它,就像你在教给别人这个想法. 最要紧的是,对一个想法分而化之,虽然可能重复解释某些已经弄懂的知识点.但你最终会到达一个临界点,无法再解释清楚.那里正是你需要填补的知识缺口.为了填补这个缺口,你可以查课本

架构师速成7.4-架构师为什么要带团队

有人说架构师明明只需要做架构,干嘛要扯出来带团队,带团队不是项目经理或者CTO之类的管理人员干的事情吗? 其实这个是一个误区,架构师其实是一个全栈的特殊人物,应该项目开发的所有的环节和角色都有深入了解,尤其是带过团队对你的帮助会更大.那种只做架构,而且仅会做架构的架构师,是大公司畸形的产物,在我看来,不太接地气.大公司人员体系庞大,分工明确而且细致,技术只是负责技术就好了,管理自然有专门的管理人员来做.我简单列举一下架构师带团队的优势: 架构设计时会从整个项目的角度考虑 开发人员使用更方便 测试