本文仅用于学习和交流目的,不得用于商业目的。非商业转载请注明作译者、出处,并保留本文的原始链接:http://www.ituring.com.cn/art...
访谈嘉宾:
Nicolas Bevacqua,阿根廷人,是一位富有激情的JavaScript工程师,热衷于打造健壮的构建流程和清晰的应用架构。喜欢谈论关于JavaScript、性能、可维护代码和开放互联网的所有内容,曾多次在技术大会上发表web性能、ES6方面的知识分享。
2017年6月24日,Nicolas作为重量级嘉宾参加了“腾讯web前端大会”,分享《JavaScript的未来编写方式》并参加图书签售活动。
访谈实录:
什么时候开始编程的?
大概10岁的时候,我上过一些学习Flash的课,也做些网站但纯属是为了乐趣。到了高中的时候,我开始做一些更有趣的项目,比如玩一款多人在线的角色扮演游戏——网络创世纪。运行自己开发的服务器,实现游戏的特征。这段时间里,我学会了C#。大概做了两年的时候,一个朋友告诉我“嘿,人们是愿意花钱让你做这些事情的。”这对于我来说太酷啦!是的,我想,这就是我如何开始编程的。
你有没有想过,把爱好变成职业以后,会破坏爱好带来的那份乐趣?
不,恰恰相反。我从来没有觉得它是某种工作。我也不会因为把爱好变成了工作,就不再享受这份爱好。做自己喜欢的工作,这一点很重要。只有这样,你工作的时候才不会感到痛苦。
所在居住地的技术圈是什么样子的?
五年前的技术社群要小得多。不过,现在我们有了Node.js大会、有了JS大会等,确实在慢慢变大。我所联合创办的Node.js大会是去年开始的。今年,我们依然会组织。我们希望把它变成一个定期举办的大会,人们才可以更多地参与到技术社区,而不仅仅是每年来那么一次,然后就完全忘了。
JavaScript中有很多的框架。如何才能跟上趋势,不被技术落下?
我们谈话的这个时候,可能就有一个框架出现。重要的是,我们的主要任务不是跟随那些耀眼的事物,而是更多地了解趋势,什么是对我有用的、有帮助的。
如果两年前开始的一个项目还在使用Angular,我就不需要认为Angular比React落后,Angular肯定会糟糕一些。是否使用某个框架取决于你的要求,总是去追求最新的技术是件很危险的事情。在一段时间内坚持使用同一种工具,讲究工具的一致性是很有价值的。
此外,不被新技术落下也是很重要的。你可以,但是不建议你还在使用jQuery和HTML做网站。
关键是找到合适的平衡点。不断丰富自己的知识,如果有时间就去尝试一下。千万不要因为是新技术就盲目尝试。
你能按照时间顺序给我们提供一些JavaScript的学习建议吗?
首先,要弄清楚你适合哪种学习方式。有些人喜欢看知识截屏或者视频演讲。对于我来说,我在视觉学习方面的能力很差劲。我需要自己研读。如果让我看一段视频,我会想要了解任何一种细节性的知识,反反复复看四遍。换做一本书或是一篇文章,我就可以很快掌握。我想说的是,你应该弄清楚自己是一个视觉型学习者,还是喜欢文本型内容的学习者。
然后,你就可以开始真正地学习JavaScript的基础知识:句法、语法,等等。有了坚实的基础,你就应该进入ES6的学习,掌握些特征。与此同时,你可能专注于某个单一的框架,Angular或者React或者其他任何一个框架,但一定要做到精通。你可以阅读所有的文档并浏览文件直到完全了解它的工作原理。
我用自己编写的框架来学习事物是如何工作的。这是一个相当有效的方法,可以验证些东西、编写些技术工具。如果非要推荐一种学习资源,它应该是https://12factor.net。这是一个网站,它列出了从安全性、可扩展性等方面出发的12种不同的应用程序设计原则。我认为,人们应该了解它。
目前,你正在编写《模块化的JavaScript》系列图书。为什么会关注模块化?
早期的时候,JavaScript基本上就是复制粘贴“如何做”。人们在网上找到一些代码片段,复制粘贴到他们的网站,然后结束一天的工作。随着语言的发展,这种情况将不再适用。
人们变得更加专业,开始开发一些JavaScript应用程序。现在的JavaScript应用程序中有很多的模块。起初,这些模块都是相当大的。现在,编写小模块变得简单得多。
在我的系列丛书中,我试着教大家如何编写出简洁的、单目的模块。原因是,人们希望编写出专业的模块,这样就可以重复使用、测试,甚至在需要的时候给它提供官方文档。最重要的是保证架构方面的可扩展性。当你有5个不同的模块,每个模块有5000行代码的时候,事情会很难处理。如果你有5000个模块,每一个都是100行的代码长度,那么这就简单多了。
本系列主要讨论如何获得这些高度模块化的应用程序。这一系列内的后续图书会讨论测试及部署等内容。
How did you get started in programming?
When I was around 10, I had some classes using Flash. Also, I made websites for fun. In high school, I did a couple of more interesting projects, like playing the game called Ultima Online. I used to run my own server and implement features for the game. That's how I learned C#.
After doing that for 2 years, a friend told me, “Hey, people actually pay you to do this.” It's too cool to get paid. Yeah, that's I guess how I begin.
Have you ever thought that turning love of role-playing games into a career will spoil your fun?
No, it's the other way around. I never felt it like work to me. I would also never fall out of love with hobbies because I'm doing it for work. But it's important to work on something you like. Then it won't feel like torture when you’re doing it for days.
What does the tech community of your living place look like?
It's much smaller 5 years ago. Nowadays, we have Node.js Conf, JS Conf and so on. It's definitely growing. Node.js Conf started last year. This year, we will still run it. We plan to make it a regular thing so that people could engage more with the community, not just coming to this event once a year and then completely forget it.
There are lots of frameworks in JavaScript. How to keep up with the state?
There's probably a framework coming out right now as we speak. The important thing is to know that the theme is not to follow those shiny stuffs. It’s more about figuring out the trends, what's useful and helpful for me.
If I started one project 2 years ago, it's still using Angular. I don’t really need to feel that Angular is a little bit lower than React and it must be worse. It depends always on your requirements. It's very dangerous to go after the newest thing. The consistency of using the same tool for a while is valuable.
Also, it's important to not be fallen behind. You can, but it’s not advisable to be still using jQuery or HTML for websites.
It's about finding the right balance. Stay informed but try them if you have time. Be sure not to jump into everything just because it is.
Could you give us some learning steps of JavaScript in chronological order?
It's really important to figure out how you learn things best. Some people love to read screen cuts or videos. I'm really bad at learning anything that I see. I need to read it. If I watched a video, I want to understand anything until I go over it like 4 times. When I read a book or article, I could get it. What I'm trying to say is that you should figure out whether you are a visual learner or if you prefer written contents.
Then you could start to really understand the basics of JavaScript: syntax, grammar, etc. Once you have a solid foundation, you should move into ES6 and learn features. At the same time, you might focus on a single framework, Angular or React, but be sure to be specialized on that. You could read all its documentations and browse files to figure out how it works.
I implemented my own frameworks to learn how things work. I think it's an effective way to experiment and build things for yourself. If there were one source I would recommend, it should be https://12factor.net , which is a website that lays out 12 different principles for robust application design in terms of anything from security, scalability, etc. I think people should know it.
Currently, you are writing the Modular JavaScript book series. Why do you focus on modularity?
In the early days, JavaScript was basically on copy paste of "HOW". People find snippets of code on the internet that would give them comments for websites. They go to copy paste them into their site and call it a day. As the language developed, the case will not match any more.
People become to be more professional and started developing JavaScript applications. Now, JavaScript applications have lots of modules. At first, those were pretty big modules. It's now much simpler to write small modules.
In my book series, I'm trying to teach people how to write concise and single-purpose modules. The reason is that people want modules to be specialized so that they can reuse them, test them, and even document them if needed. But the most important thing is scalability in terms of architecture. When you have 5 different modules, each one with 5,000 lines of code, it would be really hard to work with them. If you have 5,000 modules and each is 100 lines of code in length, it's much easier.
The series basically discuss how to obtain these highly modular applications. Then the later books in the series will talk about Test and Deployment.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。