前端工作流程

最新推荐文章于 2023-04-10 16:35:52 发布
最新推荐文章于 2023-04-10 16:35:52 发布
阅读量142 收藏
点赞数
文章标签： 前端 markdown json ViewUI
原文链接：http://www.cnblogs.com/willkan/p/3307685.html
版权

若要获得更好的阅读体验请移驾http://willkan.github.io/blog/html/Workflow/

概述

为什么写这篇文章

接触前端一年了，瞎摸过来这么久一直很希望看到一个完整的前端构建流程，遗憾没找到相关文章，所以自己在做这个网页的时候顺便纪录下来自己从架构到部署的整个过程。

我一直希望有个网站可以让我用markdown写文章，并且可以在markdown中插入自己的demo（不是源码），于是就做了这么个项目让我可以轻松发布自己的文章。(文中并不会提到如何解析markdown,解析markdown可以了解下grunt-markdown)

使用资源分析

网上前端资源非常丰富，做一个网页完全没必要重复造轮子，下面是我做这个网页用到的工具及其分析。

  1. 响应式css框架：Foundation 4 很多人听到响应式会第一时间想到Bootstrap，但在网上查询后我发现很多人再说Bootstrap在移动端的性能并不好，甚至会拖慢应用，很大一部分原因是因为Bootstrap只采用jQuery这么个在移动端上并不太适合的库。而Foundation4在移动端采用Zepto，并且采用mobile first概念（就是说首先为小屏幕设计，随着屏幕逐渐增大，层次越复杂，可以和"渐进增强"类比）。 Bootstrap和Foundation的详细对比大家可以参见twitter-bootstrap-vs-foundation-4-which-one-is-right-for-you（注意，这里比较的Bootstrap版本还比较老） 感觉Foundation 4 在国内使用群还比较少，所以教程还是参见官网吧。 但是有一点比较奇怪的是Foundation 4的官方Docs在我的移动设备上仍会卡顿。是html文件太大？还是Foundation 4的css太臃肿？ 在之后真正进入开发时我会作出对比。

  2. DOM操作库：Zepto 为什么选择Zepto？因为Zepto性能比其他DOM操作库在webkit上表现好太多了。而webkit又是IOS和Android上主力的浏览器核心。部分dom操作性能对比请查看http://jsperf.com/jqm3/103

  3. 模板解释引擎：HandleBars 其他模版引擎也可以，只是这里我比较喜欢Handlebars而已。模版解释的好处在于不再需要再写大量而不清晰的js插入dom结构语句。此外，我将回用Handlebars往markdown解析后的文件中插入demo。

  4. 前端模块化：seajs 要么requirejs，要么seajs，为啥选seajs，请查看seajs处的解释 架构工具：yeoman

  5. 提高开发效率和规范 移动端动画：采用css3动画实现页面切换而不是传统的setTimeOut调整dom的样式，

  6. css预编译：Sass 因为用到了foundation 4，而foundaton 4 官方版本又拥有Sass版本，所以用上了Sass

  7. 测试：CasperJS 感觉上mocha,jasmine更偏向于本地纯js调试，而CasperJS这基于PhantomJS的工具则更适合浏览器调试

项目初始化

yeoman是什么

工具选好了之后，我们开始构建项目了。首先介绍一下yeoman，借用一下infoq上的介绍：

