了解下前端的发展历史和未来，还有一篇关于代码质量的话题，作者是反面入手，有点被说到心坎里去了的感觉
前端发展史
前端历史发展过程中，我们所能沉淀下来什么
- 早期 Web1.0 时期的形态，纯静态展现，前端工作非常简单，职责偏向于 MVC 中的 View，页面交互需要整体刷新，体验很差
- 动态 Web 2.0 时代，面向过程时代码大量增加，难以维护
- 前端 MVC 时代，backbone.js 前端 MVC 分层尝试的先驱者
- 性能问题：雅虎 35 条军规
- 自动化工具：代码合并，压缩，CSS 预处理，雪碧图等（Grunt 为代表）
- MVC/MVP 只是提供了职责的划分，并没有简化代码量，需要同时关注 Modal(data) 和 DOM 操作(view)
- 如今工程化初具规模
- webpack + babel
- vue/ng/react
- npm
- eslint
- Node + Express/Koa
- git flow
- 更多 SSR、GraphQL
- Hybrid App（JS 和 Native 通信）
- Cordova
- React Native
- NativeScript
- Weex
- Flutter
代码质量
今天看到一篇很清奇的文章，主要讲述代码质量相关，但作者是从反话入手，对于作者的观点和痛点，只能说深有感悟！
建议总结
- 不要过于追求让代码尽可能的短一点，比如要保证易读性的前提，比如三元表达式不要盲目使用
- 变量的命名，不要使用一个字母的变量，当然循环索引可以除外
- 不要使用单词缩写，比如
browser -> brsr，那样只有你自己看得懂 - 避免抽象的、通用的命名方式，比如
- obj/data/value/item/elem
- 根据变量类型命名：str/num，本质提供不了有价值的含义
- 如果找不到更多的名字呢？追加一个数字，比如 item1、item2
- 避免智能同义词，比如函数前缀 display、show、render、paint
- 避免重用名字
- 覆盖形参变量的值，会导致后来人不自己检查代码，根本不知道变量被修改过
- 本地变量覆盖外部同名变量
- 避免使用下划线
- 代码变得更长降低了可读性
- 其他伙伴可能会花费很长事件来弄清楚下划线是什么意思
- 避免副作用和非标准结果
- isXXX/checkXXX/findXXX 等函数看起来不会改变任何东西，也就是无副作用函数，因此一定不要产生去改变某些东西
- 比如 isXXX/checkXXX 表意应该是返回 boolean，因此不要返回其他等不标准结果
- 避免强大的函数，函数功能要单一
- 如果你觉得函数名称不好取了，就该思考是不是他做的事情太多
- 多个动作加到一个会导致代码难以宠用