前言：工具是次要的。
前言：但是，我们不能放弃追逐好的工具。
前言：而且，我们要勇于抛弃陈旧的工具。
一入前端海，就要找工具。
像HBuilder之流的，就不考虑了。（不买情怀流的帐）
第一时间装了Jetbrains家的WebStorm。
然而用着用着，我就想：为什么我要用它？
其实应该拥抱变化的，为什么就一定要用重型的IDE呢？基本上主流前端工程师都是用文本编辑器+插件的，我为啥不能花这种学习成本呢？各种鸡汤曾灌输我们说：从舒适区里跳出来才能获得成长，不是吗？
那好，从最主流的Sublime、atom、VS Code里面选吧。
- Sublime：老牌。py语言开发的。时光倒流3年我就用它了（当然当时也确实用的它）。强力的插件库。
- VS Code：确实在某视频中见过前端大神在MAC系统里用过这货，也用的挺好，但是微软的东西总让人感觉硬不起来。也许是它名字起的不好吧。
- Atom：插件的强力程度大于等于Sublime。然而，github出品，并且是用nodejs写的。虽然我不会nodejs，但是我就是喜欢nodejs。那么，就它了。
Atom Zhuangbility 流程记录 and gezhong Fly with 插件
好不好用这个问题，自然是谁用谁知道。如果用了发现不好用：要更努力用它，适应它，进而更深度地使用它，然后批判它。
在JS中跳来跳去【同时需要安装 hyperclick插件】
在开发工具中打开命令行，不知道是不是一个好的习惯。如果是，请使用这个插件
格式化代码【用来用去，目前还是webstorm的格式化代码最舒服】
P.S.【2017.08.16补充】弃坑提示：atom的终端（命令行/控制台）插件并不好用。第二名的终端插件直接安不上，第一名的插件终端启动系统后，浏览器中的react开发warning提示没有，而且无法在浏览器中使用redux devtools插件。
规避方式：可以在其他工具中启动系统，不必非得使用atom的控制台插件启动，对日常开发影响不是很大。但是总的来说，atom中开发前端个人感觉还是比在jetbrains家族中舒服一些的。
有了工具，就可以读代码了
editorconfig：有的工程提供了这个文件，我不知道是有意的还是不小心将自动生成的配置文件提交上来了。总的来说，editorconfig约定了编辑器/IDE在这个工程中的一些个性化配置。我们要走读的开源工程中也有这个配置文件，就不展开解读了。
webpack.config.js使用了atool-build扩展，也有可能是dora封装的。鄙人能力有限，因此这个文件就先不展开解读了。基本上是一些less的配置，比较常规吧。
其他读代码部分请见其他文章。本篇主题是说工具。
关于部署
之前我对部署这块认识应该是有个误区。误区是什么就不说了，省的误导别人。
总之：
- 开发时，开一个调试服务就行，不用启动后端，只把前端拉起来就行。数据部分proxy也好，mock也好，开发阶段是真正的前后分离的。
- 部署时，合并部署。一套服务起来，既有前端也有后端。因此，主流实践是前端工程放到整个系统工程目录的frontend目录中。前端人员开发时，只关心这个目录就行。前端build的时候，输出目标文件到整个工程的target目录中去。然后后端工程已启动整个就拉起来了。
因此，在开发阶段和部署阶段，对于工具的选择也可以不同。例如：后端或者整个工程使用idea，前端工程使用atom。
关于开发调试
两个chrome插件一定要装：
- redux devtools。在roadhog的dev模式下可以直接看redux相关的。比如当前state、比如action调用。
- jetbrains IDE Support，可以在intellij或者webstorm中启动JavaScript debug，直接就可以在ide中打断点了。
