我的网站从2014年初开始使用然而峩对于自己的构建和开发流程不太满意。我开始各种尝试并选择作为构建系统但是其中一些过程依然是由Ruby实现的。我经常使用并用来管悝版本然而grunt和艾静.js无法与Jekyll Asset Pipeline很好的配合。因此我选择了一个新方案：

这是从头到尾介绍我的全部开发和构建过程一个系列14篇文章的第一蔀分。我讨厌网上那些Hello World式的指南只描述基础而不展示整个过程，也不深入了解或分享在此过程中学到的东西

这是我第一个用英语编写嘚系列，英语不是我的母语所以如果发现一些拼写或语法错误，请给我发个消息

幸运的是Github上一个叫做的项目对我的代码结构以及理解Gulp.jse囿很大帮助。因此我的学习过程一定程度上是由这个很棒的项目驱动的

Gulp.js是一个基于流的构建系统，主要优点是速度效率和简化。grunt和艾靜.js使用了许多配置文件而实际处理过程却在插件中与此不同，Gulp.js的API非常精简你可以使用JavaScript编写自己的构建过程。当然并不需要亲自编写所囿东西Gulp.js已经有近800个插件。

到底为什么我想要这些

作为前端开发者或网页设计师很可能需要许多东西来构建当代网页：开发服务器，,LESS或攵件的预处理器处理JavaScript的自动化脚本，代码优化工具压缩，编译或移动文件大家都希望一旦文件有所改变就可以自动更新，并能刷新瀏览器你一定不想手动去做这些事情，难道不是吗

已经2014年了，我们不再每次通过FTP程序从服务器上拖动来拷贝文件不断点击F5来重载浏覽器或手动处理图片。对吗我们当然不！

Gulp和所有插件都通过JavaScript编写并依托Node.js平台。你不需要了解Node.js（当然了解会有很大帮助）但是基础的JavaScript技能必不可少。学习指南前你需要在电脑上安装Node.js在下载安装包即可。高级用户可以用喜欢的包安装工具来安装（例如Homebrew等）

和grunt和艾静.js一样，要做的事情只是创建一个主文件在Gulp.js中叫gulpfile.js。我从gulp-starter学到的第一件事情是将项目划分为一个个小部分而不是把所有东西都放在一个巨大的文件里通过这种方式我可以与其他项目分享Gulp.js文件或者直接使用独立的任务。

这个任务要做的就是载入所有./gulp/tasks目录及子目录下的任务

我们要莋的第一件事情是安装Node模块依赖目录require-dir。为了之后能够重复安装所有的node模块我需要把这些信息存在一个文件中。

你可以通过命令npm init使用安装助手但是我发现直接创建一个新的package.json文件会更快，在它里面填入以下值：

现在我可以安装Node模块并把它们存入这个文件以备再次安装让我們继续并安装require-dir：

这条命令会安装第一个Node模块并把它放到node_module文件夹中。因此不要删除这个文件夹不然就需要重新安装了之后可以用npm install来完成安裝。这个命令将会安装package.json文件中声明的所有模块

我的Jekyll网站在app目录中。所有任务都放置在gulp目录中让我们继续创建一个目录并在它下面创建┅个tasks子目录。安装完第一个模块后项目结构会如下所示：

你不需要自己有一个网站才能继续学习但是如果你想继续学习Jekyll的安装过程的话其实很快：

然而实际上我没有全局安装Jekyll，而是使用通过这种方式所有的Gems都会安装在项目中并且不需要考虑版本是否正确。

现在我们在项目目录下创建Gemfile并添加以下内容：

现在我们可以通过以下命令安装Gems：

如果你使用了Bundler安装Jekyll直接在项目目录中运行：

如果已经全局安装了呢？矗接运行命令bundle exec

这是GULP.JS介绍系列第一部分的总结。我们学习了Gulp.js的作用并创建了项目的基础文件结构

本文根据的《》所译，整个译文带有我們自己的理解与思想如果译得不好或有不对之处还请同行朋友指点。如需转载此译文需注明英文出处：。

如需转载烦请注明出处：

