前端自动化构建工具-构建化方法

入前端坑已经快两年半了。 这两天突然想到第一次面试时面试官问的一个问题——你是怎么理解前端工作的？

对我这个当时的新手来说，完全是扯淡，词不达意，看得面试官一头雾水。 现在想想，这也算是尴尬的聊天吧…… 两年的不断爬行，我不得不回答这个问题。 有了新的认识，趁着早上一无所有，写了这篇博客，想到哪儿就写到哪儿，讲讲自己理解的前端。

技术方面：第一阶段（新手村）

前端初学者必须掌握的核心技能是HTML、CSS和JavaScript。 这三者是前端最底层的技术支持。 如果看几年前的答案，应该有jquery，但个人认为现阶段前端圈jquery可能不是必备技能，虽然jquery对新人很友好，但是现在mvvm框架满天飞Vue、Angular、React三分天下，用起来比jquery直接操作dom舒服多了，当然这个阶段就是打基础阶段框架，类库等等可以依靠落后。 Native Js 永远是重中之重。 不了解底层原理，你只会使用框架，永远不会精通。 我推荐红皮书Javascript高级编程。 把红皮书吃透，打好基础再学习其他框架，妈妈再也不为你的学习操心了。 接下来，还有一个附加技能，PhotoShop。 你要知道你不用做ps，但是你一定要知道，而且在一些小公司，UI只会丢给你一张PSD。 没有 Sketch 这样的东西，也没有人会帮助你。 你剪图，这一切都需要你自己处理，所以PS是一个额外的必备技能。

第二阶段（副本开启）

进入成长阶段，开始打怪升级。 这个阶段持续时间最长。 这期间，需要爬无数个坑，积累各种失败经验，再一次次往下刷。 关于HTML和CSS，你需要知道各种UI框架的使用，比如BootStrap，ElementUI...，关于不同图片的格式标准，浏览器兼容性，移动端和PC端的区别，响应式布局，flex布局，grid layout，以及设计审美的提升……等跟提升你的页面开发效率相关的技能，UI框架比较杂，选自己感兴趣的看一下。

对于Js，这时候就可以开始选择一个主流的框架来学习了。 前面提到的Vue、Angular、React都是不错的选择，而对于面向对象编程、对象封装、原型继承、闭包、同步异步的区别、js的一系列进阶知识应该深入了解，并且在同时，es6标准也需要了解。 可以参考阮一峰老师的es6介绍。 书中包含了es6的各种新特性，默认参数，模板表达式，多行字符串等常用特性，拆包表达式，改进的对象表达式，箭头函数=&>，Promise，块级作用域let和const，class类，模块化等，可以自己封装组件，写出可维护性强、可读性强的代码。 而且平时需要多看别人写的代码，学习别人的优点，多看技术文献。 最重要的是总结自己的问题。 比如遇到bug，一头雾水，就解决了。 下次再遇到同样的问题，可以看看此时总结上一个问题有没有效果。

第 3 阶段及以后

了解各种设计模式，了解各种框架的源码，前后端全包了，自己写js框架……嗯，到这个阶段我就不写了…….. ..

在职的

一个完整的工作流程应该是：

项目立项--项目讨论--需求确认--产品原型--后台开发，同时设计师拿到原型进行UI设计--开始前端开发--测试bug--修正bug--重复n次--产品验收

以上只是一个大概的过程。 至少在前端，我们需要做的是梳理业务逻辑，理解业务逻辑。 这对你以后的开发很有用。 同时，您可以根据需要选择应用技术和划分项目结构。 需求模块的划分和完整项目的构建，当然还有很多自动化的构建工具可以为你节省很多时间。 现在的前端开发不再只是静态网页的开发。 千变万化的前端技术，使得前端代码的逻辑和交互效果越来越复杂，难以管理。 模块化的开发和预处理框架将项目分成若干个小模块，增加了最终发布的难度。 没有统一的标准，导致前端项目结构千奇百怪。 前端自动化搭建在整个项目开发中越来越重要，但是初学者还是要尝试一点一点的搭建一个项目。 当你多做几个项目的时候，你会发现每次都重复这个很烦人，所以你自然会进入，毕竟这会让你更深刻的理解为什么需要使用自动化构建...比如我们的main stack就是vue，最常用的是vue-cli。 Bower、Gulp、Grunt、node、yeoman等自动化工具有很多选择，我们应该根据自己的需要选择最适合自己研究的。

