怎样成为大家口中的「好前端」？

会员服务 ·

怎样成为大家口中的「好前端」？

2017 年 12 月 10 日 前端大全

（点击上方蓝字，快速关注我们）

来源：饿了么前端/Galen
https://zhuanlan.zhihu.com/p/28275428

本文不是讲技术的，也没什么代码可看！

被「误解」的前端开发

不知道从什么时候开始，大家对一个前端工程师的评价变成了一种很规范化东西：

会用 Angular/React/Vue？
掌握 Webpack/Rollup/Gulp？
用过 Postcss/Sass/Less?

请问，上面这些工具能确认一个前端工程师是不是一个好前端么？我的答案是：不能。

上面这些畸形的判定标准也对很多初学者造成了很大的误导：

我学会 Vue 是不是就能找到工作啦？
我刚入门前端开发，是不是该学 React 啊？
明天去面试，今晚背背 Angular 的 API 吧。

那么究竟怎样才能成为大家口中所说的「好前端」呢？

不要让工具成为衡量你能力的标准

工具是什么？

对于开发者而言，工具应该是提高你工作效率的东西，用各种各样的工具来提高开发效率是应该的，但对工具过分依赖甚至离开了工具就不能进行开发是万万不可的。

比如 Vue 帮助你实现了数据驱动页面，你自己就不能通过 DOM 操作来改变页面的状态了么？当然不是，DOM 操作作为前端开发的基础知识，是每一个前端工程师都应该熟练掌握的东西。

我该不该用这个工具？

众所周知，前端行业的轮子满天飞，每隔几天就会出来一个新轮子，新陈代谢贼快，作为开发者我们很多时候也会面临一个难题：“我要不要用这个轮子？”。面对这个问题，我一般会问自己三个问题：

这个东西是干嘛的？ 这个问题其实很简单，在引入任何工具之前，一定要搞清楚它是干嘛的，核心功能是什么，这样才能确保在项目中正确地使用并收获预期的收益。
它解决了什么问题？ 我认为，任何工具的引入都应该解决了现阶段的开发痛点，比如 Vue 可以帮助你通过数据来驱动页面、Babel 能帮你享受 ES6 带来的语法糖。如果引入一个工具没有帮你解决开发过程中的任何痛点，那你应该仔细考虑一下是否真的需要它。
我为什么需要它？ 这个问题其实是前两个问题的综合命题，即引入任何工具都应该是带有一定目的性的，就好像我想在项目中使用 ES6 语法，所以我引入了 Babel，如果它达不到你的预期目的，那么你并不一定真的需要它。

当然，除了上面几点还有很多细节需要考虑，比如稳定性、社区活跃度、团队成员接纳程度等等，至于具体在什么样的场景下应该选择什么样的工具，相信各位心中都会有一杆称。

纸上得来终觉浅

众所周知程序员是一个需要学习能力的职业，我们需要不断地学习才能保持让自己不因技术的革新而落伍，而知识的获取渠道也有很多，像技术博客、技术文章、书籍、文档等等，那么问题来了，你看了那么多的东西就真的收获了那么多知识么？

你获取的是「知识」还是「文字」？

身边有个朋友，处于刚入门的级别，问我看什么书能巩固 JavaScript 基础，我就向他推荐了《You Dont Know JavaScript》系列，他看得很快也很认真，基本上每看完一块内容都会来跟我讨论一下，大概两周就把上中两册看完了。

然而过了不久他问了我这样一个问题（大概描述）：

var count = 0

function foo () {

this.count++

}

foo.count = 0

for (var i = 0; i < 5; i++) {

foo()

}

“为啥我跑完这样一段代码后外层的 count 是 5，而 foo.count 却还是 0？this 不应该指向 foo 么？”

我当时一愣，因为我记得《You Dont Know JavaScript》里在写 this 的部分单独举过这种例子，这位仁兄看的那么仔细居然不知道？对此他的回答是“忘了”。这时我就猜到了他只是把这本书当成了一个睡前读物，草草读一遍也就过去了。所以我给他的建议是：回头重读一次，用心看每一段 demo 的代码，如果与你已知的知识不同或你干脆就不知道这些东西，就动手写一写，在搞明白为什么这么写是可以的之前不要看别的东西。

实践出真知，搞技术不是写论文，不要只看理论知识，实际操作中的理解要比看书上干巴巴的文字深的多得多得多。搞技术切忌纸上谈兵，做不到实际的落地都白扯。

怎样把得到知识变成生产力？

当然光有满腹学识也不够，你还要把它转换为实际的生产力投放到日常的工作中，这就需要你把知识用「活」。至于怎样才能真正用活知识，我也没什么资格下定论，因为我自己做的也不怎么样，只能在此提醒大家：基础的东西就那么多，把东西用活，变着花样地弥补不足才是王道。