Open chenxiaochun opened 6 years ago
作为一名软件开发者，我们基本上都是靠技术吃饭。因此，我又经常说自己就是一名手艺人，就是靠这点儿手艺吃饭。
前端开发作为软件开发的一个分支领域，目前的发展状态与我国正在经历的改革开放非常类似，未来的目标一定是更加开发、繁荣。
很多技术初级者遇到问题，一般就是唉声叹气的怀疑人生😩，然后去百度上随便搜索一坨代码粘下来碰碰运气，不好用再去找。但是，你会发现身边的技术大拿一般不会这么做，他们之所以是大拿，除了天分，运气之外，很大程度上就是靠个人持续不断的钻研努力。他们也是从一个技术菜鸟过渡过来的，遇到问题，他们不会叹气，不会怀疑人生，而是提神屏气，擦亮眼睛，用理智的头脑去思考问题发生的背后逻辑究竟是什么。
软件开发是一门计算机科学技术，要做到理智的分析问题，就要有比较牢固的基础知识。前端发展的再快，也终究离不开我们众所周知的那些基础技术，比如说：html、css、js、svg、http协议、算法等。即使是现在风靡前端圈的 Vue 和 React，也万变不离这些『宗』。当然，目前又衍生出了另一条重要的技术分支：WebAssembly。
所以，这些基础技术才是我们应该花最大精力去钻研的东西。只有掌握了这些基础技术，未来在面对任何衍生出来的框架或者类库时，才能做到闲庭信步中就可以掌握其框架用法。
个人认为，未来前端技术一定是朝着更符合 w3c 标准规范，更易于团队协作，更易于代码开发维护的方向发展。
恐惧源于内心的不自信和对未知事物的不了解。
学习一门技术，最好是阅读它的官方文档。因为作者才是最了解这门技术的人，他自己写出来的文档才有可能通俗易懂、面面俱到。虽然不排除有些作者书写的文档确实是比较晦涩，但他们之所以能成为这个行业里的翘楚，除了有很高的技术造诣之外，就是也有非常良好的文字表达能力。
回想自己若干年前，也比较恐惧阅读英文文档，每次搜索一个问题点开是英文界面的时候，立马就会关掉，生怕它好像会扑过来咬我似的。但是，你必须硬着头皮读下去，耐心的慢慢去理解文章的意思。再后来随着阅读 stackoverflow 上的问题答案，随着翻译了几篇英文技术文章之后，这种恐惧心理就逐渐逐渐的消失了。
因此，为了训练自己阅读英文和书写表达的能力，我最近在翻译一本关于 js 的英文小册子（exploring-es2016-es2017），章节不多，但是有的篇幅确是很长。不为别的，更多是为了给自己看吧。
阅读英文资料时，一定会遇到生僻的单词，所以装一个能即时翻译的工具很重要，这个就很多了。无论是电脑客户端，还是 chrome 插件装一个自己喜欢用的就好。
麻烦的就是碰到那些加了若干转折的英文长句，这种长句你如果用工具直接翻译，一般翻译出来的结果会和原文意思大相径庭。这个怎么办？除了依靠你自己的英文功底之外，就是再重新阅读这个长句的上下文，根据上下文的表达意思和那个不靠谱的翻译结果，尽量猜出它是什么意思，这个过程有可能会持续数分钟之久，但是一旦理解出来，你就会有一种浑身舒畅，打通任督二脉的快感。
有的同学会说，有那么一两句不理解直接跳过去也无妨。我对这种观点是既同意，也不同意。之所以这么说，得看你当时的场景，你如果正在非常着急的解决一个技术问题，那么只要读懂能解决自己问题的那部分即可，剩下的可以以后慢慢读。但是如果你像我一样，有时候就是为了训练自己的英文阅读能力和表达能力，我还是建议你最好把每一句的意思都弄明白。
最后，前端开发的英文资料中出现的生僻词一般就是那几十个，或者不超过几百个吧。搞明白，并且记住它们，并不是一件多么困难的事情。所以，英文特别好的同学请直接忽略我这种土办法哈。😳
遇到问题请使用 google 搜索（科学上网的问题请自己想办法）。如果用中文关键字找不到匹配的内容，那么就换成几个英文关键词再试试。通常来说，只要你遇到的问题，别人也一定曾经遇到过，而且一般来说只要搜索到 stackoverflow 上就有答案了，所以才诞生了下面这本书吧。😅
如果是我们平时用到的一些开源包出了问题，我有时候就是直接打开此开源包的 issues 列表，尝试轮换着用几个英文关键字搜索一下，看别人是不是已经提出过类似的问题了。如果没有找到相关的 issue，并且使用 google 也找不到满意的答案，那你就可以给此开源包的作者提一个新的 issue 了。
提问题也是一个技术活。我发现，这几年通过网上一些有影响力技术牛人的教育，很多人已经逐渐的学会了如何进行提问。我个人觉得提问题还是应该注意以下几点：
很多作者开发的工具，完全是利用自己的业余时间搞出来的（当然，也有很多是大公司造的轮子）。他们可能没有从这个工具上面获得过任何经济上的收益。所以不要觉得白用了人家的成果，出了问题，还要摆出一幅大爷的样子，好像对方解决不了你的问题，就对不起你似的。
不管提任何问题，我觉得都要充分尊重作者的习惯。例如，有的作者为了使问题描述的更清楚，预置了一个 issue 的书写格式，这个时候，不要发挥自己的个性，请充分遵循作者提供的规范，按照人家的格式老老实实的写清楚自己的问题。
最后，不要忘了感谢作者。不管对方是哪个国籍，都应该说一句：Thank you very much🚀。
纸上得来终觉浅，绝知此事要躬行 —— 陆游（宋）
学习一门新技能，切忌眼动手不动。你只是看一遍，基本上什么也记不住（而且可能很快就睡着了）😴。强烈建议你照着作者提供的示例，自己搭环境手动敲一遍，你会碰到很多光是凭看发现不了的问题，比如：
作为一名软件开发者，我们基本上都是靠技术吃饭。因此，我又经常说自己就是一名手艺人，就是靠这点儿手艺吃饭。
前端开发作为软件开发的一个分支领域，目前的发展状态与我国正在经历的改革开放非常类似，未来的目标一定是更加开发、繁荣。
很多技术初级者遇到问题，一般就是唉声叹气的怀疑人生😩，然后去百度上随便搜索一坨代码粘下来碰碰运气，不好用再去找。但是，你会发现身边的技术大拿一般不会这么做，他们之所以是大拿，除了天分，运气之外，很大程度上就是靠个人持续不断的钻研努力。他们也是从一个技术菜鸟过渡过来的，遇到问题，他们不会叹气，不会怀疑人生，而是提神屏气，擦亮眼睛，用理智的头脑去思考问题发生的背后逻辑究竟是什么。
万变不离其宗
软件开发是一门计算机科学技术，要做到理智的分析问题，就要有比较牢固的基础知识。前端发展的再快，也终究离不开我们众所周知的那些基础技术，比如说：html、css、js、svg、http协议、算法等。即使是现在风靡前端圈的 Vue 和 React，也万变不离这些『宗』。当然，目前又衍生出了另一条重要的技术分支：WebAssembly。
所以，这些基础技术才是我们应该花最大精力去钻研的东西。只有掌握了这些基础技术，未来在面对任何衍生出来的框架或者类库时，才能做到闲庭信步中就可以掌握其框架用法。
个人认为，未来前端技术一定是朝着更符合 w3c 标准规范，更易于团队协作，更易于代码开发维护的方向发展。
克服恐惧心理
恐惧源于内心的不自信和对未知事物的不了解。
阅读英文文档
学习一门技术，最好是阅读它的官方文档。因为作者才是最了解这门技术的人，他自己写出来的文档才有可能通俗易懂、面面俱到。虽然不排除有些作者书写的文档确实是比较晦涩，但他们之所以能成为这个行业里的翘楚，除了有很高的技术造诣之外，就是也有非常良好的文字表达能力。
回想自己若干年前，也比较恐惧阅读英文文档，每次搜索一个问题点开是英文界面的时候，立马就会关掉，生怕它好像会扑过来咬我似的。但是，你必须硬着头皮读下去，耐心的慢慢去理解文章的意思。再后来随着阅读 stackoverflow 上的问题答案，随着翻译了几篇英文技术文章之后，这种恐惧心理就逐渐逐渐的消失了。
因此，为了训练自己阅读英文和书写表达的能力，我最近在翻译一本关于 js 的英文小册子（exploring-es2016-es2017），章节不多，但是有的篇幅确是很长。不为别的，更多是为了给自己看吧。
阅读英文资料时，一定会遇到生僻的单词，所以装一个能即时翻译的工具很重要，这个就很多了。无论是电脑客户端，还是 chrome 插件装一个自己喜欢用的就好。
麻烦的就是碰到那些加了若干转折的英文长句，这种长句你如果用工具直接翻译，一般翻译出来的结果会和原文意思大相径庭。这个怎么办？除了依靠你自己的英文功底之外，就是再重新阅读这个长句的上下文，根据上下文的表达意思和那个不靠谱的翻译结果，尽量猜出它是什么意思，这个过程有可能会持续数分钟之久，但是一旦理解出来，你就会有一种浑身舒畅，打通任督二脉的快感。
有的同学会说，有那么一两句不理解直接跳过去也无妨。我对这种观点是既同意，也不同意。之所以这么说，得看你当时的场景，你如果正在非常着急的解决一个技术问题，那么只要读懂能解决自己问题的那部分即可，剩下的可以以后慢慢读。但是如果你像我一样，有时候就是为了训练自己的英文阅读能力和表达能力，我还是建议你最好把每一句的意思都弄明白。
最后，前端开发的英文资料中出现的生僻词一般就是那几十个，或者不超过几百个吧。搞明白，并且记住它们，并不是一件多么困难的事情。所以，英文特别好的同学请直接忽略我这种土办法哈。😳
请使用 google 搜索
遇到问题请使用 google 搜索（科学上网的问题请自己想办法）。如果用中文关键字找不到匹配的内容，那么就换成几个英文关键词再试试。通常来说，只要你遇到的问题，别人也一定曾经遇到过，而且一般来说只要搜索到 stackoverflow 上就有答案了，所以才诞生了下面这本书吧。😅
如果是我们平时用到的一些开源包出了问题，我有时候就是直接打开此开源包的 issues 列表，尝试轮换着用几个英文关键字搜索一下，看别人是不是已经提出过类似的问题了。如果没有找到相关的 issue，并且使用 google 也找不到满意的答案，那你就可以给此开源包的作者提一个新的 issue 了。
提问题也是一个技术活。我发现，这几年通过网上一些有影响力技术牛人的教育，很多人已经逐渐的学会了如何进行提问。我个人觉得提问题还是应该注意以下几点：
1. 尽量描述清楚自己的问题，包括但不限于：
2. 作者不欠你任何东西
很多作者开发的工具，完全是利用自己的业余时间搞出来的（当然，也有很多是大公司造的轮子）。他们可能没有从这个工具上面获得过任何经济上的收益。所以不要觉得白用了人家的成果，出了问题，还要摆出一幅大爷的样子，好像对方解决不了你的问题，就对不起你似的。
不管提任何问题，我觉得都要充分尊重作者的习惯。例如，有的作者为了使问题描述的更清楚，预置了一个 issue 的书写格式，这个时候，不要发挥自己的个性，请充分遵循作者提供的规范，按照人家的格式老老实实的写清楚自己的问题。
最后，不要忘了感谢作者。不管对方是哪个国籍，都应该说一句：Thank you very much🚀。
实践，实践，再实践
学习一门新技能，切忌眼动手不动。你只是看一遍，基本上什么也记不住（而且可能很快就睡着了）😴。强烈建议你照着作者提供的示例，自己搭环境手动敲一遍，你会碰到很多光是凭看发现不了的问题，比如：