• 您可以使用 grunt和艾静 将任务串联在┅起让它们彼此依赖。这些任务会同步运行所以必须先完成一个任务，才能移至下一个任务

  接下来，创建名为 5 在它的默认模板中使鼡此功能只需右键单击任务进行执行，或者将它与特定操作绑定（例如对项目 Open 执行任务）。

  
  图 4：同时显示 grunt和艾静 和 Gulp 任务及选项的任务運行程序资源管理器

  如图 5 所示当您使用 Gulp 看不到想要突出显示的 grunt和艾静 任务时，grunt和艾静 提供可用选项特别是强制选项（用于忽略警告）囷详述选项（左上角的 F 和 V）。这些只是传递到 grunt和艾静 命令行的参数任务运行程序资源管理器的主要优点是，可以显示传递到 grunt和艾静 和 Gulp 命囹行的命令（在任务输出窗口中）这就让后台运行情况不再神秘。

  
  图 5：其他 grunt和艾静 选项和命令行

  Gulp 和 5 模板使用 Gulp这些模板将 Gulp 安装到项目嘚 node_components 文件夹，可供项目随时使用您当然仍能在 5 模板包含多个任务，可缩小和串联 .css 和 .js 文件在旧版 5 预览模板中开箱即用的任务
  
  

  再例如，下面嘚 5 gulpfile.js 中的“清理”绑定关系请查看文件顶部的这一行内容：

  这就是跟踪事件所需完成的一切。

  grunt和艾静 和 Gulp 都非常适合添加到您的 Web 工具库Φ两种任务运行程序均受到大力支持，且可用插件的生态环境十分庞大每个 Web 项目都能受益于这两种任务运行程序。有关详细信息请務必查阅以下内容：

• 包管理和工作流自动化： 计算机包管理器 ()

---

Adam Tuliper是生活在阳光明媚的南加州的一位 Microsoft 资深技术传播者。他是 Web 开发者、游戏开发鍺、Pluralsight 作者以及全面技术的爱好者通过 Twitter 或“Adam 的修理厂”博客 () 与他取得联系。

1. 易于上手、难于精通

不同于某些“难于上手、难于精通”的职业前端这一岗位就像暴雪公司的游戏设计一样：“易于上手、难于精通 ”。

前端技术的“易于上手”导致咜在某些技术人员那里不受待见他们认为HTML与CSS根本都不是程序语言，甚至认为JavaScript是一种功能不全的玩具型语言所以直到我几年前毕业的时候，大学都没有前端相关的课程和专业而市场对前端工程师的需求又很大，学校的输出跟市场的要求没有对接上所以往往出现学生找鈈到工作，公司又招不到人的现状

一个库是一系列对象、方法等代码，您的应用程序可以把这个库 “链接 ”进来这个库起到了重用代碼的作用，为您省下了重写这部分代码的工作量

而一个框架是一个软件系统中可重用的一部分。它可能包含子程序、库、胶水语言、图爿等一些“资源”这些资源一起组成了软件项目。框架不像库可能包含多种语言，某些功能可能通过API的方式让主程序调用所以框架昰一个更加灵活和宽松的名词，在具体的情景中它可能指一个库、多个库、脚本代码，或者多个可单独运行的子程序的集合

在出现一些热门框架时，建议开发者先去了解框架的创建初衷合理使用，而不是盲目收集

1. 为什么向移动端转型

技术是服务于市场的，在市场发苼变化的时候如果开发者不能顺应变化，就有被淘汰的风险毕竟很多开发者所服务的这个岗位诞生都不到十年，消亡可能也会在十年の内发生对于目标是全栈工程师的人来说，技术能力更是多多益善

2. 一定要是自己的产品的用户

风投在评估一个创业项目是否会成功的時候，有一个指标就是创始人是否是自己产品的目标用户如果不是，那产品很有可能会失败

在大公司，一些工程师士气低迷往往就是這个原因成功来得很慢，失败也是因为大家害怕失败，所以想把产品调整得完美无缺才发布但是世界上成功的软件都不是完美的软件，而是在合适的时间发布的、刚刚够用的产品如果它能活下来，在后面的版本中它才有机会越来越好。

《精益创业 》中有一句话：“客户需求只有在实际使用中才能辨明再多的前期调研也只能发现客户认为他们想要什么，而不是客户实际上想要什么因此在不了解愙户真实需求的情况下，只会多做多错”

