2014年7月1日 By 情封 分类: 随笔
1)项目文件“接口”唯一化
       前端很多一部分工作都是在写静态页(包括业务js),每次写完都是直接通过qq邮箱或qq把静态页打包发给上下游检查或嵌套代码。但下面的场景大家应该都会经常遇到:
     上游看完静态页后发现一些问题跟他设计的或交互不一致,需要你修改,前端修改完再次把压缩包发给上游,来来回回导致上游那会出现v1,v2多版本的情况。或者如果当时接收完没及时后,后续都不知道还有这事。
      对下游来说我们只有提供该项目的svn地址,他们直接checkout下来就可以了,这样获取的都是最新项目的代码,还可以存在版本记录。
      这种重复易出现的问题,就是在项目配合中的一个痛点。
      现在的解决方案是:
      对外:各位童鞋把写好的静态页都放在ued svn上同步到内网直接提交一分可预览的页面给上游,如果有问题沟通完可以直接刷新查看,减少了文件的传输以及避免错误的误解。
      对内:对前端团队来说,团队内部的任何童鞋都可以开发、修改任何一个静态页,以达到项目交叉配合。一定程度上提高开发效率。
     基于前端这种模式都可以推到ued内部的其他部门,特别是对ui部门的psd管理。
    ps:对每个项目组来说,只关注结果,前端内部的如何协作,是几个人来做还是一个团队来做,对他们来说是不透明的。
2)维护性项目或已上线的项目维护
     这种类型的项目往往是要去修改后端嵌套完的页面,如果本地没开发环境,你就很难做到修改就及时预览的效果。所以一般的做法都会是安装个虚拟机来做本地的开发环境。
     针对这种类型的项目特点,有几个问题:
      a:本地环境比较难搞(主要是模版数据的问题),如果要多人合作一个项目的化,每个人都要在本地配置一个,这样维护的成本太高了,每加入一个新人就要配置一个。
      b:利用虚拟机的话,在项目中试用过半年,有时候突然奔溃了,项目就玩不动了,或者一会儿nginx没启动,一会儿apache没启动或者虚拟机时间不对导致本地页面没数据,等等这种类似的问题,这种情况一次两次之后,心都操碎了。这种也是会有上面那个同样的问题,每一个新人加都进来都要搞一次环境。
经过多方面考虑权衡后,把这种类型的项目部署到内网去,前端就不用去管那个里面的配置,他们只要checkout项目代码到本地然后修改完通过ftp直接上传到内网上,(这部分可以利用ide来自动上传)这样就可以做到及时修改及时更新的效果。这样也就解决了环境的配置问题,数据也解决了,不用开虚拟机了,解脱了前端上多种的困然。
后期有新人加入项目的话,只要提供一个ftp的账号就可以了。如果调试都ok了,把本地的代码直接提交到项目svn上。
但是采用这种的有个弊端是毕竟是用ftp所以不能多个人对同一份文件进行修改保存,不然会导致覆盖的项目。但相比之前造成的困然,我觉得整个弊端可以通过人为的约定下就可以解决。
ps:上面记录的都是在项目配合过程中遇到的痛点,把一些重复的或容易出问题的点给解决了,你在其中所收获的远远不止这些。这可以涉及到是否有心发现问题,以及之后的解决问题的方式。
可能上面所提到的都是很简单,很粗暴的办法,但可以解决现在团队内遇到的问题,也算是一个到现阶段比较好的解决办法。优化问题的解决方案可以持续进行。
2014年2月11日 By 情封 分类: 随笔
    临睡之前,想了一件事情:
    跨部门,跨项目的团队合作,前端团队应该提交出一份怎么样的交付物,以及如何调试线上产品,以及如何方便的后期与开发的联调。
