zoukankan      html  css  js  c++  java
  • 我是如何对待写静态页这项工作的

    欢迎一起交流

    欢迎关注我的个人公众号,不定期更新自己的工作心得。

    图片描述

    什么是静态页

    传送门

    文章起因

    最近负责公司商家后台项目的前端业务,可惜只是写静态页,不用写任何JS代码,作为一名新时代的FE,一开始我是拒绝的,我怎么能做这么low的事呢?前端必须要高大上啊!什么Angular、React搞起来啊!毕竟我们招聘JD上面也有相应的技能树要求的嘛。

    不就是让你切个图嘛~说了这么多,到底能不能做?

    所以有了这篇文章。

    磨刀不误砍柴工

    开工之前先了解一下需求

    有人会问了,写静态页还要了解需求?

    如果我告诉你,我是照着产品经理的Axure切呢?

    了解之后才发现,所有后台都有计划重做。。。。。

    开工,我是如何定义现代切图的

    UI Framework

    既然所有后台都有计划重做,那么统一风格那就是必须的了。既然需要统一风格,那么一套UI Framework就是必不可少的了。这里选择Bootstrap为基础,通过less进行深度定制,形成公司统一风格UI库。看到这里也许你会说,不就是引用Bootstrap吗,如果你这么想,那你真的只能是切图了,换做我,我会这么做。

    基于Bootstrap使用less进行UI定制。比如基本色调,比如圆角,比如字体大小,比如间距,比如组件样式。通过这些工作你可以深入了解less这么CSS预处理语言,传送门

    自动化构建

    What the fuck!不就是写静态页吗?这和自动化构建有什么关系?你丫也太能折腾了。

    当然,传统使用DW画页面确实是不需要的。不过如果你是对工作效率有一点点追求的工程师,那么,你一定会采用自动化构建,让我们来看看,自动化之后有什么好处。

    1. 去除重复工作。通过自动化,你可以将重复的工作都交给构建工具来完成,比如通用头部、尾部、banner等等可以抽象成独立模板引入。

    2. 通过构建可以进行less代码编译、压缩、合并等,这一切都在你按下command+s的瞬间完成

    3. 避免出现低级错误。如果你经常切图的话一定出现过,拷贝一个新的HTML后发现样式错乱了,原来是css引用没改名字~~,这类问题都可以通过自动化解决。想想生活是不是美好很多呢。

    4. 解放ctrl+c/v。这就不需要解释了吧~~毕竟80%的代码都是这么产生的嘛。。。

    5. 提高效率。解决了上面的问题,还不能提升你的效率?

    6. 增加技能树,既然是前端来做自动化构建,那么我首推gulp 毕竟gulp的口号是Automate and enhance your workflow嘛。

    7. 如果你也是这么做,并且想到有更多益处,请给我留言^_^

    协作

    传统方式

    传统的前后端切图协作方式是,A(切图仔)将静态页面写好之后,通知 B(后端工程师),将页面通过QQ、Email等方式发送给 BB将代码下载后,在本地预览,确定符合需求后,将静态页面套成后端模板(例如我司使用的FreeMarker)。

    配合代码管理工具

    一个复杂的项目,大多会用到代码管理工具(常用的如Git、SVN等)。有了代码管理工具以后,A 将静态页面写好之后,只需要提交代码,通知 BB将代码拉取后本地预览,确定符合需求后,将静态页面套成后端模板。

    我是怎么做的?

    在我司,后端采用的是SVN进行代码管理。我们前端部门采用的是自己搭建的Gitlab。作为一个前端工程师,我毫不掩饰自己对Git的钟爱。让我使用SVN,我是不乐意的。让后端迁移到Git上?这就像空格与Tab的一场圣战~

    当然这不是最主要的,有过切图经验的同学应该都有过这种经验。你幸幸苦苦写完一个页面之后,后端同学往往会发表一些想法(虽然他们自己不写)。这里要改一下,那里改一下,如此等等。产品经理就是这么被揍的,不是吗?为了避免这种情况,最好是不是在后端用之前先让他们看一看?

    我的方案如下:
    1. 提供一个可以在线预览静态页面的地方,后端工程师在使用之前先在线预览页面并给出意见。我采用Node.js提供一个Server服务,提供静态页面预览。

    2. 提供一个在线下载源码的地方,毕竟我不想为了一个代码管理工具,发起一场战斗^_^,通过Node.js提供动态打包压缩功能,支持单个页面独立打包和打包所有页面。

    3. 上面的功能应该是自动化的,基于Gitlab的Hook功能,自动构建发布

    38.pic

    一些经验

    所谓解决方案,大致可以分为两种:

    一种是普适性的,这种往往会形成一套框架,如:Angular、React、vue等;

    一种是基于特定业务的,这种往往是多个技能树拼凑起来的一套流程

    By vczero

    我个人很认可这种说法。我自己更看重基于业务的解决方案,更能够考验一个人的整体素质。

    在我看来,解决方案没有最好,只有更合适,需要工程师在不断自我完善的过程中以不断创新的标准要求自己。我倡导一切技术性研究都应该以业务为基础。

    我在生活中比较喜欢用意淫这个词,在面试中发现有很多程序员喜欢背名词,以前端为例,什么Angular、React、Node.js、NPM、Bower如此等等,再一细问绝大多数都只是停留在一个demo中,并不能领会这些技术的精髓,以及了解技术的适用场景,我把这些称为意淫;工作中经常遇到一大堆整天吹嘘各种技术名词的人,工作中却仍然不能突破自己的舒适区,我把这些也称为意淫;

    写在最后,我个人认为产品经理是这个世界上意淫频率最高的物种。没错!我就是这么直接。

    写在最后的最后,不论你在从事什么工作,请成长在每一次业务中

  • 相关阅读:
    黑客长期摇号不中"黑"掉北京小客车摇号网
    网络犯罪新动向:“黑客”学历不高 年龄不超30岁
    McAfee重返科技业 研制D-Central防政府监视
    windows系统服务编程代码示例分享
    Fireeye火眼公司发布报告,评论中国网络间谍活动
    FBI是如何破获“美国少女”裸照勒索案的
    得到内网域管理员的5种常见方法
    别人在用你的什么技术在赚钱.其实你天天在做
    慢一点恋爱,别急着洞房
    元芳,关于向朋友借钱你怎么看
  • 原文地址:https://www.cnblogs.com/10manongit/p/12631879.html
Copyright © 2011-2022 走看看