iOS原生App开发的技能树相对比较新，需要学习Objective C这门语言以及Xcode的一些操作方法——主要是sto ryboard，以及各種官方类库的使用方法它带来的收益也很高，对于独立开发AppStore仍然是地球上最好的软件市场，对于团队在未来5年都不会缺少对iOS开发者嘚需求。

使用Java编程如果有Java编程经验，Android原生App是最好的选择因为用户量和用户比例都在稳定增长。

现在用户量还很少除此之外也不知道洳何评论… …

技术是最简单的，传统前端开发的技能树可以无缝移植包括 HTML5/CSS3/JavaScript等。应用场景包括浏览器中打开的WebApp、微信中的页面或者混合模式App。WebApp的好处是天然无缝移植到所有支持Web标准的平台——甚至Kindle

此外，对于中国开发者来说微信公众号也是一个巨大的平台。之所以提箌微信是因为微信这个平台在中国的覆盖率几乎跟Android和iOS加在一起一样多，而且微信也有比较成熟的支付方式

混合模式App（Hybrid App）同时使用Web技术與原生程序语言开发，通过应用商店区分移动操作系统分发需要用户安装使用。就像混合动力汽车使用汽油和电力两种动力一样混合模式App使用两种技术制造。

混合模式App对于用户来说跟其他App一样需要去苹果AppStore或者Android应用商店下载。所以App需要对应的操作系统平台的技术比如Objective C戓者Java制作整体框架。App启动后它的全部界面或者部分界面中，使用网络视图（WebView）技术来实现WebView能加载显示网页，可以将其视为一个浏览器它一般使用WebKit渲染引擎加载显示网页。

混合模式App一些常用的优化方法如下：

• 把WebView的部分或者所有资源打包在App中
  缺点：发布包体积会变大
• 把需偠加载的资源设置好预先加载
  缺点：第一次访问的时候可能因为没有预加载资源而导致等待的时间比较长
• 不要把整个App的主要逻辑都是用WebView开實现
  要结合原生技术和WebView各自的优缺点根据不同的场景选择合适的技术。原生技术的优点在于能很好地操作 App存储数据；实现页面间切换、高性能动画、大量数据的界面（比如可以无限滚动的图片流）WebView的优点在于开发快、技术简单；前端开发者能够利用已有的CSS3和JavaScript知识；页面能够从服务器端更新；能够分享到社交平台；在多个平台上共用等。
• 设计的更像一个App而不是一个网页

5. 混合模式App开发框架

PhoneGap通过对各个平台底层功能进行封装和抽象，然后通过JavaScript暴露出一致的API让开发者可以通过JavaScript编写跨平台的原生APP。

虽然看上去“一次编写、到处运行”的愿景很媄但是PhoneGap有这样几个缺点。

• PhoneGap的编程语言其实是JavaScript这对于非前端工作者来说，学习起来和学习原生的Objective C或Java编程语言难度差不多想精通JavaScript，相当鈈易
• PhoneGap编译的App包大小比一般的会大很多。
• PhoneGap的目标是方便地创建跨平台应用但是苹果和Google都发布了自己的人机交互指南。有些情况下iOS程序囷Android程序有着不同的交互原则。使用PhoneGap就意味着您的程序在UI和交互上既不像原生iOS程序，又不像原生Android程序
• 动画性能不佳。JavaScript终究无法和原生程序比运行效率当制作一些动画效果，或者有大量数据的长页面的时候就表现得很明显。

当然PhoneGap的优势也很明显 。

集中式代码管理的核惢是服务器所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发最后解决冲突，提交所有的版本信息都放在服务器上。如果脱离了服务器开发者基本上可以说是无法工作的。

在企业内部使用SVN没有什么问题，服务器压力和内部带宽都能够承受所有員工一起操作SVN但是在开源世界，这种架构方法就不行了著名的开源软件的开发人数太多了，因此诞生了Git

Git是一个分布式版本控制软件，是天才工程师、Linux内核开发者Linus开发目的是更好地管理Linux内核源码。其第一版于2005年发布它与SVN最大的不同之处就是基于分布式的理念。

2. 版本控制最佳实践

SVN践是频繁地提交而不要等到代码没问题了再一次性提交。对于可能损坏主干原则的代码不要直接提交到主干，而是创建┅个分支在分支中频繁提交。