回顾在网龙与4399的工作方式,总结出一些问题:
一般的项目开发流程:
    前端开发人员做页面的流程普通是这样的,有新的项目,按自己的习惯或以往的项目经验copy或新建一份项目目录,然后就开始写前端静态页,包括js交互效果。涉及到ajax与后端交互,全部自己模拟。在本地写完静态页,通过QQ或邮件知会相对应的开发人员,开发人员进行模板嵌套,最后提交到产品测试服务器让QA测试。
    如果非常顺利的话,这将是一次完美的项目开发,但事与愿违,总是会出现这样或那样的问题,比如PM临时新增的需求,浏览器兼容性没测试完整,这样情况在前端上都是非常常见的,而且必然会导致前端模板或静态资源的修改。这一来二去的,如果总靠通过QQ或邮件发送,总是很浪费时间与成本。
非常糟糕的前后端配合方式:
     情景:前端FE接收到一个PM提的BUG或临时需求,需要动到模板,以及css,images等。FE会把线上的相对应的模板代码以及相关的静态资源copy一份到本地,然后进行修改测试(或通过fiddle代理映射),都完成之后,告知开发说哪里修改了,很多时候得陪着开发修改,因为怕忘记告诉开发哪里修改了。这种更浪费时间,而且项目的得不带沉淀,永远没有完整的一份前端代码,不利其他童鞋的配合与交接。
在整个的项目配合过程中,前端开发人员的痛点永远都是产品数据嵌套完后的各种纠结问题。所以基于以上的种种问题,有想到之下的方案:
    前端开发人员写完静态页后,统一提交到一台前端项目服务器(前端组所负责的各个项目),提交一份项目的地址给后端,利用中间可视化页面知道每一次的提交的相关信息,(利用脚本定时自动抓取或手动操作同步),这样就可以把相关的静态资源同步到产品测试环境中,尽量每一次的静态资源的修改都不用麻烦到后端开发。
    针对产品模板嵌套完数据后谁来修改的问题,这个要看具体的项目情况:
    1)后端不做修改,那可以同步一份模板页到前端服务器,前端根据需求修改完,同步至测试预览服务器,后端可与对比合并。
   2)后端自行修改,那前端在本地修改完静态页后,提交到前端项目服务器,后端抓取纯静态模板后与预览服务器上的模板文件对比,自行修改嵌套。
    通过中间这层,对前后端来说其实沟通更方便了。
    对前端而言:
    1)内部项目更容易协调了,多人配合做项目
    2)对外的接口更统一了,跟后端的接口永远都是前端服务器上的文件
    3)可以保证前端项目文件的完整性
    4)前端所提交的交付物一致
    对后端而言:
    1)每一次的修改文件夹少了,避免频繁性的浪费时间的沟通,让更多的时间做有意义的事
    2)执行对比差异化文件,不会遗漏修改点
    前端最后提交给开发的项目文件的标准:
    1)css代码的合并、压缩
    2)图片的优化
    3)图片的缓存问题