交流

前端是团队中最应该学会沟通的人。 如果接口有问题，需要和UI沟通。 如果数据有问题，需要跟后台沟通。 emmm心好累

通讯界面

前端是离用户最近的人。 用户对一个网站和软件最直观的感受都体现在前端。 也许你会说，最直观的不应该是UI设计师。 你要知道我是前端，我为设计师代言。 ！！！

在与UI的沟通中，我们在工作中不能被动的进行UI设计，而应该理性的提出自己的想法，否则以后的返工会浪费双方的时间。 比如我们刚来公司的时候，项目中的一些小图标的图片还是使用Sprite图片，但是很明显随着浏览器的支持越来越好，svg和font图标逐渐成为主流。 我在阿里巴巴的图标库里建了一个项目，把UI拉进来，UI直接把他用的图标加到项目里，前端直接从项目里生成字体图标导入到项目里。 绝对比慢慢切图，分离图标，合并雪碧图更简单，也更容易上手。 很酷，想换颜色就换颜色。 再比如，如果你需要做一个图表，使用echarts前端自动化构建工具，你完全可以让UI设计风格基于echarts，而不是让他在那里自由发挥，因为你永远不知道设计师脑子里有多少想法，所以节省这是两个人的时间，不会有他做得很好而你却达不到的尴尬。

通讯产品

一般来说，是程序员和产品经理之间最难的沟通。 只有相互残杀，没有爱情。 毕竟Zi曾经说过：“这个需求很简单，我不管怎么实现，明天上线！”，

这是lensuntop的一篇文章，我觉得写的很好

我记得一个笑话：

产品王：程序员前端自动化构建工具，急需实现吗？

程序员：请告诉我。

产品王：请根据手机壳的颜色来实现APP启动的颜色。

程序员已经被风吹乱了。 . .

从这段话中，多少能体现出产品与技术之间的各种激情“火花”。 产品经理眼中的简单需求，在我们看来是不可能实现的。 而程序员也无法理解为什么产品经理要实现这样的需求。 那么，站在程序员的角度，应该如何与产品经理沟通呢？

1、深刻理解需求，清楚了解需求的动机和原因

我们程序员一定会问为什么产品经理要在APP启动的时候根据手机壳的颜色动态实现APP的颜色。 既然要听分析，就不要急于发表自己的结论——技术上是不可能的！ 既然有疑惑，先解决自己的疑惑。

2.同理心

产品有产品角度。 作为程序员，我们在寻找什么？ 逻辑正确，更快，更容易扩展。 产品追求的是什么？ 老实说，我自己也没有深入思考过这个问题。 站在惯性的角度思考，可以想：一个产品为什么存在，它的存在能解决什么问题，它的用户体验好不好。 这些都是决定一个产品的核心价值。 毕竟工作的性质会影响一个人的思维逻辑，所以这个时候，我们站在产品的角度来思考每一个需求就显得尤为重要。

3.关注每一个细节