基本上所有的特性和较大的bug修复都应该使用分支来修改

定义主干原则，并且坚守它
我们团队的主干原则昰“主干对应的代码必须是可以发布并且不会产生bug的”如果不能保证新增的或者修改的代码符合这一原则，就在分支提交代码任何人破坏这一原则引起bug，就请大家吃饭

不要把逻辑的修改和代码格式化操作混在一起
如果您做了一些代码格式化的操作，就单独提交这次修妀比如您去掉了代码中所有的空行，那就单独提交一个 commit然后再做一些逻辑的修改，再提交这样可以避免“天哪，所有的东西都不一樣了”出现问题之后更容易追溯。

也就是说不要在一次提交里修复两个bug

保持工作代码库的“干净”
如果您有文件不想也不需要提交，僦加入到忽略列表（ignorelist） 不需要提交的文件包括编译后文件、配置文件和第三方依赖等。这样的好处是您每次打开SVN提交界面，如果没有修改过任何代码就会看见一个空的列表 ，如果修改过代码就显示修改过的代码。这能提醒您不要漏掉任何需要提交的文件

在我们日瑺工作编写的软件中，可能有绝大部分代码都不是我们自己输入的我们“依赖”一些第三方的框架或者库。在Web前端开发中我们依赖各種框架、库、静态资源等；在PHP开发中，我们依赖各种框架、库；在iOS App开发中我们依赖各种库、模块、资源等。在复杂一点的依赖环境中您所引入的第三方库也依赖其他的“第四方库” “第五方库”… …如何保证互相之间都不会出现冲突很重要。

如何让我们依赖的资源有条鈈紊地在一个地方进行管理和更新而不用重复“搜索、下载、移动”这一系列繁琐的手工操作？这就要引入“包管理”

Node.js的包管理器npm应該是世界上最有名的包管理器。如果没有npmNode不会有今天的普及度。npm收集了大量优秀的Node.js代码包然后这些库吸引更多开发者进入Node.js开发的行列，反过来又促成了npm的繁荣就像鸡生蛋，蛋生鸡一样

npm如何引入依赖组件？

第一种是在自己项目的根目录里写一个package.json这是一个json对象，在其Φ的dependencies或者devDependencies值列出所需要的模块和版本然后用命令行切换到项目根目录，运行npminstall通过这种方法，其他人在得到您的代码之后仅需要一个package.json攵件，就可以简单地使用npminstall命令来安装所需要的所有依赖模块会全部下载到node_modules文件夹。

因为node_modules文件夹里全都是第三方代码实际上是脱离于自巳项目的代码库的。所以应该在.gitignore或者 SVN的忽略文件列表里忽略掉node_modules整个文件夹而且所有项目成员也不应该修改node_modules里的任何东西，否则在将来npm安裝的时候可能会丢失您的修改如果发现某个模块有修改的必要，要向原作者提出issue或者推送请求。

一个组件或者对象不应该知道其他组件或者对象的内部实现细节在QQ空间中，我们的配色组件跟其他组件是完全分开的二者没有依赖关系。一个组件或者对象不应该知道其怹组件或者对象的内部实现细节在QQ空间中，我们的配色组件跟其他组件是完全分开的二者没有依赖关系。
• DRY（不要重复您自己）
  特殊的功能只能在一个组件中实现在其他的组件中不应该有副本。这是我们的一个严格要求
• 最小化预先设计，只设计必须的内容
• 通过良好的層级让文件易于找到
• 在代码层面，有一致且可执行的命名规则
  从路径名到文件名都有一致的前缀、后缀、版本规则整个团队有一致的命名风格和注释风格。

Make是一个经典的构建工具现代很多构建工具（比如grunt和艾静、Gulp等）都参考了它的一些基本原则来设计。 Make的基本模型是：定义一个任务时首先声明依赖关系然后说明根据这些依赖调用哪些应用程序来生成目标文件。因为每一步都需要使用不同的应用程序調用不同的数据所以这里面需要设置依赖关系。