2013年11月21日 By 情封 分类: 随笔
     这次终于又迈出省了,除了杭州之外,我又更北上了去魔都上海了。2013年11月15号借参加携程UED大会,去了一趟魔都上海。此行也见到了不少的朋友,很多只在微薄或QQ上聊过的朋友,比如@克军、@小鱼、@小志、@大漠、@神仙等。还坐上了地铁,哈哈最后还是感觉跟动车一样。。。
      那天确实很不幸,飞机由于航空管制,延误了1个半小时,12点多到达虹桥机场酒店。下午@鬼、@神仙走走聊聊等待晚上跟几位大神碰头。期间在中山公园跟神仙有聊一些自己比较困惑的或觉得在北上广的一些想法。比如在北上广会有很多的分享会,而且分享的主题都是比较前瞻性的,但能真正落地的有多少。毕竟除了BAT之外,中国还是会有很多中小型企业,这些公司真正要解决的实际为主。犹如阿里的目标就是为中小企业服务,哈哈~~
     晚上跟几位大神的碰面,顿感拘谨了,我只能扯扯淡。@小志分享的整体上班氛围确实很弹性,只要每周上够时间即可,这确实很让人羡慕。通过晚上的聊天,此次上海也可以啦~~
     重点戏来了,去虹桥国际科技中心参加会议。。哈哈领了嘉宾带,跟CSS女神@点头猪 聊聊,哈哈很害羞啊。上午的会议时间拖延了很久,早上的分享有四场,凭着零星的记忆总结下:
     第一场是携程技术副总裁的广告时间,主要介绍携程的今后的发展以及作品展示。主要以数字来展示。
      第二场是台湾Yahoo的设计总监分享的,通过翻译也听懂一点,了解他们团队怎么产生一个作品。为了一个产品头脑风暴,会召集不同的岗位童鞋来做风暴。整个项目团队成员还是要以坐一起,有问题立马站起来讨论,一是节省时间,二是避免找会议室。整个团队要互相信任,多谈我们,少谈我。这种在项目团队中还是非常重要的。针对一个产品,不要一开始就直接开PS软件,而是快速的画出原型,拿着低保真的原型跟用户去讨论,实现快速上线,然后根据用户的反馈在修正。PS:针对用户研究的工作,在一般性企业中是很少有的,有的话很多也是交互兼职做的。在天朝,主要竞争太激烈了,一个产品不允许有太多的时间。
     第三场是青蛙设计的战略官,以及第四场华为首席体验师董建明的分享没太认真听,青蛙设计的分享也是围绕用户研究,产品等,都基本有点类似。
     下午的第一场在体验设计专场听了关于UX项目的管理工作。整个分享会还是以分享者在平时工作中的总结经验为主。项目管理一般有前期准备、中期根据项目紧急度做不同的跟踪,避免时间到期工作还没开始。项目结束后自己要总结这个项目自己存在的问题以及做得比较好的地方。重点有提到利用表格管理项目时间、帮助团队成员摆平一切障碍,这也是团队负责人应该要做的。自己的零星记忆或总结想法都可以记录起来。
     第二场在前端专场,有幸听到小鱼关于web未来是什么样的思考,以及关于如何学习新技术的回答。学习新技术应该是为了帮助我们解决问题,更好的解决问题,而不是盲目的跟踪新潮流。不管是CSS2.1还是CSS3,不管是node.js还是PHP,都只是帮我们利用这个工具来解决问题。
      前端的第二场分享,吐槽句确实分享得有点那个。在上面直接分享sass语法而由于时间问题没分享团队协作等等这些重点的东西。在当时有翻PPT,有提到规范、工具等这些确实会有一定的帮助。
     前端的第三场主要分享没认真听,只知道他们IOS团队开发了一个可以直接在手机上演示交互原型的工具,这个期待开源。大概了解一下基本是原生APP与普通页面的结合,即APP中的webview。前端负责模板与数据拼接。。
   最后一场由于时间的关系,克军的关于还原“活”的设计没听,直接奔去外滩,拍了些照片、逛了城隍面。
   今年的项目经历让我在听这些分享的时候,深有感觉,很感谢今年的这些项目。PS:牛人或大神都是善于去思考总结的。
2013年11月5日 By 情封 分类: 随笔
 晚上这场培训课,虽然有点念PPT的感觉,但从内容来看确实是分享者的多年总结,很多经验是很实用,特别是项目管理,这点体现得比较多,从敏捷开发模式、到项目人员管理、团队的绩效考核,特别是新老人的考核点。说道深处,脑袋里一直在循环片段,因为今年经历了以往我都没经历多的,但我感谢今年的项目团队。
       整场下来给我印象最深的除了前面的项目管理外,还有一个亮点就是最后的问答式QA的分享,那些问题真的帮助到很多人特别是从P转到M的人。主要有以后几个关键词:
1)跳出技术圈去想产品,技术只是个基础。PS:这点跟我一直谈的想的不谋而合。技术只是个工具,是为产品服务的。只有项目产品靠谱了,再去谈技术的架构才有意义。当然编码有编码的快感,但如果从整个产品的视角去观察,你体验到的就不只是一个点比如前端、交互,而是整个产品的所有能连贯的点。
2)管理者对工作亲历亲为的故事。这故事这一年来我深有体会,但我也有困惑,如果不深入到项目中,如何去发现项目问题,如何去沉淀前端技术,一直以为只有走过了才知道问题的深浅。
3)主动。主动的童鞋总是会获得更多的资源。主动包括主动交流去提升自己,主动做分外之事。人都是喜欢主动的人。
4)绩效考核表。这个还是比较深刻,主要有本月工作业绩,能力提升点。PS:这点倒可以在每个月的最后一周总结看看。
5)管理者对童鞋的评价,要懂得如何看人,如何用人,把合适的人放到合适的位置。管理者摆平心态,不怕童鞋超越自己。
PS:自己要改的点很多,但我不会后悔今年参与的所有项目,在这中间自己体会到很多,也让我思考了很多。特别感谢今年的所有项目团队。
2013年10月30日 By 情封 分类: 随笔
        接上一篇提到前端项目统一化的问题。之前的项目构建流程基本都是复制一份基本的项目目 录,在此基础上开发,等前端模板页开发完毕,再去调用YUI Compressor进行合并压缩,就单单配置YUI Compressor就要花费很多时间,曾经试过配置过于麻烦。现在可以采用高富帅套件Grunt+bower来建立团队的前端项目自动化。
      项目基本流程是这样的,利用grunt可以自定义项目模板,统一部门的前端开发项目目录。每次调用都利用自定义模板初始化项目。项目模板中可以包含css压缩、js混淆、前端拆分模板的引入、CSS、JS检测等一些基本功能。在Gruntfile.js中根据项目的不同情况做相应的配置即可。具体如何自定义项目模板,在Grunt官方模板中都有说明:http://gruntjs.com/project-scaffolding
       现在来说说前端静态资源的管理。相信每个公司或前端团队都会有一套部门内部的业务组件,包括CSS,JS。要么都直接放在某位童鞋的电脑上,要获取组件代码,得绑定HOST,要么都挂在内网服务器上。每一次的操作都是人工手动去复制一份组件代码到本地项目中,这种频繁性、手工操作的时代可以过去了,现在通过Bower来管理团队的静态资源是一件很容易、很方便的事情,既可以保证资源的统一管理,又方便童鞋调用。
       Bower本身有一份网友贡献的组件列表,可以直接通过命令行直接调用。如果你想共享你的组件到这列表上,你也可以去注册一个。
    利用这些再加上前端模块化,相信在前端项目构建上,会如虎添翼。
    PS:我没贴出具体的实现代码,是有原因的,这些都需要自己去亲自动手操作后,才会理解的更深刻。我们要自己学会搜索学习。
2013年10月27日 By 情封 分类: 随笔
   现在前端团队负责的项目越来越多,每个人都有一套自己的风格,不论是CSS的命名还是HTML的结构写法上都存在差异,更不用说JS的质量水平参差不齐。项目代码的维护性、扩展性更不用说了,以后其他童鞋来接手就会成为历史遗留问题。
      如果项目重构的话,还是要小处着手,大处着眼。因为如果代码不是你写的,你写的不知道会影响到哪些模块,所以在项目前期的时候做好模块的规划还是很有必要的,即前端模块化。
     以前的前端开发会是这样,包括现在团队某些项目还是有这种情况,拿到设计稿先审查设计稿,看看模块的复用性。然后所有的CSS代码都写在同一份中。如果项目大,页面多,写到最后估计自己都看不下去或坚持不下去了,因为一份CSS都有几千行,这对维护性来增大了很多的风险性。
    基于以上的种种原因,思来想去还是要在源头处理。
    1:建立团队的基础模块代码,是业务的抽象。如在项目中有这种类似的模块,直接调用这个模块代码,在根据实际的业务需求再做调整,这个包括JS组件。
    2:规范前端项目构建流程,可以保证每个项目的前端上一致性,这个包括前端必要的一些优化,CSS压缩,图片优化,JS混淆等等这些基础的功能,现阶段做之前比一两年前来的更容易些。
    3:建立团队的公共资源,在开发不同项目的时候,大家都可以看看团队中是否有这种资源,存在的话,直接调用。不存在的话,自己开发,如有必要,提交到公共资源。有一种我为人人,人人为我。一方面可以做好项目的沉淀,方便后期重构维护。二是为前端公共资源做好沉淀。
    之前有一个项目的前端开发采用先写模块,最后在拼装整个整体页面,这种模式跟之前的方式有点不一样,就是在测试的时候,可以先测试单模块,最后再测试整个页面。有点类似做单元测试,在一定程度上可以提高开发效率。如果存在多人的话更不会有问题。
    最后项目中会涉及到后端会拆分页面、嵌套模板,这种在前端我们也可以做得更往前一步,做好页面的模块拆分,期间我们可以不关心模板的数据,我们只关心模块代码的复用性。一个页面分成头部模块、内容模块、底部公共模块。最后的预览页还是完整的,但拆分的模块都交付给后端。具体的后端数据不同,再自行添加。
    放空的一个想法:以后做的页面,基本都是调用公共资源,包括JS组件,html、css模块,再根据需求自我调整。
    在项目协作的过程中,有好的方式大家都可以分享。不主动展示自己的工作成果是不称职的。
