一介布衣

2014 年前端最明显的变化之一，就是大家开始不再满足于“jQuery 把页面拼起来”这种方式了。页面逻辑越来越复杂，数据与视图之间的关系也越来越需要一种更系统的组织方法。

刚接触 AngularJS 时，如果只看到模板语法和双向绑定，很容易把它理解成“更会操作页面的 jQuery”。但真正让项目组织方式发生变化的，往往是 service 和依赖注入这套东西。它让数据请求和公共逻辑开始有了固定归宿。

第一次看 AngularJS 的指令示例时，很容易觉得它像一种“什么都能包起来”的能力。按钮、列表、弹层、表单，似乎都可以做成指令。这个想法没错，但如果刚入门就把所有逻辑都往指令里塞，通常很快会把自己绕进去。

列表页做缓存，最先想到的写法通常很直接：第一页缓存成一个 key，第二页再来一个 key。
刚开始看完全没问题，可 2014 年我在给后台列表和内容列表做 Redis 缓存时，很快就遇到现实难题：真正决定一页内容的，根本不只是页码。

2014 年前后，Node.js 配 Redis 是很常见的一套轻量组合。大家一开始都觉得 Redis 上手快，set、get 会用就能干活，但真把它放进登录态、验证码、计数器、页面缓存之后，问题很快就来了：key 越堆越多，过期时间各写各的，最后自己都看不懂线上到底存了什么。

Grunt watch 刚接进项目时，体验真的很好。改一个文件，自动检查、自动编译、自动刷新，前端开发节奏会立刻顺起来。但 2013 年我在几个页面项目里把它用深之后，也很快遇到另一个问题：watch 一旦开始什么都监听、什么都触发，最后开发环境会变得越来越重。

同一台电脑上同时管理多个 SSH key，最开始最容易掉进“我记得这个仓库该用哪个 key”的状态。2013 年我在不同 Git 仓库、不同服务器之间切换时，也常常靠记忆硬撑，结果不是连错主机，就是推送时身份不对。

页面一旦出现“点击没反应”或者“滚动明显发卡”，很多人会笼统地说这是性能问题。但性能问题如果只停在这个词上，其实没有任何帮助。对前端来说，更实用的还是先把问题拆开：是逻辑没走到，还是逻辑走到了但执行得太重。

2013 年前端开发已经越来越离不开浏览器开发者工具了。页面一出问题，如果不会用 DevTools，很多排查只能靠猜。

样式问题最容易让人陷入一种低效循环：改一处 CSS，刷新页面，看不对，再回去改下一处。尤其是接手别人留下来的页面时，选择器层级多、覆盖关系杂，如果只在源码里猜，很快就会迷路。