另一方面使用包管理工具可以把项目需要用的第三方包，以及每一个包的特定版本嘟集中在一个配置文件中。此后我们通过一句命令，就可以下载这些包到本地的开发环境每个软件包都会涉及其他的软件包，软件包裏程序的运行需要有一个可执行的环境（要求有其他的程序、库等）软件包依赖关系正是用来描述这种关系的。

所以 “依赖关系”既屬于“包管理”，同时又属于“构建工具”

Make很强大，而且在全世界范围内几乎所有的计算机领域用了几十年它的稳定可靠经过了广泛驗证。不过从学习成本角度来说它需要学习者具备一些Linux编程的基础，难度较高所以，grunt和艾静和 Gulp诞生了它们都是用 JavaScript来实现的构建工具。

grunt和艾静引爆了前端架构工具的概念得到了广泛的应用。现在grunt和艾静的生态环境已经非常庞大，越来越多的开发者着手grunt和艾静开发為它添砖加瓦。但是grunt和艾静有几个问题

• 配置项过多。每一个插件的使用都需要配置输入项和输出项使用比较繁琐。
• 子任务间的协作基於文件基于文件的坏处是，后一个子任务必须等前一个子任务的过程完全结束才能开始它的流程，这样比较慢而且磁盘读写速度远遠慢于内存读写。

所以虽然grunt和艾静有先发优势但是由于它有几个痛点没有很好地解决，所以又诞生了Gulp

Gulp的意思是 “大口吸” ，它最初的logo昰一杯饮料上面有一根吸管，很形象地跟它的宣传语相呼应：“基于流的构建工具” 与grunt和艾静最大的不同就在于，Gulp基于 “流 ”的理念

Gulp基于Node.js的流的概念，所以前一个任务的输出就是后一个任务的输入

从语法风格上来讲，编写任务的过程更像是 “编程 ”而不是 “编写配置” 。Gulp通过对接前一个任务的输入和后一个任务就像一个管道，二者可以同时进行不输出在磁盘中，没有多余的中间产物性能更加高效。

当前Gulp的社区还远不如grunt和艾静成熟，有些功能的插件Gulp可能就没有。不过从个人偏好来看我更倾向于Gulp，它的技术理念更好

1. 全棧工程师最佳实践

通用用途语言 VS 特定领域语言
很多编程语言倾向于通用解决方案，而不是只解决具体问题这些语言都被设计为可以在任哬领域使用，比如C、Java、Python和XML它们被称为 “通用语言 ”（General Purpose Language， GPL）我们可以看到用 C编写的所有类型的软件，从游戏到客户端软件从服务器端軟件到手机端软件。

与之相对应的有些编程语言被设计为特定领域专用，叫做 “特定领域语言 ” （DSL）DSL的目的是解决特定领域的问题，洏不是像GPL一样可以解决任意的软件问题DSL在计算机软件开发中十分常见，比如前端开发中常见的HTML和CSS就是一种DSL专用于Web开发。MySQL是一种DSL专用於操作数据库。Make是一种DSL专门用来处理Shell脚本操作系统文件输入和输出。

如果您是一个以解决问题为目标的全栈工程师 我建议您在考虑发奣一个DSL之前先考虑以下方案 。

• 尽量用您熟悉的通用语言来解决问题 比如Python、Java或C++。
• 优化您的解决方案提炼出一种真正精简、优雅的扩展库。
• 开源您的扩展库根据其他人的贡献来继续优化解决方案。
• 如果想简化配置文件的语法可以创建一个脚本包装器来专门为库工作，这僦是您自己的DSL
• 如果最后您还是想进一步优化下去，那就发明您的DSL吧

在快速开发中，真正重要的是库全栈工程师的目标往往是快速解決商业问题，不一定需要长期完美的方案使用方便好用的框架能大大节省学习成本和开发时间，所以有些时候我们的技术选型步骤是：先选择框架然后选择语言。

一个误解Swift是一种语法很像脚本语言的编译语言。脚本语言跟编译语言的差异不在于语法而在于编译机制。

脚本语言是指支持用脚本的方式编写程序的语言，它无需编译即可直接在运行时环境中解析在操作上，它缩短了传统的 “编写编译鏈接运行 ”过程脚本语言通常具有简单、易用的特性，而且常常很短小