2013年7月31日 By 情封 分类: 随笔

    这次一看标题就知道是什么意思了。这么多篇的博客,就这么标题写的顺一些。

     最近DNSPOD一直发邮件提醒我域名快过期了,可我一点想续费的感觉都没。自己有考虑过这个问题,如果续费了,我还会继续做这个导航站吗?毕竟曾经自己也拥有过,后来还是想想算了。对我来说导航站的时代已经过去了。

     ux265.net是我2011年7月份做的,第一版是纯静态页,用JSON存数据。后来一发不可收拾改过三次ui,后端采用php来写,也正是这个导航站让我PHP入门了。早些时候也写过两篇文章来说为什么会有这个产品以及这中间的曲折。那个时候有看到好的前端博客都会收集,收集分享给前端人,那个时候写博客的人也多但现在有坚持写博客的人也少了。现在搜一下导航站,一搜一大把,内容大部分同质化。变的是ui,不变的是内容。纯看每个开发者的需求。

     从前端导航站这个产品需求来说,用户对产品的依赖性不会那么大。很多纯粹只是当备忘或者需要某个工具或网址的时候过来查下。现在大家多多少少都会通过浏览器的书签来收藏自己一直比较关注的网站。这点上现在浏览器都做的不错,有云同步。 越发这样对导航站的依赖性越少。从百度统计上来看稀稀拉拉的还是会有人。通过google搜索前端导航,排在第一位的就是ux265.net。曾经也出现过不少类似ux265的网站,至少域名还有跟我类似的,后缀不一样。现在如果要做前端导航站没做个性化定制的话,基本也玩不起来了。别人有的,你得优啊。

    情封做的前端导航站随着域名的过期也结束了。

     今年做的前端De早读课上,之前想做吐槽的,但后来算了,整天吐槽也没什么意思,负能量太多。从这个月改名叫前端De早读课。每天分享一篇,听着名字就很有正能量。大家看到域名的时候不要惊慌哈~~

   曾经有在前端De早读课上吐槽过,现在是分享工作实践或项目经验的时期。某个人的整个博客可能没多大意义,但总有精华的部分。我们要的就应该是这种有内容的博文。从中学到我们要学的。现在每天在前端De早读课上分享一篇文章到微博上,内容会涉及到前端,后端,设计,产品,交互还有一些能燃起激情的鸡汤。最重要的是一些推荐的文章,内容确实很涨姿势的。

     自己也有在想这么分享自己有没学到什么或者有没什么方式可以让我会看完长篇文章。解决方式还是有的,看完文章都要在详细页中写一些摘要。或自己的一些想法。自己引导一些用户来评论吧。

    以前在GR中最喜欢看的是牛人分享的或推荐的博文。因为觉得那个有进行过一次筛选。后来自己也收藏了一些,但面对几千篇的博文,自己想看的心都没了,整个纯粹是在逛博文而已。如果每天分享一篇还不满足,有做了一个每天随机推荐一篇文章,这个让人都会很惊喜的

 现在整个前端De早读课定位于分享前端资讯以及一些产品的吐槽等。现在基本推荐者就我一位,好心酸。但我觉得这事做的很有意思,会不断对这个产品进行改进。不管是从UI还是从功能上。