Yeoman是由Paul Irish、Addy Osmani、Sindre Sorhus、Mickael Daniel、Eric Bidelman和Yeoman社区共同开发的一个项目。它旨在为开发者提供一系列健壮的工具、程序库和工作流，帮助他们快速构建出漂亮、引人注目的Web应用。Yeoman拥有如下特性：

  • 快速创建骨架应用程序——使用可自定义的模板（例如：HTML5、Boilerplate、Twitter Bootstrap等）、AMD（通过RequireJS）以及其他工具轻松地创建新项目的骨架。
  • 自动编译CoffeeScrip和Compass——在做出变更的时候，Yeoman的LiveReload监视进程会自动编译源文件，并刷新浏览器，而不需要你手动执行。
  • 自动完善你的脚本——所有脚本都会自动针对jshint（软件开发中的静态代码分析工具，用于检查JavaScript源代码是否符合编码规范）运行，从而确保它们遵循语言的最佳实践。
  • 内建的预览服务器——你不需要启动自己的HTTP服务器。内建的服务器用一条命令就可以启动。
  • 非常棒的图像优化——Yeoman使用OptPNG和JPEGTran对所有图像做了优化，从而你的用户可以花费更少时间下载资源，有更多时间来使用你的应用程序。
  • 生成AppCache清单——Yeoman会为你生成应用程序缓存的清单，你只需要构建项目就好。
  • “杀手级”的构建过程——你所做的工作不仅被精简到最少，让你更加专注，而且Yeoman还会优化所有图像文件和HTML文件、编译你的CoffeeScript和Compass文件、生成应用程序的缓存清单，如果你使用AMD，那么它还会通过r.js来传递这些模块。这会为你节省大量工作。
  • 集成的包管理——Yeoman让你可以通过命令行（例如，yeoman搜索查询）轻松地查找新的包，安装并保持更新，而不需要你打开浏览器。
  • 对ES6模块语法的支持——你可以使用最新的ECMAScript 6模块语法来编写模块。这还是一种实验性的特性，它会被转换成eS5，从而你可以在所有流行的浏览器中使用编写的代码。
  • PhantomJS单元测试——你可以通过PhantomJS轻松地运行单元测试。当你创建新的应用程序的时候，它还会为你自动创建测试内容的骨架。

使用yeoman
安装yeoman

yeoman是基于node.js，首先得安装node.js，然后在命令行中安装yeoman

npm install -g yo grunt-cli bower

mac或linux下npm安装到全局需要root权限

使用yeoman
yo

yo用于构建项目的手足架。

刚安装完的yeoman（1.0版本）中是不含模版的，我先去找了个模版generator-backbone

npm install -g generator-backbone

然后使用该模版开始构建

mkdir myapps
cd myapps
yo bakcbone myapps

命令行提示是否使用twitter和coffeejs，该项目中都用不到，所以都不选

此时myapps的目录结构如下

修改前

但该架构并不完全满足我的需求，于是我进行了手动修改，修改后结构如下

修改前

yo的使用基本结束。

之后本文提到的路径都是myapps的相对路径

bower

bower用于载入网页需要的组件

由于目录变更，我们需要修改bower的路径，bower的路径在.bowerrrc文件中，将其内容改为

{
    "directory": "app/public/bower_components"
}

bower.json文件是用来描述需要载入的组件

grunt

grunt用于自动化，例如编译scss文件，编译coffe文件，部署等。

因为myapps的目录修改过,所以Gruntfile.js中的相关路径也得修改。

后面的开发中会大量用到grunt，此处先提一下grunt的一些个人经验

  • yeoman预置的Gruntfile.js很聪明，已设置为从package.json读取grunt插件并注册，只需修改此文件并执行 npm install,即可注册grunt的插件。

  • 在grunt.initConfig()中我们可以配置各种子任务，例如

      grunt.initConfig({
      copy: {
                  dist: {
                      files: [{
                          expand: true,
                          dot: true,
                          cwd: '<%= yeoman.app %>',
                          dest: '<%= yeoman.dist %>',
                          src: [
                              '*.{ico,txt}',
                              '.htaccess',
                              'images/{,*/}*.{webp,gif}'
                          ]
                      }]
                  }
              }

  })

    然后通过grunt.registerTask()来注册任务，例如

      grunt.registerTask('default', [
       'copy:dist', //执行copy下的dist子任务，
       'copy' //执行copy下所有任务，执行顺序为定义时的顺序
  ])

HTML和CSS框架

Foundation4

Foundation 4是一个CSS框架，有CSS版本和SCSSS版本，都可以在官网获得。

直接上我的html代码先

    <div class="row">
        <div class="small-12 large-9 columns">
            <h1>
                前端工作流程
            </h1>
            <hr/>
            <article></article>
        </div>
        <button class="hide-for-medium hide-for-large nav-btn"></button>
        <aside class="hide-for-small small-6 large-3 columns" data-magellan-expedition="fixed"></aside>
    </div>

这里解释一下Foundation的栅栏表格。

  • columns表示行，row表示列

  • .columns元素必须得是.row的后继元素

  • 默认版本的Foundation中，把行分成12份，使用如下：

    • small-1表示该列宽度占最近.row祖先元素的1/12
    • small-3表示该列宽度占最近.row祖先元素的3/12
    • small-3 large-4表示该列宽度在小屏幕中占3/12,在大屏幕中占4/12
    • 上述例子中的small,large表示屏幕大小，可在_global.scss中找到定义，可以在该文件中搜索关键字$small-screen