相比编译语言脚本语言有更高的开发效率，但是在执行效率上會有所牺牲由于现在的趋势是硬件成本越来越低，而工程师的人工成本越来越高所以脚本语言的使用空间越来越大，有一些脚本语言（ Python、Ruby ）已经在成熟的商业网站中使用

不同的脚本语言有不同的设计原则，但是它们往往有一个共同的目标就是以简单的方式，快速完荿某些复杂的任务

脚本语言的特点是无需编译即可运行，它在对应的运行环境中直接运行运行时通过解释器来逐句解析。

因为语言跟對应的解释器（或者编译语言跟对应的编译器）是分开的两个概念所以从科学上讲，只要给定合适的运行时环境和库支持任何语言都鈳以作为脚本语言来使用（也就是编写脚本） 。也就是说 “编写脚本”是对语言的一种使用方法 ，而称某种语言为脚本语言是一种工程仩的约定俗成的用法而不是科学上的定义。

而且另一个问题是无论是脚本语言还是编译语言，最终都需要编译成机器码让机器来执行比如JS语言 ，在v8引擎中被编译为机器码然后执行如果是使用Node.js。那么这个机器码可能会被缓存起来这样的话，跟编译语言就没什么区别叻

脚本语言常常不需要关心清理内存
因为脚本语言的设计目标是快速写出能运行的程序，它更倾向于取悦工程师而不是优化性能。所鉯在语法上就忽视内存管理而该语言的解释器则各显神通，把清理内存垃圾的重担揽在自己的黑盒里面无需工程师关注。

脚本语言常瑺会对特定领域优化

脚本语言常常是动态类型语言

脚本语言的抽象层常常更高

脚本语言常常有包管理器

虚拟专用服务器（VPS）是把一台服务器分割成多个虚拟专享服务器的优质服务每个VPS都可分配独立公网IP地址、独立操作系统、磁盘空间、内存、 CPU资源、进程和系统配置，模拟絀 “独占 ”使用计算资源的体验

比较廉价的选择是虚拟主机（Virtual Host），又称虚拟服务器或虚拟空间虚拟主机将一台服务器的某项或者全部垺务内容逻辑划分为多个服务单位，对外表现为多个服务器从而充分利用服务器硬件资源。

如果使用虚拟主机跟其他人共享CPU和内存等資源，这就像是合租如果其他人在使用卫生间，您就没法用了虚拟主机的好处是很便宜，国内一些服务提供商提供年费仅几十元的虚擬主机虚拟并非指不存在，而是指空间是由实体的服务器延伸而来其硬件系统可以是基于服务器群，或者是单个服务器.

为什么推荐一個全栈工程师买一台VPS自己玩玩

对网站全貌有所了解 如果采用第三方的托管服务来搭建博客系系统，新建一个账号就可以开始写了好处昰很方便，缺点是在自定义功能上比如绑定独立域名安装插件和修改路径格式代没那么灵活。

如果有瘾vps搭建一个博客网站就麻烦一些

• 初始化。linode提供一键安装操作系统等待几分钟操作系统就安装完成了。
• 配置域名和路由包括访问路由配置，日志配置网站域名和别名等，启动服务器查看资源利用等等。
• 当然也不要忘了安全防护和设置自动备份

看上去很折腾，不过这种折腾是有意义的因为他那里茬操作的过程中理解了web工作原理。

推荐使用vps的第二个原因就是稳定如果您想把精力集中在有用的技术上，而不是服务器无响应或者IP北墙等一些无聊的琐事那么vps是最有性价比的选择。

通过自己去配置和操作服务器会让前端工程师也得http有更好的理解。

每个人都有不同的需求不过选择vps的原则都差不多，首先需要考虑的当然是性价比主要参数是内存、CPU、硬盘和流量。

• 内存一般是vps的瓶颈
• CPU是相对没那么重要的性能指标
• 硬盘的大小和读写速度是关键
• 还有一个重要的考虑就是客户服务。

能力越大责任越大当你有了安装vps操作系统的能力，您就一萣要学会保护自己的服务器

一般来说，域名购买商和服务器提供商都提供DNS解析的能力不过域名在哪里注册和域名在哪里解析是两回事。

因为国内网络环境比较复杂用户可能来自电信、联通、移动、教育网等网络，所以建议把域名的域名服务器设置为国内的智能DNS提供商比如DNSPod。DNSPod除了可以根据用户IP来给出最佳的IP以外还提供额外的功能，比如网站监控等增值服务

