从第一份实习工作至今，从事前端开发已经快两年了。回想起大概一年前自己对于这个问题的思考，感觉当时有点一叶障目，不过这也是难免的。
最近的工作内容有些特殊，代码写得不是很多了，也许正是这个原因，反而从埋头写代码，埋头想如何把代码写好中挣脱出来，感觉自己对于这个问题有了更全面的理解，想要谈一谈。
当然，这些理解并不是完全起源于自己，甚至大多数都来自于身边经验更丰富的同事，我觉得这是自然而然的事情，对我来说也是幸运的。
仅就前端而言
前端的职责是什么？
“更好”
我想相当一部分人，包括我自己，都曾以为前端的职责是开发前端页面，如今我意识到，这只是最基本的职责，除此之外还有另一个重要的职责，就是把这件事做得更好。
“更好”可以这么理解：能做只是进入任何一个行业的门槛，专业之所以专业，就是因为把同样的事情做得更好。
途径和目标
「开发前端页面」其实只是一种途径，并不是最终的目标，最终的目标应该是：
能用技术支撑好业务，不让技术上的问题，成为业务发展的阻碍。
应该从哪些方面去做？
前端支撑业务的载体主要是web应用，为了实现最终目标，我们主要应该关注如何把web应用做好。我觉得可以从这些角度来考虑。
开发效率
简单地说，就是活干的又快又好。为了提升效率，我认为有这些途径：
- 流畅的研发体验：
- 本地开发调试流畅：热更新、项目编译启动速度，mock数据，连接沙盒、线上环境调试都应该做好
- 团队文档管理（设计文档、项目文档、笔记）
- 开发->代码入库->部署沙盒->部署线上，持续集成的过程应该是傻瓜式的，流畅的
- 良好的API管理：api定义杂乱或文档不全会浪费大量的时间对接口
- 保持合理的项目架构，有良好的抽象和封装
- 抽象设计易于理解，即便是一个技术一般的开发者，也能快速上手
- 能够大幅减少重复代码
- 软件会逐渐变质，应该及时地、阶段性地重构
- 通用的工具包：封装众多应用之间通用的功能（时间工具、校验工具、ajax操作封装...）
- 规范的项目管理机制：规范不合理应该去修正规范，而不是不遵守规范——规范最直接的好处，就是让项目的各个成员都能保持自己熟悉的节奏，随着项目团队的磨合，节奏会越来越好
- 完善的脚手架：能够快速开启新项目。
稳定性
稳定性应该是有一个及格线的，对于不同类型、不同规模的项目，及格线的位置不同，但是稳定性达到及格线，我认为应该是一个软件的最最最重要的基础，不容妥协。
为了提升稳定性，有这些途径：
- 一个应用应该有P0测试case，并且整理下来，当做比较大的线上变更，所有P0 case都需要测试通过
- 单元测试：代码的可测性和单元测试是相辅相成的（当你开始写单测，会自然地注意代码的可测性）。最起码对核心逻辑，或一些被复用的逻辑，应该有单测。
- 做好code review：理论上所有的入库代码都应该经过cr的，并且不流于形式，cr时能及时发现代码的问题
- sentry：对系统的代码报错和业务错误均有收集，不等用户反馈，就应该能够看到线上出现了哪些异常情况，以及时处理和定位
- A/B test：大的功能升级可以先小流量上线观察
- 快速的上线、回滚能力：保证线上问题能够被尽快处理&修复
- 容灾和降级：对于一些稳定性要求比较高的应用，有容灾降级的方案
- 稳定性评估：有一套稳定性评估模型，包括线上错误数、单测覆盖率、线上bug数、线上故障时间等，有评估机制，才能知道进步的空间和效果。
技术力
如果说效率和稳定性是朴实的内容，技术力应该就是花活了。前端的“花活”可能包括这些：
- 样式和动效
- 音视频处理
- 图形学（Canvas、3D）
- SEO
- 国际化
- 各种端能力
- 用户行为采集
- 前端性能优化
- 静态页面生成
- 编译工具开发
每一点，都是一个非常大的课题，我个人认为，对于这些花活，不能太过投入和迷失，否则很容易陷入自嗨的境地，要明白什么对产品来说是重要的。我的态度是：先做基本的了解，有需要的时候再去深入研究，不迟。
优先级？
在我自己看来，稳定性 > 开发效率 > 技术力，这样的优先级排序，应该是适用于大多数业务的。
应该学习什么？
我眼中资深前端工程师的标准，就是在开发效率和稳定性的方方面面都有理解，并且实际完成过其中的多个topic。
而新人的前端学习路径，我认为不应该是从纯技术的角度去看，而应该从解决问题的出发点去看：
- 当要优化项目编译速度，自然要去看webpack
- 当要做平台式的api管理，自然要去看Yapi，swagger这类工具
- 当要重构现有的项目设计，自然要去看设计模式
- 当要通用的工具包，自然要去了解如何开发和维护一个npm包
- 当你想要快速的上线回滚，自然去了解DevOps
- ......
从这样的角度出发，很大一个好处，就是能避免自己陷入自嗨的境地，以至于忘了自己用技术到底是去解决什么问题。
随着涉足的topic越多，以及在实战经验中的历练越丰富，就越接近于资深的前端工程师。
同时我也认为，这样的前端工程师，才能真正地用技术去支撑好业务，不会让技术成为可能导致业务失败的因素之一。
不仅仅是前端
从主要职责上来说，前端就是个工具人，负责解决一个特定技术领域的问题。
但在实际中，我们的角色经常需要跨越前端，涉及更多其他领域。
产品力
前面说到，我们的目标其实是为了做好产品，做好业务。而前端天生就是贴近用户，贴近体验的，所以前端很容易对产品、业务有比较深刻的理解，这是一个不错的前提条件。
有时，也许一顿花里胡哨的技术优化，都不如一个产品设计优化来得有效，如果在技术之外，能对“好的产品”有着清晰的理解，也许会更容易的实现目标。
其他专业领域
说回技术，前端首先是一个程序员，其次才是前端。
当在前端领域打下了扎实的基础，触探其他技术领域，并不是多么困难的事。
我近段时间在做大数据相关的产品，学习了一些大数据相关的知识，当然我所学习的只是这个领域一小部分，但我却发现了很多值得去做的事。
我想了想为什么我之前没发现这些事情的价值，并且这些事情还没人去做，大概有三个原因：
- 以前不了解大数据，压根不知道还能这样做
- 以前觉得这个事情是有些价值，但没仔细想过，没想到有这么高
- 对公司内专业的数据工程师来说，这个事情的价值并不高，所以他并没有去做
这些原因会导致非常多事情的优先级和重要性没有被公正的评判，始终没有人去完成。
所以我认为，不画地为牢，主动开放地去设计其他感兴趣的专业领域，一定会有收获。
