Home > Web Front-end > HTML Tutorial > 我是如何对待写静态页这项工作的_html/css_WEB-ITnose

我是如何对待写静态页这项工作的_html/css_WEB-ITnose

WBOY
Release: 2016-06-21 08:45:52
Original
910 people have browsed it

什么是静态页

传送门

文章起因

最近负责公司商家后台项目的前端业务,可惜只是写静态页,不用写任何 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等方式发送给 B , B 将代码下载后,在本地预览,确定符合需求后,将静态页面套成后端模板(例如我司使用的 FreeMarker )。

配合代码管理工具

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

我是怎么做的?

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

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

我的方案如下:

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

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

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

一些经验

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

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

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

By vczero

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

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

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

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

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

上图来自百度~~~~

source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template