作为一名程序员，我必须深深地认同这句话。 因为标点符号或类型错误，它会导致意想不到的错误。 产品经理在设计产品的时候，总是从大的方向去思考问题。 只要大方向正确，细节就离不开大方向。 这就是他们的想法。 但是对于程序来说，绝对不能。 因为一个细节的逻辑往往决定了整体的方向。 例如：有一个要求，用户的作品需要提交审核，审核通过后才能让大家看到。 当产品经理把这个需求交给你的时候，你能发现什么问题吗？ 这里有几个细节： 1. 用户提交评论后，用户是否可以再次编辑作品； 2、作品是否会多次评审； 3.是否需要记录审阅历史； 4、用户的工作是否需要有版本控制，如果要生成版本，版本是如何生成的； 5、审核通过后，用户可以再次修改作品吗？ 如果没有，是不是其他人就看不到用户的作品了……毕竟，这只是一个简单的逻辑需求！ 但是涉及的细节太多了。 我们在编码的时候经常写不下来，因为给出的要求太模糊，没有详细到点子上。

4.“无法实现”的另一种说法

实现不了，我们都要经常说这句话。 但是直接告诉产品经理可能会把产品经理逼疯。 因为我们让他们觉得无论他们想要什么，我们都无法实现。 但事实并非如此，因为有条件不能实现，比如时间不够。 所以，首先要认同产品经理的观点（“可以实现”），然后提出他的需求实现的条件。 因为在现实中，产品经理并不总是愚蠢的，经常会提出一些不合理的要求，但是在需求面前，我们需要评估实现时间，而这个时间并不是那么容易准确预估的。

5、遇到不合理要求时，积极寻求替代方案

以段落中的需求为例，让我们提供几个APP皮肤供用户选择，这肯定比原来的需求更容易实现，也更人性化。 再说一个故事，有一家智能家居公司想实现厨房水龙头。 根据人声，水温可达几度。 换个角度想想，你能感觉到40度和45度水的温差吗？ 而从人声来看，这涉及到语音识别系统。 你想兼容多少种语言？ 其实我觉得左右切换还是挺聪明的，没必要弄的那么复杂。 所以程序员不得不寻找更好更简单的实现方式。 不要让产品经理想当然。

6.必须遵循文件精神

在开发过程中，我们经常与产品经理进行额外的详细讨论。 但是，我们没有在产品原型或需求列表中记录这次讨论的结果。 但是几个月后，我们往往会忘记我们最初讨论这个或那个细节的原因。 所以一切需求都要有根据。 另一方面，也保护了双方的利益。 不要等到出了问题，不知道是谁的责任，而在这方面，程序员往往吃了不少苦头。

7. 对你的节目有一颗艺术的心

有人说过，当需求影响到代码的可扩展性时，先切的是需求，而不是代码！ 在一定程度上，我同意这句话。 在我看来，程序是思想的产物。 要达到艺术的境界，必须在功能、体验和逻辑上做到合理。 就像一件艺术品，看起来很自然！ 因为一个看起来“丑”的作品，一定是不符合人的逻辑和习惯的。

写到最后，感觉又回到了程序员本身。 其实和产品经理沟通，最重要的是要明白：我们是在解决问题，而不是在制造问题！有了这个核心，一切问题都迎刃而解

一般来说，跟后台沟通没有那么麻烦。 约定好规则之后，一般来说，你们通过API进行通信，但是当你调试接口的时候，出现了一些不明所以的东西，感觉不是你的问题。 与后台沟通是最明智的。

职责分工

这点相信大家都深有感触，因为前端是最后一关，所有的需求都在前端手中变成了具体的产品，让你很容易成为后援人，导致项目失败。 延迟有很多种，比如设计图纸不及时、后台数据有问题、产品需求临时变更等。 如果你不能证明是这些问题导致了项目延期，你肯定会责怪自己。 唯一的办法就是——à口头确认——à发邮件给负责人确认——à通知上级，别觉得这很麻烦，出了问题会比这更麻烦，

写不下去了，以上是个人爬坑后对前端的理解（ps：虽然还在坑里），也算是对自己工作的一个总结吧。 2018升职加薪，找女朋友！！！

结尾

觉得这篇文章对您有帮助？请分享给更多的人

关注《前端百科全书》，提升前端技能