Press "Enter" to skip to content

Tag: 软件项目构建

webpack与项目构建再认识

webpack 这个工具在前端社区异常的流行,以至于我在一年前就简单的研究过(看这里 ,和这里 ),当时发现webpack在无意中提出了「Web模块」的概念——任何web app组成都可以是模块(JS模块是一种),对其进行依赖跟踪,当在发布时可解释最新依赖后打包出最新版本。「Web模块」的概念确让人耳目一新,不过由于一直没有参加具体商业项目,对 Wepback 没有多少经验,也谈不上有太深刻的认识(包括本质和意义)。

最近正在着手做一些实验项目,开始触及项目构建。读了《Setting up an ES6 Project Using Babel and webpack》,发现 webpack 的目标就是 给现代JS项目开发引入 构建 一步( introduce a build step into your process),这个观点我觉得很关键,和深刻。

webpack 与 现代web项目开发流程

最初的JS项目开发是比较简单的,纯手工,开发和构建(编译)混在一起。但显然,当项目规模增大,手工需要转向自动化。 然而,什么东西需要自动化呢?这个问题针对JS项目(Web程序结构很复杂),初学者具有异常的困难。所以学习使用 wepback 一开始是不容易的。

首先明白一点,编译(将一种码转为另一种码)只是构建的一步,模块打包也是一步而已,而自动化构建的具体任务(WHAT)和过程顺序(ORDER),根据项目性质的不同,工作流(WORKFLOW)不同会有不同。例如,项目使用了不同CSS架构方法,那「CSS样式开发」的流程就会不同。

从零开始为Web项目定制构建系统(三)——简单交互页

我们现在已经给项目添加了git系统,为 项目管理 打好了基础条件。接下来的一个版本继续完善「构建系统」的形式,并给wgp添加少许复杂度,做一个完整的交互页面。

wgp项目新版本功能计划如下:

  • 第一,充实build任务,划出独立的build目录,将发布版与开发版分开;添加clean反向清理任务;
  • 第二,start 任务除了启动http server,还打开浏览器;
  • 第三,添加热加载功能,不用每次修改都重新手动刷新浏览器;如 LiveReload / watch
  • 第四,添加交互行为,类似hello XXXX!

定制实验项目的计划指导

至此,「我们的定制系列」有了一定的发展模式——都是给项目的build sys完整形式,并增强功能(注意构建系统和目标应用程序功能是一对一)。「我们的系列」最后的一个目标是定制出高效的「React项目构建系统」,然而由此(简单交互页)至最后目标(React SPA)之间,还有几个版本的「构建系统」,每个版本都计划“生长”些什么,是没有严格指引的。而我们为了更好为了下一个版本作计划,我们需要这种指引。

从零开始为Web项目定制构建系统(二)——版本跟踪系统

git版本跟踪系统 可以理解为 build sys的子系统,类似于 测试子系统,因它们共用同一个系统工作目录;然而,git版本跟踪系统 比测试等「build子系统」更具独立性,因为它使用独立的工具或技术基础(git 独立于nodejs)和操作接口(git不使用npm script执行,不是构建任务的一项)。

不管怎样,版本跟踪任务 还是现代软件项目管理、构建、协作和分享的重要一环。在继续给我们的构建系统增加功能之前,先将为它添加版本跟踪系统(或者叫加入到项目管理之中)。

EM:「项目目录」是多个逻辑任务的宿主,版本管理,和软件构建是软件管理并行的两个任务。

从零开始为Web项目定制构建系统(一)——静态页面

相信很多人(包括初学者),无论是通过实践学习程序开发,还是真的开始一项商业软件项目,他们一般直接「使用现成的构建工具」作为新项目的构建工具,例如一些流行的脚手架,或者项目模板。鲜有人细究构建工具的内部构成。原因有几:

  • 第一,认为没有必要重发明轮子;
  • 第二,构建工具内部与软件编程无关涉;
  • 第三,成本;

研究构建工具内部构成的意义

而我个人认为还——研究构建工具的构成——是很有必要,这个道理有点像学前端不能只学应用框架(例如react vue),原生JS和浏览器API还是必修的;这是一个理由:了解构建工具内部结构,有助扫除「后继开发构建过程」出现的问题;

第二个理由,虽然构建工具的使用与编程是无涉的,但构建工具是用来「构建」目标程序,「构建工具」的特性与「程序」特性是一一对应的,「认识构建工具」是我们对自己的任务——程序组成的性质——深入认识的一个极好的侧面。