Foundation的css使用就解释到这，更多请查看API

然后来看看Foundation的js插件部分,foundation依赖于zepto或jQuery,引入其他插件前需要先引入foundation.js

若使用zepto请注意zepto是可定制的,foundation使用的是他自己定制的zepto,所以请使用foundation/js/vendor/zepto.js

SCSS

鉴于SCSS的方便，我采用了SCSS版本。这就带来了个问题，每次都要编译才能被浏览器解释。grunt这时候就起作用了。

首先说一下我SCSS的配置

  • Foundation是通过bower载入的，所以Foundation的路径是app/public/bower_components/foundation
  • 自定义的SCSS我选择放在app/resource/scss中
  • 编译后的CSS文件放在app/public/style/scss中
  • 所有CSS文件由app/public/style/main.css通过@import引入，html中只导入该css

然后就是grunt的配置了

  • 首先得往系统中安装compass（需要ruby环境）： gem install compass
  • yeoman构建项目时，package.json中已含有grunt-contrib-compass插件，该插件可以对SCSS进行编译

  • 然后可以开始配置Gruntfile.js:

    ...
grunt.initConfig({
  ...
  //实时监控
  watch: {
    ...   
    compass: {
              files: ['<%= yeoman.app %>/resource/scss/{,*/}*.{scss,sass}'],//监控的文件路径
              tasks: ['compass']//若监控文件改动，执行的任务
          },
    ...
  },
  //compass配置
  comapss: {
        //全局配置
        options: {
              sassDir: '<%= yeoman.app %>/resource/scss',
              cssDir: 'app/public/styles/scss',
              imagesDir: '<%= yeoman.app %>/public/images',
              javascriptsDir: '<%= yeoman.app %>/public//scripts',
              fontsDir: '<%= yeoman.app %>/public/styles/fonts',
              //此处配置SCSS的引入源路径，我添加了foundation的SCSS路径和animate的SCSS路径
              importPath: [
                  '<%= yeoman.app %>/public/bower_components',
                  '<%= yeoman.app %>/public/bower_components/foundation/scss',
                  '<%= yeoman.app %>/public/bower_components/animate.scss/source'
              ],
              relativeAssets: true
          },
          //局部配置，覆盖同名项
          dist: {},
          server: {
              options: {
                  debugInfo: true
              }
          }
  },
  ...
});

//往server任务中插入compass子任务，执行该任务命令为grunt server
grunt.registerTask('server', [
    ...//其他任务,
    'compass:server',
    ...//其他任务
])
...

    在命令行中执行grunt server,即可实现SCSS的实施编译

HTML模版

在HTML和CSS框架部分我们已经完成了HTML框架的构建。

下面我们开始使用HTML模版来编写网页需要模版。

HTML模版引擎的好处这里就不说了，在非常多的模版引擎中我选择了Handlebars，仅仅是因为我喜欢这个模版。

模版的编写就不说了，这部分主要还是描述如何模版文件的放置结构和实现模版的预编译。

首先来看看目录结构

  • 模版文件我放置在app/resource/templates中, 后缀名是.hbs
  • 自定义模版工具(就是helpers之类的东西)放置在app/resource/templates/helpers中
  • .hbs这些文件编译生成的文件我放置在.tmp/templates这临时文件夹中
  • 最后，把.tmp/templates中的文件和helpers连接在一起，生成.tmp/template.js