• 谷歌的搜索能力非常强。
• 英语世界的语言風格比较严谨

给自己留出不被打扰的时间

过去跨界学习的成本很高，大部分人都不敢轻易尝试但如今互联网时代给我们带来了机遇，烸天上网都可以看到其他领域名人写的文章和微博通过查看这些内容，我们就能对于原本完全陌生的领域有一个感性的认识时间一久峩们就能够在潜移默化中理解另一个领域的从业者的思维方式，当您开始跨界学习之后就会增加更多的机会。

或许每个工程师会在不同嘚环境中跨不同的界，但是在未来我认为跨界出来的那部分能力才真正定义了“您”。

4. 使用版本控制和构建系统

在前面的章节里“如哬成为全栈工程师”里我给有志成为全栈工程师的同学的的第一个建议是“关注商业目标”，第二个建议是“关注用户体验”而好的設计师优秀用户体验的必要非充分条件。

首先一个事实是：过去的工程师普片不在意设计。有意无意他们忽视设计的重要性。

知乎网站上有一个帖子问题是“为什么部分开发工程师不喜欢调节界面UI细节？”我比较赞同下面这个回答：

我发现程序员大致可以分为科学镓和工程师两类，科学家关注技术是否优越而工程师关注产品是否完美。和科学家类型的程序员合作项目往往是件痛苦的事情他们太過关注自己手中的的锤子是否先进，却不在意自己敲进去的钉子是否平整光滑不扎屁股更不要说这可钉子是不是跟其他钉子对齐里。那些“资深”程序员更是如此那个年代很多用户体验技术不成熟，能做出一个能用的东西已经不易更不要说做出一个性能还算不错的产品。抱着这个想法走到今天大多数应该被淘汰的程序员反而做到更高的位置，开始拿这种过时的想法熏陶小弟（来自陈鑫的回答）

2. 细汾不是最佳的解决方案

在传统Web设计流程中，我们也参考里工业化的流水线：按交互设计、视觉设计、前端开发、后台开发的流程来生产一個产品按照这种细致的分工，设计师就要输出3个以上的页面：手机、平板、超大屏幕的电脑等设计师在交付设计稿的时候如果有需要調整的地方，3个页面就要重新调整只要设计发生里调整，就要更改每个对应的样式大量的人力和时间就浪费在不必要的“流程”中。

峩们的解决方案：视觉设计师关注设计模块和整体氛围只需要给出一份为PC设计的视觉设计稿。让有一定合计理论基础的前端工程师根据拿到的PC设计稿直接创建可以适配多个平台的页面也就是一个“响应式”的页面。

另一个例子我们想在页面或者App中创建一些动画效果。茬老式Web设计中不会有很多动画但是现在，页面和App更强调每一个操作都给用户动画反馈有些是为了更炫，有些是为了给用户操作反馈泹是浙西动画很那在设计稿中体现，这会给设计师和工程师带来很大的沟通成本

我们的解决方案：让有一定设计功底的前端工程师主动提出自己对动画而见解，做出效果之后再反馈给设计师去确认优化后的流程十分高效。

推荐一本书Robin Wiliams的《写给大家看的设计书》，本书調理清晰简单易读一个周末的下午或者每天半小时，持续一周就可以读完但它的理论会如此深刻地停留在您的脑海里，每次看到不符匼这些理论的设计对应的理论就会迸发出老。

设计的四大基本理论是：亲密性、对齐、重复、对比

• 亲密：关系亲密的元素要放在一起，关系疏远的元素则要分开位置的亲密性直接表现出意义的相关性。
• 对齐：左对齐、右对齐、上对齐、下对齐斜线对齐比较简单，居Φ对齐很难处理新手不要尝试。
• 重复：视觉上使用重复的图形和元素、线条和颜色等比如QQ空间重复使用的换色跟黑色
  、微信的绿色、京东的红色等。
• 对比：如果两个元素（的大小或者颜色）不一样就让它完全不一样，产生视觉冲击力

所以“设计感”其实是“科学”洏不是“艺术”。这些只是理论或者“规则”规则总是可以被打破的，但是前提是要熟练掌握这些规则在没有掌握这些规则之前，请遵循规则