总得来说,构建工具的认识是很有必要的,它能提高我们的专业性——对自己的工具和任务有特别细致的了解。

「构建程序/系统 」制作的概念基础

最近觉得React编程技术学得有一定操作能力,开始转向实操阶段,转向开发环境的学习。第一个任务,是学习和定制构建工具,或构建系统。

然而,名不正,言不顺,在尝试制作一个东西之前,必须对这个东西有一定深度的认识。构建程序,或构建系统 是什么,有什么用,相信有过一定项目经验都不陌生,但并不一定精确;如果你还不能为一个特殊的项目定制 构建系统,直接使用现成的脚手架, 也是你不精通的例证之一。

JavaScript构建工具的选择

本文略译自《Choosing a JavaScript Build Tool – Babel, Browserify, Webpack, Grunt and Gulp

当我们开启一支新的JavaScript项目时,首要做的一件事之一,就是为项目建立一个构建系统(build system)。然而,由于市面有太多的选择,如果没有经验,针对某个项目构建的特性而「挑选工具」的任务本身,成了一项“开发任务”。

项目构建与源码编译

软件成品的制作可能需要多种原材料,源码(及其编译)只是其中最大的一部分而已,还可能会有多种数据资源;另外,为保证质量,源码(及其编译)也会多种处理,例如语法检测,功能测试等。软件成品的制作的所有任务为「项目构建」。

想像一下,如果存有一种简易的规则,我们遵循这些规则能正确的选择构建工具,无需耗费挑选时间,直接进入开发阶段,这不是很棒?事实上,我有过五年的使用不同自动化构建系统的经验,我掌握这样的简易规则。我知道在什么的情况下使用哪一种构建工具,读完这篇文章,你也可以。

Webpack的入门教程(一)

本文略译自《Webpack – A Detailed Introduction》。在开始阅读教程前,如果你是初学者,理解webpack我写了一些抽象提醒,你可随时回来读:

对任务细致的了解极利于对工具/技术细致的认识。本文假设你的任务是:
第一,开发一个前端JS程序/web app;
第二,JS程序使用了第三方的库;
第三,为是了提供「自动化模块化构建」,构建使用了webpack ,webpack本身也是nodejs cli 程序;
这里最巧妙,又容易让人迷惑的地方是,目标程序(前端JS程序),使用的构建工具(webpack),和依赖的第三方库,都是JS模块/软件/程序;

好,开始翻译。

Babel使用指南(一)

本文略译自《A Beginner’s Guide to Babel

本文介绍 Babel,一支允许JS开发者现在就能使用下一代 JavaScript (ES6+) 的 JavaScript 转译器(transpiler)或编译器(compiler)。

为什么要转译?

使用JavaScript构建 web 应用程序常常令人沮丧,我们必须考虑浏览器兼容性问题,例如有想要的功能吗?如果功能未实现时会发生什么情况?有些人会建议干脆不要支持这些功能,但如果我们正在构建一些复杂的东西,不得不后向兼容,这在大多数时候都是一种痛苦的经历。

Git 入门的一种(一)

不了解任务,也就不能更好的使用工具(的特性)—— 陈原

为了保证效率和质量,大型软件项目离不开源码版本的控制与管理(version-control system)工具的帮助,一种编码以外的,属于项目管理的重要工具之一,VCS提供包括「版本跟踪」和「多人协作」的功能。源码版本的控制的概念还是比较直观的,任务不难,但是当功能和任务扩展到版本的多人协作管理,再加上分布式,版本仓库在分布在多个网络节上时,VCS任务变得很复杂。参与VCS的人员涵盖了开发者,项目管理者,和周边人员(系统管理人员,学习者,软件用户),VCS是一个十足的Ecosystem,一种类似生态结构系统。

复杂回报是功能强大,灵活,以Git为例,一种现代的VCS,相当的复杂,相当的强大。然而,这对于初学者,很是畏惧,面对诸多的命令和概念,甚至有点无从下手的感觉。

怎么说Git只是一个工具,只是囊括了多种不同性质「项目源码跟踪和管理任务」,集结了多样的功能,造成学习上的困难,所以学习Git的第一步应该大略「划出这些任务」,和对应的工作角色。

Git 基础理论之一

本文具有一定理论性,不是写给初学者的,对读者有一定git经验预设,并且可能对已入门者认识git有一定的提高。

本文以仓库托管商backlog.com提供的教程  (一篇不错Git入门教程,带有理论逻辑概念,不像官方或其它偏实现技术细节的)为纲,加入自己的理解,扩展写成。

另,此托管商提供了100M免费空间可用于个人项目。