下面来看看预编译

  • 首先，为什么要预编译？

    模版文件并不能直接被js执行，需要经Handlebars解释成一个函数后才能被执行，也就是说浏览器得先执行模版解释，这对性能并不好的移动设备来说无疑带来了性能损耗。所以更好的做法是在服务器段就把这些模版文件预编译成可执行的函数。

  • 那该怎么实现预编译呢？

    grunt这时候又来了。

    预编译Handlebars需要grunt-contrib-handlebars这个插件，载入方式还是在package.json中添加该项，然后npm install

    那接下来看看这插件的配置(grunt.initConfig()中的配置)

    handlebars: {
          compile: {
              options: {
                  //函数所在命名空间
                  namespace: "Handlebars.templates",
                  //函数名称格式
                  processName: function (filename) {
                      return filename
                          .replace(/app\/resource\/templates\//, '')
                          .replace(/\.hbs$/, '');
                  }
              },
              files: {
                  //'生成文件':[需要编译的模版文件]
                  '.tmp/templates/template.js': ['<%= yeoman.app %>/resource/templates/*.hbs']
              }
          }
      }

    上述代码实现下列转换(文件所在路径都是app/resource/templates)

    • a.hbs->Handlebars.templates.a
    • b.hbs->Handlebars.templates.b

  • 把helpers也合并进来

    这里用到grunt-contrib-concat,注意文件连接顺序，应该是先连接helpers类文件，应为模版中可能会用到自定义的helper，只有先定义了helper，后面的模版函数才能正常执行

  • HTML引人预编译的文件

    预编译带来的好处还有一个：我们不再需要引入完整的handlebars.js和.hbs这类模版文件,只需要引入handlebars.runtime.js(和handlebars.js相比，没有模版解释函数)和预编译生成的文件.tmp/template.js

  • 实时编译监控

    我们可以添加监控的文件和任务以实现.hbs这类文件的实时编译，这样我们只要直接修改模版文件，并不会因为预编译而给调试修改带来麻烦。

前端模块化

接下来让我们看看该如何组织js文件。

以前我们引入js文件的方式是：

<script src=""></script>

或者是用jQuery$.ajax()

但这些引入方式有一个致命缺陷就是文件依赖问题，我们更希望看到的是像java一样可以import，于是一部分前端的前辈们就致力于解决模块化问题。

seajs(CMD规范)和requirejs(AMD规范)就是解决模块化问题比较好的两个库。

二者的详细对比我就不说了，大家可以看看SeaJS与RequireJS最大的区别。

虽然模块化的确很有用，但无可否认目前大多数的库还是传统的写法（外国也有一部分库已支持AMD），也就是说需要这些s库进行人工CMD化或AMD化。国际上的一些比较著名的库我还没找到原生支持CMD，都需要人工CMD化。

而我这次项目选择的是seajs，原因是二者在构建上都没有成熟的方案，seajs的生态圈更本地化（作者是玉伯大大），相比一堆英文的交流我更愿意用中文交流，也算是为国内前端生态圈尽一份力吧。

目录结构和seajs配置

我在这讲的主要是自己在使用seajs过程中遇到的问题和解决方案，想查看API者请移驾https://github.com/seajs/seajs/issues/266，如果玉伯大大看到这篇文章，容小弟稍微抱怨下用github作参考文档真心不太容易用。。。资料找起来还是挺费劲的。

目录结构

先规范一下scripts目录结构

scripts目录结构

以下描述的相对路径是app/public/scripts

  • sea-modules放置的是通过spm(下面会提到)加载的库
  • example
    • example/logic放置的是自己编写的逻辑模块
    • example/utils放置的是CMD化后的开源js库
    • example/templates放置的是CMD化后的模版文件(例如前文提到的app目录下的.tmp/templates.js,.tmp下的文件还未CMD化)
    • example/static放置的是已经CMD化的静态资源文件
seajs配置

注意seajs的路径解释规则,请查看模块标志

这里注意paths中定义的路径就是其直接路径,并不会互相解释,例如

seajs.config({
    //base默认为'app/public/scripts/sea-modules'
    paths:{
      scripts: '/public/scripts',
      logic: 'scripts/logic' //此处并不会被解释为'/public/scripts/logic',而是'app/scripts/sea-modules/logic'
    }
});

此外paths的配置还应注意不应以'/'结尾(仅限2.1.1版本),详情请见https://github.com/seajs/seajs/issues/926

这个问题是因为使用seajs还应注意一个初学者不太能发现的ID 和路径匹配原则

CMD化

seajs2.0开始推荐将所有js封装成CMD模块.

对于非CMD的js我们需要对其进行封装,我说一下封装foundation.js这个文件(依赖dom选择器)

define(function(require, exports, module){
    var $ = require('$');//写入依赖,需要再seajs配置中配置alias的$
    ...//源代码
    return Foundation;
})

而对于类似于模板预编译成的文件,我建议使用grunt对其进行封装,grunt-contrib-concat支持对文件进行包装,这里不作描述

部署

经过上面的步骤,网站的组织已经比较清晰,再编辑完网页所有功能后,进入下一步----部署.

yeoman配置的Gruntfile.js并不能适应所有自动化,我们需要对其进行适当修改.

先来看看我的grunt build执行了哪些任务

   grunt.registerTask('build', [
        'clean:dist',//清空临时目录
        'compass:dist',//编译SCSS
        'markdown',//将markdown转换为handlebars模板格式
        'handlebars:markdown',//预编译handlebars
        'handlebars:compile',//预编译handlebars
        'concat:template',//连接handlebars预编译后的文件以及助手
        'wrap:template',//对连接后的文件进行CMD封装
        'transport:seajs',//获取CMD模块ID
        'concat:seajs',//连接CMD模块
        'uglify:seajs',//压缩CMD模块连接而成的文件
        'useminPrepare',
        'imagemin',//压缩图像
        'htmlmin',//压缩html文件
        'cssmin',//压缩css
        'copy',//将没处理过而网站又需要的文件拷贝过来
        'rev',//为css和js添加版本号
        'usemin'
    ]);

usemin的作用请看官方说明

Replaces references to non-optimized scripts or stylesheets into a set of HTML files (or any templates/views).

屌丝翻译:替换HTML文件(或任意模板文件)的引用

举个例子,main.css经处理后变成main-rev.css,usemin就是把html中引用到main.css的地方都改为main-rev.css

连接CMD模块

这里我只讲述文档比较少的transport和concat,这两个任务分别用到了grunt-cmd-transport和grunt-cmd-concat

transport

对于为分配ID的CMD模块,我们首先使用grunt-cmd-transport抽取其ID,先上代码

        transport: {
            seajs: {
                options: {
                    alias: {
                        underscore: 'underscore',
                        backbone: 'backbone',
                        $: '$',
                        modernizr: 'modernizr'
                    },
                    paths: [
                        'app/public/scripts/example/static',
                        'app/public/scripts/sea-modules',
                        '.build'
                    ]
                },
                files: [
                    {
                        cwd: 'app/public/scripts/example',
                        src: [
                            'static/{,*/,*/*/}*.js',
                            'templates/*.js',
                            'utils/*.js',
                            'logic/*.js'
                        ],
                        dest: '.build'
                    }
                ]
            }
        }

  • 解释一下options

    • alias可以指向一个文件也可以指向自定义的别名,alias中的键值对(假设为key:value)的表示需要处理的文件中若含有require('key')则用require('value')来代替

    • paths是一个数组,表示需要用到的模块路径,例如处理的文件中需要require('logic'),而logic模块并不在默认路径中,则需要在paths中添加logic模块所在的路径(注意,此处应把file.dest指向的路径也添加进去)

    • idleading我们可以用这属性给所有抽取的ID添加一个前缀

  • 然后是抽取

    • 抽取顺序和file.src这数组的顺序相同
    • 若模块a依赖模块b,则必须先抽取b再抽取a
    • 抽取到file.dest指向的路径下

  • 模块ID的命名方式

    ID名字 = options.idleading + 文件相对CWD路径

    例如

    假设无idleading,cwd为'app/build/scripts',dest为'.build',文件相对路径为'logic/a'则ID名字是'logic/a',抽取出来的目录结构是

    .build
  |--logic
       |--a.js
    concat

    模块抽取完后就要开始进行连接.还是先上代码

           concat: {
          seajs: {
              options: {
                  relative: true,
                  include: 'all',
                  paths: [
                      'app/public/scripts/sea-modules',
                      'app/public/scripts/example/static',
                      '.build'
                  ]
              },
              files: {
                  'dist/public/scripts/main.js': ['.build/{,*/,*/*/}*.js']
              }
          }
      }

    options的paths解释和transport的options.paths一样

部署优先策略

这是我自己应用的一个策略,也就是尽量保证一步部署,不再对部署后的文件上进行手工修改

usemin并不会对seajs的引用进行修改,为了实现部署优先,我们在index.html应采用下面方式

    <!-- 引入seajs -->
    <script src="public/scripts/sea-modules/seajs/seajs/2.1.1/sea.js"></script>
    <!-- 引入seajs配置文件 -->
    <script src="public/scripts/config.js"></script>
    <!-- 引入seajs合并后的文件, 路径为合并后的文件相对路径 -->
    <script src="public/scripts/main.js"></script>
    <!-- 调用启动模块 -->
    <script>
        seajs.use(['modernizr','logic/load-markdown']);
    </script>

解释一下引入合并后的文件的原因:

  • 合并后的文件在开发调试时并不存在,调用该文件对开发不会造成任何影响
  • 合并后的文件并不符合CMD模块,只是一系列CMD模块的定义

解释一下部署后的调用启动模块

  • 引入合并后的文件并不会执行模块中任何函数

  • 当引入合并后的文件时,会对一系列CMD模块进行define,define过程应该是这样的:

    若define()的参数中含有ID,则先对ID进行路径解释,把解释后的路径添加到seajs.cache中

  • seajs调用模块时会先去查看seajs.cache中是否含有解释后的路径,若有,则直接调用该路径对应的模块,若无则想服务器获取该模块
  • seajs.use()调用模块的相对路径不是base,而是html所在路径.而只有调用的模块路径的解释路径和模块ID的解释路径相同才能正确调用, 为了部署优先,最好为启动模块设置顶级标识,应为顶级标识才能在seajs.use和require时获得相同的解释路径

测试

我选择的测试工具是CasperJS.

基于PhantomJS, 也就是说CasperJS可以执行一系列浏览器上的动作, 应该就是所谓的UI测试吧,而这正是web最需要保证质量的事.

建议使用CasperJS 1.1版本(目前最新版本)

使用请参看API

对于刚迈入大四的我来说,也就是一两个月前接触过测试这一概念,而ui测试通俗点说就是: 点击了按钮a, 页面发生了响应. 而测试就是判断这响应是否符合测试设定的标准, 无论符不符合, 都返回测试结果.

后记

本来想描述自己的建网页流程,感觉写着写着有点变成流水账了…还丢了一坨代码上来…

转载于:https://www.cnblogs.com/willkan/p/3307685.html

weixin_30287169
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
few-plato:前端工作流程插件
05-08
柏拉图（FEW） 用于front-end-work-flow的Plato插件有关少量介绍的信息，请参见 。 这将生成一份平台报告，以进行代码复杂性分析。安装$ npm install few-plato --save-dev示例gulpfile.js // Configure plugins// ...
【前端进阶】前端工作流程详解，如何构建高效、可靠的前端工作流程
weixin_55846296的博客
06-27 2031
随着Web技术的不断发展，前端开发越来越受到关注和重视。然而，前端开发本身就十分复杂，如果没有一个规范的工作流程和有效的工具支持，就会导致项目的延期、出现重复的错误以及代码难以维护等问题。本文将分享如何构建一个高效、可靠的前端工作流程，帮助前端开发者在开发中提高效率和代码质量，并适应快速迭代和高质量代码交付的要求。前端工作流程可以解释为一系列从需求分析到代码上线的标准化流程。前端开发者需要遵循这些流程，并且遵守团队内部的规范，来确保代码的质量和项目的交付质量。
前端工程师的基本工作流程
weixin_45969432的博客
10-29 5353
前言 对程序员这个行业而言, 很多朋友是通过自学或者其他方式接触到的, 在刚开始的日常工作中对一些流程和需要注意的细节都比较懵懂，今天就这个问题来和一些刚初接触前端的朋友聊聊，方便参考 项目工作流程 大致可分为九个步骤： 产品PRD评审 => 任务排期 => 需求项目建立与任务拆分 => 业务开发(并行) => 测试用例评审(并行) => 联调&自测 => 提测 => 修复测试BUG => 上线 产品PRD评审： 针对于将要开发的项目，由产品经理
一套标准的前端代码工作流
我本可以容忍阳光，如果我不曾见过太阳，然而阳光已使我荒凉，成为更新的荒凉。
02-08 451
工欲善其事，必先利其器。对于写代码而言，也是需要有一套完善的工作流（工具和流程）。先说下编辑器选择，在踏入前端行业之前，我最喜欢的代码编辑器就是 sublime text ,它很简单，编写...
前端开发是做什么的？工作职责有哪些？
黑马程序员官方博客
04-10 2782
我们介绍Web网站工作流程的时候提到，前端开发，主要的职责就是将数据以好看的样式呈现出来。说白了，就是开发网页程序，如下图所示：那在讲解web前端开发之前，我们先需要对web前端开发有一个整体的认知。文字、图片、音频、视频、超链接、表格等；程序员写的前端代码（备注：在前后端分离的开发模式中）通过浏览器转化（解析和渲染）成用户看到的网页浏览器中对代码进行解析和渲染的部分，称为 浏览器内核。而且我们电脑上安装的浏览器可能都不止一个，有很多。
前端开发是做什么的？工作职责
weixin_51689029的博客
12-06 1万+
想要了解前端从业者的工作职责，需要从一个完整网站应用产生流程入手，一个网站应用从无到有的过程大致如下 ：1）产品经理与甲方反复沟通交流，逐步确定产品需求完成设计草图；2）产品经理根据需求和草图进行分析，提交 PRD（需求文档），并与开发人员协商软件功能；3）若PRD（需求文档）协商通过，后端开发团队进行可行性分析并完善方案；在一定的准备过后，进入后端开发，并给出开发文档；4）产品经理根据协商通过后的PRD，制作原型和设计文档，并交付设计团队；5）UI/IxD等不同职责的设计师，根据设计文档和原型产出高保真原
前端浏览器的工作流程详解
最新发布
04-10
前端浏览器的工作流程详解
润唇膏：适用于Web应用程序的通用前端工作流程
02-02
适用于Web应用程序的通用前端工作流程 介绍 BalmJS规定了最佳实践和工具，以帮助您保持生产力。 自然地：使Web开发简单，自然且愉快。 基于结构：一个配置文件可以管理至少90％用例的Webapp项目。 学习一次，...
前端开发流程图
01-31
需求评审,产品画原型图或prd(流程图)提出需求, 开发提出合理化建议,完善需求与原型并确认需求 产品在jira上录入故事和主要功能或模块, 要求ui必须按照原型来,不能有字段等功能改正 确认开发组长理解需求和逻辑
微信小程序前端源码逻辑和工作流
09-01
主要介绍了微信小程序前端源码逻辑和工作流 的相关资料,本文还给大家提供了文本基本结构图和实例代码，非常不错，具有参考借鉴价值，需要的朋友可以参考下
web前端开发流程图
12-31
本资源是是以思维导图的形式展示了关于Web前端项目开发的流程图，很详细，需者自取。
公司前端的工作流程
oLylia的博客
10-29 1131
公司前端的工作流程-------准备找工作的小伙伴建议收藏
前端工作的大致流程
aziyywg3619的博客
08-22 284
前端工作的大致流程 转自大神 一只羊博客» 前端工作的大致流程: http://www.asheep.cn/skill/end-process.html 当一个项目要我负责开发时， 我的大概工作流程是下面这样的， 当然可能跟实际的某方面有偏差， 因为很多时...
企业级VUE前端项目执行流程总结
qq_34020761的博客
03-27 786
vue前端框架项目执行流程
前端介绍
m0_46307689的博客
03-05 3855
一、web前端概述 1.什么是前端？ 全称"Web前端开发"，简称“前端"，又称作“客户端开发" .可以这样简单的概括，只要是浏览器或移动设备上能直接被人看到的界面，都可以是前端开发者的工作负责范围。而配合前端工作的开发人员被称作“后端”也称作“服务器端" . 在互联网诞生初期(称作Web 1.0)网站主要内容都是静态，以图片和文字主，用户使用网站的行为也以浏览为主，“前端"词还并不存在。 但随着...
【路在前端】我的前端工作流程梳理
m0_37613418的博客
03-17 1万+
学习的意义是，即便以后我们会忘记学到的大部分内容，但剩下的东西一部分会固化在我们心中，塑造了我们的思维模式和判断标准;另一部分则融入了生活，影响着我们的涵养和气质。——我        “前端开发”工作，狭义的定义是前端交互和网页外观的实现。我们团队的前端工作涉及到WEB前端技术的方方面面，覆盖了视觉设计、前端美工、网页实现、交互式设计等技术。        笔者作为一个刚入门的前端工程师，分
web 前端和后台配合工作流程
热门推荐
林中明月间丶
11-27 2万+
下面结合代码演示前端和后台配合工作流程。 GET方式 html> head> meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> title>title> meta charset="utf-8" /> script type="text/javascript" src="
工作流程图前端js插件
07-23
工作流程图前端JS插件是一种用于在网页或应用程序中创建和展示工作流程图的JavaScript库。这种插件使开发人员能够通过简单的API调用创建复杂的工作流程图，使用户能够清晰地了解和跟踪各个工作步骤之间的关系和顺序...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值