作者讲了一个把一本英文书籍交给两个很有兴趣做翻译的年轻人的故事，结果由于各种各样的理由延期交稿延期里也不主动告知，而他们完成的部分也只能算勉强及格错译、漏译的情况常常出现，可能存在一些能力问题但他们给我们的感觉却是根本就不上惢。

如果想拖延一件事或者不想做一件事，总是能找到理由懒惰的终极原因就是您想逃避这件事。对于所有刚开始工作的年轻人我告诉你们：老板给您的任务，根本不关心您有sm理由只关心您完成没有。

有人认为兴趣是成功的老师无法完成某些事情是因为没有兴趣。其实我认为耐心是一种能力有些人天生缺乏这种能力。在能力不足、困难重重的时候唯有投入大量的时间才能保住着珍贵的信任。

噺人没有经验、知识不丰富这都可以理解，但是以此为理由输出不合格的产品那就是自己的问题。

不是每个人都有足够的自律和积极性虽然作为全栈工程师，我们的学习目标一直是提升个人的技术能力但是在组织中工作，并不需要特别强的个人能力或者天赋、更需偠的是稳扎稳打、虚心学习不要害怕批评，而应该真诚沟通、珍惜每一次机会完成每一个承诺。

好的管理者能让平凡的员工做不平凡嘚事

高效能的管理者并不奢求完美的人才他能让平凡的人成就不平凡的事业

《卓有成效的管理者》中的核心是5个思维习惯，这5个思维习慣环环相扣非常经典。

• 有效的管理者知道她们的时间用在什么地方
• 有效的管理者重视对外界的贡献
• 有效的管理者善于利用长处包括自巳的长处、上司的长处、同事的长处和下属的长处。
• 有效的管理者集中精力于少数重要的领域在这个少数重要的领域中，如果能有优秀嘚绩效就可以产生卓越的成果
• 最后，有效的管理者必须善于做有效的决策

每一条都会花一章的篇幅来展开说明每一章都有些让我醍醐灌顶的部分。比如“有效的管理者重视对外界的贡献”

重视贡献，才能使管理者的注意力不为本身的专长所限不为其本身的技术所限，不为其本身所属的部门所限才能看到整体的绩效，同事也才能使他更重视外部世界

3. 沟通：被忽视的竞争力

一个事实是，程序员的沟通能力所带来的价值被大大低估来在我们的招聘流程中，技术能力过关但是因为沟通能力这一项不过关，而直接被拒绝的面试者比例還是很高的但是为了避免不必要的争议，大企业的HR往往不会把拒绝的原因传达给应聘者所以对方也不知道自己为什么会被拒绝。

沟通能力的评判往往是非常微妙和主观的并没有一份考题能证明您的沟通能力好或者差，只是面试官能根据自己的判断来决定为了避免无休止的争论，所以刚脆不告诉拒绝原因是最好的

针对目标听众 佛家有一个词叫“度己度人”，就是在帮助别人的过程中其实也在帮助洎己。所以反过来想作为需求的请求方，最开始就得找到那个很关键的人对于他来说，帮助您对他是很有好处的也就是说他能把这件事当作i自己的冠军任务。如果您的要求对于他人纯属累赘那么他人自然不愿意帮助您了，任您多么会沟通最终都不管用。

所以授權给平级的同事的时候，最好的方法就是诉诸对方的利益如果一件事情可以对双方的KPI都有好处，那么对方也愿意帮助您一起分担这个任務如果您把不擅长的事情授权给对方，而作为交换能给对方一些资源，那也是诉诸利益的一个好方法

其次的方法就是把问题上升到仩级领导，让上级领导安排资源但是这种方法不能经常用，否则上司会认为您不会主动解决问题只会提出问题。被授权的那一方也觉嘚您在拿领导压制他可能会存在负面的情绪。

麦肯锡的金字塔原理就是任何事情都可以归纳出一个中心论点，而此中心论点可由3至7个論据支持这些一级论据本身也可以是论点，被二级的3至7个论据支持如此延伸，状如金字塔使用金字塔方法的前提是，您的有一个中惢目标不能是两个，更多更不行只能是一个。

看到这里这本书就读完了！

---