附上前端De早读课地址:http://www.zaoduke.net/

2013年7月10日 By 情封 分类: 随笔

针对这段时间考虑的前端如何方便的修改 静态资源与模板的问题,现在把讨论的方案做个总结:

A方案,即TM时期的解决方案:弄一台测试服务器A开放相应的目录权 限,前端或UE都在这台服务器上修改。A具有SVN服务器相同的代码。待UE都修改好了,在提交代码。不定期或定期去同步代码到SVN 服务器。(类似的是UE各在自己的电脑中配置一个环境运行代码,采用这种方案只是由在自己的代码上变成共享使用同一台服务器),好处就是 所改即可所见。

这个方案有个缺点就是不能多人修改同一份代码。否则会被覆盖。有点类似FTP。多人修改同一份代码的几率有多少。修改模板的时候会跟后端冲突,这点也有坑 的。

B方案:对前端开放SVN服务器的相应目录权限,UE每修改完一个BUG,都要commit去检测看看是否有改正确,然后要同步出去,期间要花费1分钟的 时间。这样导致commit的版本会过多,而且当产品要发布的时候刚好你提交了你的测试代码,后果不堪设想。(如果branch可以解决 的话,这个顾虑可以没有)。主要现在后端上没人打branch。

C方案:利用nginx把线上的静态资源代理转发到项目SVN中。只要修改好本地的静态资源文件,就可以看见所改的。就是修改模板的时候不太方便,只能 去修改解析后的源码。如果测试没错的话,在去模板文件中修改。

这个方案不好就是对模板的修改需要做两遍。这两遍的过程中往往会出现改的问题。

D方案:就是采用虚拟机的方式。里面装好项目,每做一个项目都需要做软链。很多程度上要依赖后端。往往后端对这种每次做软链也很不爽。这个方案我已经采用 半年多了。

 

A与C的方案中,现在有点偏向C。
限于项目权限的问题,暂时没有完美的解决方案,跟朝东商量后,基于我们现有的情况。我们就暂时采用C来做。
如果哪一天权限全开放,前后端就好统一了。
如果有什么好的方案,我们也可以讨论讨论。。。

2013年6月24日 By 情封 分类: 随笔

这个活动从立项到项目接近尾声,整整花了三周多的时间,在这中间两个开发人员都是抽时间来做的。这点让我怀疑现在的分组是否有问题,当涉及到一些开发时候人员的调配问题。

   我是上周才开始进入与后端工程师的项目联调。短短的修改、测试联调期间,发现了项目中的一些问题。现在也做个总结就当以后回顾吧。

0:在项目立项会议中,运营大概讲了这次社区活动的目的。但没对具体的工作做模块、功能拆分(涉及到多人)。这个在后面影响很大(对功能的技术评估),估计在会议前没多少人看需求文档。

【建议】在会议前理解需求(知道要做什么),针对页面的功能做拆分,具体到技术评估。

1:交互原型稿在多个环节中不一致的问题。运营、前端、视觉这三个人拿的原型不一致。可能因为交互稿版本的更新导致。针对图片尺寸,在交付稿上有必要直接写出尺寸来。

【建议】每一次的原型更新都要通过邮件周知项目相关人。不管是以附件的形式还是以网址的形式都可以,保证原型稿最新。

2:视觉设计师的交付物PSD。对这个PSD,我个人觉得应该是要跟交互稿一致。比如弹窗有多少种情况就应该做出多少个弹窗(即使只是一句话内容的变更)。这在前端环节上有一定的帮助。对PSD本来应该有一个成熟的设计规范。

【建议】视觉设计师设计完PSD后,交给上一环节的人审查看(交互设计师、需求方),是否有漏掉或什么,比如内容图片的尺寸,模块的内容展示是否跟原型稿一致。有时候PSD的画蛇添足会给前端不必要的麻烦。

