2016 年总结
2016 年总来的来说还是有所收获的吧。有很多可以说的，但是有觉得没什么营养。写不出高山，那就流水般地写着吧。
CoffeeScript
CoffeeScript 是工作以来，第一个 javascript 的方言吧，更多的是语法糖吧。coffee 可以让你在编写程序时，少入一些坑(由 javascript 语言本身导致的)，而且编写的代码少，兼容性好(因为 coffee 最好是编译成 es3 的)，开发效率高。我记得百度音乐的播放器应该是用 coffee 写的，Atom 编辑器也是用 coffee 写的。感兴趣的可以看看 spine 这个项目，你会发现 coffee 的代码原来可以写的这么优美。
但是现在，已经慢慢地转到 es6 了，coffee 的很多语法糖，es6 也基本上实现了。毕竟 es 标准也是 js 的大趋势，还是不能逆势而为。github 上的库基本上也是 es6 的源码，不去看看 es6 的话，你看源码还真的是不习惯。
今年 coffee2 应该出了吧，到时候第一时间去尝尝鲜，对 coffee 也是有一种情愫。
Webpack
webpack 接触的还算是早吧，大概是 2015年9月份的样子。之前实习的时候，还有老项目用的是 ant，当时表示很吃惊。后面用 grunt、gulp、browserify，到后来的 webpack，了解过 rollup，但没有去使用过。现在平常都是用 webpack，有时候也用用 gulp。这些构建工具的优缺点，网上对比分析也是很多的。中间也有去尝试 happypack，但是它对很多 loader 的兼容性很差，实际项目中，也是很难使用。
Editor VS IDE
说起编辑器或者是 IDE，我真的是折腾过不少。最开始的时候，用的是 Sublime Text，很漂亮，也很强大。后面又换成 WebStorm，真的是很强大，但是这个编辑器太重了，而且那一套快捷键真的习惯不了。后面就换成了 Atom，界面也很漂亮，就是插件多起来，启动很慢，而且编辑、保存的时候很卡。然后换成了 Vim，编辑器之神，自己也配置了很多插件，功能也很强大。后面换成了 Spacemacs，这个是基于 Emacs 做的一个编辑器，我承认我是被它的优美的界面吸引的。后来小试了一下 vscode，各方面都不错，就是界面有点丑。
主要讲讲这些 Editor/IDE 的优缺点吧。
Sublime Text：界面漂亮，快捷键设计的很好，不清楚的功能，有一个统一的入口，记住关键字就可以了，多使用几遍，快捷键就记住了。打开速度比较快，编辑、保存的速度很快。可以自己定义很多补全、常有代码块啊、自定义自己的snippet，也有多光标，编写效率也是杠杠的。插件也很齐全，唯一的缺点就是在卸载插件的时候，卸载不干净。
Atom：号称新一代编辑器，确实不错，也是借鉴 ST 的有点吧，所有的功能都有一个统一的入口，我觉得这一点真的是现在编辑器必须要有的。Sublime Text 有的，它应该都有吧。缺点就是打开大文件，卡。打开大项目的时候，也是卡。弃用的主要原因。
WebStorm：功能强大，自带版本管理工具。补全做的相当好，代码跳转，进入函数真的是很有用的。而且可以很方便地调试 node，很赞，就是太重。其他几个都只能说是 Editor，这个就是一个 IDE。
Vim：编辑器之神。打开文件最快，编辑、保存都非常快。天下武功，为快不破。其几种模式，保证了 VIM 功能和效率的强大。默认是不支持多光标，但是有命令模式，还需要多光标吗?! 也有插件使其支持多光标，无非是 visual 而已。自定义 snippet，配置快捷键，快的飞起，游走于 buffer、window、tab 之中，完全不需要鼠标。缺点就是打开长行文件，比如压缩后的 js 代码。另外打开大文件的时候，一定要配置关闭高亮等其他非必须的功能，不然编辑、保存会卡。
Spacemacs：其实就是美化后的 emacs(神之编辑器)。Vim 不要喷我，我是被外表吸引的，但是我还是用 Spacemacs 的 vim 模式编辑文件的。Emacs 不如 Vim 被广大程序员使用，可能更多的是因为其快捷键，真的是......😂。但是 Spacemacs 美化了 Emacs 的外表，对其快捷键进行了梳理，基本上不需要怎么记忆。另外就是使用了很强大的插件就 Vim 引入了 Emacs，简直就是屠龙倚天在手。为什么说 Emacs 是神之编辑器呢？我个人是觉得，是因为其功能强大吧。因为 Emacs 就是伪装成编辑器的操作系统，在 Emacs 中，你可以编辑、浏览网页、看电影、...
VSCode：微软出品，必属精品(除了 Windows 操作系统)。毕竟一个软件公司，做一个编辑器对他们来说，小 case。打开文件速度慢于 Sublime Text，快于 Atom。代码补全很强大。编辑、保存很快。缺点就是快捷键不习惯、界面丑吧。
Functional Programming
打开我去了解函数式编程大门的就是 Redux，写 React 的都应该知道吧。
高阶函数，可以让你对代码更加抽象。
延时执行也是其一个特性。前几天还听到一句话，想快的话，先想慢，想想哪些是可以慢的，于是延时加载、异步加载等等优化手段就出来了。
无副作用，函数式的编程，保证了相同的输入得到相当的输出，避免一些无法预知的问题。
λ 演算，函数式编程的基础。函数式编程越来越被推崇，但是 λ 演算、Y 组合因子的作用倒不是很重要吧。但是在函数式编程中，很多时候是使用匿名函数的，那么这个时候 Y 组合因子的作用就体现出来了，我们需要递归条用这个匿名函数的时候怎么办。Y 组合因子就是来解决这个问题的。思路就是我们先假设这个匿名函数为 f，然后把这个匿名函数当参数传给一个函数，进行使用。Y 组合因子就是求解这个匿名函数以及调用关系的。具体地可以看看这一系列的文章。
React
前端现在真的是百花齐放，目前大行其道的应该就是 React 和 Vue 吧。Vue 没有去尝试过，React 一直在用的，我们团队很早的时候就开始 React，并开始使用前后端同构的方式，同构的好处，网上有很多总结分析，此处就不罗嗦了，很明显的感觉就是首次加载的速度真的是快很多。
说说我自己对 React 的一些浅显的想法吧。React 的思想，个人是觉得是采用了有限状态机的思路。之前学习《计算导论》的时候，觉得真的是很难，注意不是计算机导论，前者是计算机系统比较偏底层的一些理论，如何证明 NP 问题、NP-hard 问题；后者只是一些计算机入门的知识。
在计算导论里面，讲到了有限状态机，状态机状态分析也是很复杂的。有兴趣的可以去网上找找资料。
React 组建中 state 的变化就引发了状态变化，导致 UI 变化，采用申明式的编程，个人觉得带来的好处就是我们定义好每一种状态对应的情况，所有的变化都是引发相应的变化，使得程序更可控。组件化，又使得我们每个组件之关注自身 care 的状态，有效地降低了整个系统的复杂性，增加组建内部的聚合性。只依赖数据状态，也降低了组件间的耦合性。
组件思想很很符合，生活中的哲学思想吧。就像一个大企业，老板不可能关系所有的事情，把不同的事情交给不同的主管，主管在把不同的员工去负责。父组件将不同的数据给不同的子组件，子组件再可以根据其实际情况进行拆分。小公司没有层级很深的等级划分是没有问题的，大公司人数众多，不划分根本是没有办法管理的。
React 使得我们在编写程序时，不用关系组件 A对组件 B会造成什么影响。比如说，我们编写一个类似网易云音乐的播放软件时，一个标识歌曲是否播放的数据变量 isPlaying。碟盘转动的组件依赖 isPlaying 变量，true 就转动，false 就停止。歌词滚动播放的组件也依赖这个变量。当我们点击暂停键的时候，暂停键通过改变 isPlaying 的值，改变其状态，而依赖这个变量的组件就会更新其状态，进而更新其 UI，状态触发其行为。将组件中间的耦合性转化到对数据状态的耦合，组件在编写的时候，只需要考虑自己的依赖。
如何不采用这种模式的化，可能就是暂停键点击了暂停时，调用碟盘转动组件来暂停转动，调用歌词组件来暂停歌词的滚动。如果后面功能复杂起来，那么暂停键的业务会越来越复杂。
当然还可以才用观察者模式，采用这种方式编写的化，会存在一个问题。就是事件的 bind 、unbind 以及事件的命名空间问题，因为当事件多了，必须采用命名空间来触发和屏蔽一些事件。本应该所有的变化依赖数据和状态，编程了都依赖于事件，而事件本身又传递数据，其实增加了组件和事件的耦合性。
事件应该作为一个改变状态数据的方式和传递状态数据工具。事件去关系数据的变化，然后通知给其他组件。这样做的化，组件之和状态数据偶性，不用去和事件耦合了，不是更低的耦合性吗？！
Redux
React 状态机思想，就牵扯到状态数据的流向。单向数据流慢慢地更多接受，因为单向数据流更简单。类似于计算系统中的系统总线吧。需要更新数据时，通过 Redux 的 action 去更新数据，数据通过总线然后告诉所有的组件。这样每个组件的数据来源就单一了，都是从所谓的总线传递过来了，避免了各种私拉电线，最后导致线路混乱的情形。
每个组件的输入只有一个，不用 care 更多的东西，更加简单，也便于我们编写组件。统一了单向数据，也使得我们更容易使用别人的东西。你想想如果我们电脑上的某个元器件不仅仅依赖总线的数据，还依赖其他的元器件的输出，很可能你换了这个元器件就出现兼容性问题，不能通用。就像一个函数，不仅仅依赖函数参数，还依赖全局变量，那是多么奔溃的一件事。
先写到这儿吧，以后有时间在随便扯扯。
ps：非喜勿喷，欢迎指正、讨论。