3:前端工程师的交付物,静态页DEMO。

1)对这个我想说的是JS组件的问题。每一次项目或活动,FE都是直接复制一份本地JS组件放置项目中,但在嵌套页面的时候,后端工程师也直接复制至项目文件。这样做的后果是每一个项目都有一份JS组件,对后续的项目组件维护非常的困难,很难统一。

2)根据目前情况,前端工程师还是没习惯看下原型根据PSD写代码。或者写完模板页跟原型稿对比一下看是否缺少了什么。这对接下来的环节来说相当重要。

【建议】针对这一点,制作了4399 JS组件CDN服务页,供前端、后端人员查询。提高前端代码的统一性欲维护性。

4:后期的前后端联调。这个问题点蛮多的,因为接近项目末期了。现在说说发现的几点问题:

1)模块的完整性。一个模块刚开始肯定是有数据跟没数据情况。对模块无数据情况往往会让项目相关人遗忘。只要在交互设计这源头做好把关在一定程度上可以避免。

【建议】这点如果在前端模板页上有清楚的标识,会在一定程度上避免。

2)模块的测试。针对这次活动有个翻牌的模块,涉及到是否中奖等弹窗。这点往往给QA的时候不能很直观的测试。因为这次都是需要触发某种条件才可以出现的情况。

【建议】这种可以做一个测试区域的模块,点击触发某条件下的弹窗。这种可以当作是单元测试来做。这种在最近做的几个项目中有遇到过。

3)最无奈的功能:地址管理。这个功能在积分商城中已经有做过而且还是很完整的。但由于某种原因不能在这边迁移导致这次做地址管理的时候整体交互体验不好。

【建议】针对游戏吧的一些基础性功能(包括前后端的产品功能),还是要开始着手去做,不然等要做到了才会心痛。

5:上线前的测试用例、测试数据的清楚等。

6:最好有个测试用例文档,里面包括功能模块各种情况,包括模拟测试的地址。而不止是UI方面的测试。

PS:一个小小的活动页折腾了三个礼拜多,在一定程度上还是有暴露出问题的。本身活动没人负责,运营很难驱动的起来。不过我们都应该考虑问题的时候多想一想。一个看起来简单的模块做起来还是有很多细节的。


现在总体感觉宁愿写模块后在拼装其页面,从小到大。这样测试起来也方便简单。

每一次经历的项目总是会遇到很多问题,把这次的问题想办法解决,避免在下一个项目中再次遇到。

2013年4月14日 By 情封 分类: JavaScript

这周终于体验了这个Grunt神器了。Grunt是一款基于任务的Javascript命令行构建工具。具体是怎么用的,用来做什么的,谷哥很多办法。我只分享我在体验的过程。

要体验Grunt,必须使用Node.js 与 Grunt。在安装完Node后,切换到项目目录,这个目录中必须要有Gruntfile.jsPackage.jsonREADME.md 这个不是必须的。然后使用win自带的命令行窗口(WIN+R)来安装需要的grunt插件。

一般构建项目,会安装npm install -g grunt-cli,如果提示本地没有grunt,那需要在安装个npm install grunt,这两个是基础的。我在git上有做了一份gruntDEMO,需要的移至https://github.com/f2er/ks-grunt.git去clone。其他的就是grunt插件的事情了,需要什么样的插件就install,插件主要在https://github.com/gruntjs。

有了这些基础文件后,重点难点在于Gruntfile.js的配置了。对于配置多看API,多折腾下就可以了。我一般都用到lesscssminwatch,很多高深的还没摸透,现在基本可以满足我构建前端项目的需求了,压缩静态资源文件,分模块编写样式,JS代码。这样在开发环境中体验不错。

Grunt-contrib-watch是个很好用的插件,主要用来监控文件是否产生变化,然后对文件重新编译。如果在配合浏览器插件自动刷新页面,都F5都省了。

现在已经爱上这个构建工具了,确实提高了很多前端的工作效率。这样用less来编写css,方便很多,不用在单独找编译器来编译less了。