女儿秦慕是上外本科毕业，改行到腾讯的

腾讯前端高级工程师分享:

一个前端工程师的成长经历 秦慕 

讲得不错，可以借鉴一下

虽然从毕业到现在，我只工作了 3、4 年，但我什么都做：前端 Web、移动端 Android、后端 .NET，甚至还有嵌入式。但我最喜欢的还是 Web 前端，我喜欢图形、动画、交互，喜欢 HTML、CSS 和 Javascript 赋予的快速呈现的能力。我喜欢 Web 前端能够让我自己实现自己的需求，喜欢 Web 前端更加靠近视觉、艺术方面的能力，方便我做一些自己喜欢的动画、游戏等等。

我自认为自己在 Web 前端还有点研究，从最初的原生 HTML、CSS、Javascript，到框架 React、Vue、Angular，到绘图技术 Canvas、SVG，到后端接壤 Node 等。我在工作时也很开心，编写网页并不会让我感到疲劳。但最近的一些事情和现实情况，却让我怀疑，我现在做得事情是否有价值。

一是个人的成长速度放缓。工作中需要的技能，基本上我已具备，一般的工作对我来说没有任何问题。但我只是做一些大部分 Web 前端工程师都能做得工作：调用接口、呈现数据、填写表单、发送请求。少数让我觉得兴奋之一的工作是数据可视化，但比较少。

二是市场上出现了大量“前端已死”的声音。由于经济下行，很多公司裁员。而 Web 前端因为门槛低，容易被替代，大量 Web 前端程序员失业。所以我想，虽然我目前在公司没有被裁的风险，但其实不可替代性很低，日后万一有风吹草动，我会不会是最先被裁撤的。

三是 AI 技术的爆发发展。GPT 等模型的出现，使得 AI 代替人担任某些岗位似乎成为了可能，GPT-4 更是能够从设计图直接生成网页代码。很多人对自己的岗位是否会被替代而带有，我也无法免俗。虽然我认为 Web 前端的上限很高，但并不是所有公司都需要那么尖端的 Web 前端技术。如果真到了 AI 替代人类的那一天，我将何去何从。

以上是我最近的一些担忧，它们让我思考：

Web 前端的价值是什么？

我是一个合格的 Web 前端工程师吗？

如果我不再从事 Web 前端，那么我能从中汲取什么，并带到新的领域中？

我想搞清楚这些问题，因此我进行了一些思考和总结，写了一些文章。

我喜欢 Web 前端，热爱编程。即使有一天我不得不放弃做一名 Web 前端工程师，我希望我离开是因为环境容不下我，而不是因为我不是一个合格的 Web 前端工程师。我希望但市场不再需要 Web 前端工程师的时候，在这个领域学到的东西，能让我更好的进入另外一个领域。

就像 JQuery，使用率不断下降，但它的思想引领了一个时代的编程方法，潜移默化地影响了 Web 标准。它并不是被淘汰，而是功成身退。

Web 前端工程师是什么

Web 前端工程师是什么？通俗的来说，是编写网页的人。

但在成为 Web 前端工程师之前，先得是一个工程师，再是一个软件工程师，然后是 Web 前端工程师。

工程师

维基百科这么定义工程师：工程师是指那些在工程专业领域的人，他们使用科学知识来驾驭技术以解决实际问题，并以此为职业[1]。

工程通常是用于实现某个需求的一系列工作，而“问题”一词很好地揭示了工程师的本质。因为通常来说，工程不是容易完成的，常伴随着一系列问题。此时就需要工程师在有限的资源下，想尽办法来解决问题，完成工程。

因此，通俗的说，工程师是解决问题的人。

软件工程师

承袭上面的定义，可以推出软件工程师是实现软件工程的人，通俗的来说，软件工程师是解决软件领域问题的人。

在传统项目（比如土木工程）中，工程师通常不是工程的具体操作人（真正操作人是建筑工人），而是设计师和规划者。在软件领域，软件工程也可以分为工程师和程序员，即由软件工程师来理解需求、构建框架、定义系统，由程序员来做具体编程的工作。在大型项目中，可能确实如此。但因为软件领域的体量轻，需要的固定资源少，特别是对于互联网软件行业，一家公司可能不会由很多人，通常是以小团队为单位进行软件开发。因此，在这些项目和团队中，不会区分工程师和程序员，即软件的设计人员和编程人员是同一个。

同时，对于这个世代的程序员来说，交叉工种和学科的能力几乎是不可或缺的。一个程序员也必须学会工程、系统等知识，才能更好的发展。因此本文不区分软件工程师和程序员。

软件，既是软件工程师的目标，也是软件工程师的手段。因此，为了完成软件而必须的编程能力、系统知识、思想方法，是软件工程师的核心技能。

Web 前端工程师

Web 前端工程师是软件工程师的一种。传统意义的 Web 通常是指运行在浏览器（如 Chrome）上的软件，这种软件的特点是：

资源从服务器获取

运行在一个沙箱中

渲染依托于浏览器而不是直接使用操作系统的 API

这些特点使得 Web 有诸多限制，比如必须在有网络的环境下运行、不能访问本地文件等，但也造就了它天生的最大优势：跨平台。只要是有浏览器的地方，就能运行网页。早年可能还存在浏览器之间差异的问题，但随着 Blink 和 Webkit 几乎统治了浏览器市场以及 IE 的入土，Web 标准化（W3C）越来越深入人心（至少目前是这样的）。所以前端工程师大部分时间只需要把重点放在浏览器上，相较于其它软件（比如移动端），系统底层差异造成的麻烦就小得多。在非桌面端，也出现了 Hybrid 和 Electron 等跨平台的开发方式。

所以，Web 前端开发工程师是根据 Web 标准，用运行在浏览器中的软件，来解决问题的人。

前端工程师

至此，得到了一个 Web 前端工程师的通俗说法。

现在把概念扩大一点，把 Web 拿掉，什么是前端工程师呢？这里的“前端”是相对于后端服务器而言的，从前不区分前后端，一个请求从浏览器出发，到后台服务器，到数据返回到浏览器，都由后端程序完成。但是随着需求的增长，Web 页面的复杂度增加，以及浏览器性能的提升促使单页面应用（SPA）的出现，后端程序员快忙不过来了。于是出现了前后端分离，当然前后端分离的好处[2]不单单是为后端程序员减轻负荷，但这不是本片文章的讨论范围，因此不予叙述。

随着前端的发展，对前端工程师的要求也越来越高，出现了更多对前端工程师的技能要求。也就是说，相较于后端，前端工程师的技术和思想开始越来越区别于后端。主要体现在：

良好的美术审美和用户交互体验

不同设备显示方式的兼容（桌面，平板，手机）

数据可感知（数据可视化，音视频播放）

从这些角度来讲，开发桌面端、移动端和嵌入式段软件的工程师，应该也属于前端工程师，而且目前的趋势也正是朝着这个方向前进，出现了很多跨平台的工具，比如 Flutter 和 Reactive Native。也就是说，直接与用户打交道的界面，都可能是前端工程师的工作。

从内容上来看，现在的前端已不再是简单的文字和图片，也不仅仅是音视频等各种媒体，而是朝着多维度的可交互方向发展，比如游戏、VR、网页端的复杂应用（比如 Office）、3D 等等。

Web 前端工程师的作用

Web 前端工程师的工作内容是编写网页。从工程的角度来讲，这项工作包括：

理解需求，构建系统框架

整理系统需要的资源（比如 UI 资源、接口资源、部署资源）

编写程序源代码，将代码转译或编译成浏览器可用的程序

保证程序在浏览器的兼容性和性能要求

将网页程序部署到服务器

监控并收集日志，优化网页、修复错误

前端不断发展，对工程师的要求也越来越高。最近 10 年兴起的前端工程化潮流，使得 Web 编程越来越成熟和完善，各种工具和框架层出不穷，方兴未艾。因此，Web 前端工程师不能只满足于输出网页，也要关心自己用于开发网页的工具。也也就是老话说的：工欲善其事，必先利其器。包括但不限于：

源代码转编译和打包工具（比如 Webpack）

Web 标准与浏览器兼容性插件（比如 Babel）

代码编辑器和相关插件（比如 VSCode）

浏览器和相关插件

网页程序部署服务器（比如 Nginx）

分析需求可行性和开发资源

Web 前端工程师需要理解需求，当然理解需求不是前端工程师一个人的工作，一起工作的还有产品经理和其它程序员等。而前端程序员在这个步骤中，很重要的一个作用是判断需求的可行性，即判断一个功能点能否在浏览器中实现，能否满足性能要求。

这一点对于产品和项目都很重要。如果某个功能无法实现，那么产品经理就需要考虑是否要修改或放弃这个功能，或者另想办法，绕个弯间接地实现功能。如果功能可以实现，但是需要很大的研发投入或开发时间，那么项目经理就需要把这一风险好好考虑。

如果需求可以实现，那么就需要评估完成需求需要的时间，指出实现需求必须的资源，然后进一步与具体工作的同事沟通。如果需求实现存在风险，那么应及时提出，以方便项目经理调整安排，或者与同事商量以探索可能的解决方案。

为了做好这一点，要求 Web 前端工程师有这些能力：

沟通技巧：抓住重点，提炼要点，倾听对方的需求，提出自己的需求。

跟随 Web 标准的发展，学习新知识和技术。

全面了解浏览器的功能，认识浏览器能做的和不能做的，以及浏览器能够达到的极限。

了解浏览器在不同环境下的局限（比如在手机中的浏览器可能有性能和网速的问题）。

抽象需求为代码结构，将现实和 UI 领域的概念转换为编程领域的概念。能够下意识地想到需求应该怎样实现，有哪些既有地方案和已存的代码可以参考。

产出实现需求、性能优秀且对用户友好的网页

Web 前端工程师的产出，一般来说包括以下：

单页面应用：页面内容由运行时 Javascript 生成且自己管理状态，数据从后台获取。

服务端渲染应用：页面内容由服务器直接生成，随着文档一起发送到浏览器，通常是为 SEO[3] 设计。

渐进式网页应用（Progressive Web Application，PWA[4]）：常驻在浏览器中，可以离线使用的应用。

如果推广至前端工程师，那么桌面端 GUI 软件和移动端应用可能也是前端工程师的工作。这些软件对于前端工程师，通常是用基于 Web 的跨平台构建工具实现，比如：Electron 和 Webview。当然也可以使用自成一派的工具，比如 Flutter。

实现功能、减少错误，是对网页最基本的要求，然后再谈性能和体验的问题。

性能

网页的性能主要是指网页浏览时的流畅性，包括：

从网页跳转到显示主要内容的时间短。

用户点击或其它交互后网页做出反应的时间短。

网页内容发生变化时不突变（即通俗来说不卡顿）。

这些指标的详细研究，可以参考谷歌的 Web 开发网站[1]。

要做到这些，需要工程师对可能消耗大量时间的代码和操作有所意识，想办法减少冗余操作，提高效率。通常来说，算力密集的工作通常由后台服务器来完成，但随 Web Application 的发展，越来越多的产品将 Web 视作一个可以独立完成工作的平台，这对 Web 前端工程师带来了更多的挑战。

可用的方法有：

使用浏览器开发工具[5]，检查性能消耗大的代码并优化。

缓存体积大的数据（存放在内存、LocalStorage 和 IndexDB 等）。

使用 Web Worker，并发运行高消耗的程序。

降低资源文件体积，减少打包冗余。

体验

网页是给人浏览的界面，因此网页的操作方法应符合人的认知逻辑，风格应符合人的审美（艺术创新除外），交互方式应尊重人的感受。

为了达到这些要求，网页需要做到：

页面需要一定的焦点控制，即应该突出重点部分，同时引导用户的焦点在不同部分将流转，有所取舍，不能过于复杂。

用户进行的一切操作（比如点击、悬浮、滚动、加载等），都应有所反馈，反馈的方式包括但不限于：正常的流程、通知、样式变化等。

大面积的内容变化（比如弹出框），应有动画进行过渡。

页面重复出现的元素，有相同的含义且始终保持一致。

保存用户当前的操作状态，页面跳转返回或进行其它变更状态的操作时，应当保存的状态（比如列表位置、表单填写）可以自动重现。

Web 前端工程师虽然属于程序员，更多地是理想思维，但是应该向 UI 设计师看齐，具有一定的审美水平和设计思维，了解基本的的色彩、构图等。这一方面的知识，可以参考《写给大家看的设计书》[6]。

更进一步说，前端工程师可以学习初步的 UI/UX 设计师常用的软件（比如 Photoshop、Figma 等），以更好的控制美术资源。

编写良好的代码和网页的持续优化

在实现了需求之后，工程师就需要关心代码在功能和性能以外的属性。在这些方面，良好的代码应具有以下特点：

良好的可读性：为了与同事交流，以及日后自己能看懂。

可扩展和易修改：为了应对 Web 快速变化的需求。

这里的表述是从实际工作中的编程习惯和多人协作出发，而不是传统意义上的代码规范和设计模式。关于良好的代码规范和设计模式，有很多书籍可以参考，比如《设计模式：可复用面向对象软件的基础》[7]和《重构》[8]。因为内容非常多，这里就不展开了。

编写网页不是一蹴而就的事情，即使在网页已经发布了之后，还有很多的甚至是更多的工作要做：

修复用户报告或主动检测到的错误

优化网页的性能

改善代码结构

升级技术栈

搭建基础设施

虽然编写网页需要的工具不多，一台电脑就行。但是为了更高效的工作，Web 前端工程师需要一些基础设施，如同现实中的高速公路一样，有了它才能把货物运往各地。

为了高效的工作，软件工程师想到了很多方法。别忘了软件既是目的，也是手段。

框架

现代的 Web 应用通常不会从 0 开始写 Javascript，而是采用框架和工具（比如 React、Vue、Angular 等）。这些工具大大提高了工作效率，但在这些框架之上，Web 前端工程师还需要一套基于公司和自己业务的框架。这套框架在 React、Vue 或 Angular 的基础上，添加了常用的 UI 组建库，包含了业务常用的代码或库，以及适用于业务的打包和部署代码。这么做的目的，是为了省下重复的搭建项目和打包部署的时间。有些公司的业务可能需要 Web 前端工程师随着工作的推进不断的创建项目，如果此时能够“一键”生成出上述的内容，那么将会省下很多时间，同时也可以不重复之前犯过的错误和踩过的坑。

这样一个框架，也可以说是一份模板，把它放在 Git 仓库中，使用时 fork。或者放在私有 NPM 仓库中，利用npm init <executor>命令[9]进行创建。

CI/CD

Web 通常是需要经常更新的，把新修改的代码打包的文件放到服务器上，也就是部署。举例来说，一般的更新过程如下：

修改代码

打包代码

转移代码到服务器

重启服务器

以前，2、3、4 步都是手动完成的，也就是在开发者电脑上打包，手动复制到服务器，手动输入命令重启服务器。这样做不仅繁琐，还容易出错。因此，持续继承/持续部署（Continuous Integration/Continuous Deployment，CI/CD）[10]出现了。它把打包代码到重启服务器的步骤自动化，且都在服务器上完成，开发者需要做的只是推送代码。

这一部分的工作通常还需要运维工程师的帮忙，但作为一个软件工程师，这一部分的只是需要了解，最好能亲手试试。

私有 NPM

如前面提到的，Web 前端工程师经常需要在不同的工程间共享代码。一种方法是使用 Git 子模块（Submodule），即在一个 Git 仓库中存放一个子仓库，子仓库使用自己的 Git 管理，与本仓库独立。但是这种方法其实不太适合大规模的代码共享，因为需要协调各个项目之间的版本关系，而 Git 其实不擅长这个事情。更通用的是使用 NPM，如果公司有安全性的考虑，可以在公司的内网搭建私有的 NPM 服务器。

关于创建和上传 NPM 包，可以参考NPM 官方文档[2]。

监控系统

即使是顶级的 Web 前端工程师，写的网页也难免有错误和性能问题，这些在开发时难以察觉的问题或疏忽，在实际用户各种各样的环境中就有可能出现。因此 Web 前端工程师需要从用户端收集日志，内容包括：

页面错误信息

性能信息（加载时间、首屏渲染时间、接口延迟时间等）

接口调用信息

页面运行环境（设备、浏览器、网络情况等）

用户信息

这些日志不仅能在用户报告了错误后，对错误进行分析调试，也可以对性能差的页面，针对性的进行优化。

这一套系统包含两个方面，运行在用户端浏览器的监控程序，和运行在服务器的收集分析程序。市场上有成熟的解决方案，比如阿里云 ARMS，也可以自己搭建。比如在前端编写收集信息的程序[11]后，在后台使用免费的 Elasticsearch + Logstash + Kibana[12]方案，或者 Loki + Grafana[13]方案。

Web 前端工程师的工具包

工欲善其事，必先利其器。作为一个工程师，Web 前端开发者需要很多的工具，最好是自己熟悉和常用的，同时可以自己配置从而最适合自己的。这样一套工具组成一个环境，让工程师在工作室随手可用。

代码编辑器

开发网页需要的软件工具不多，一个代码编辑器和一个浏览器就足够。但是随着 Web 前端内容形式和编程方式的发展，以及为了更高效地工作，一个好的代码编辑器往往可以达到事半功倍的效果。

每个程序员都有自己喜欢的编辑器，但是为了达到上述“适合自己”和“随手可用”的效果，编辑器最好可以安装插件和同步配置。

以 VSCode 为例，它可以安装各种插件，从语言 Lint、调试工具、代码美化、资源预览等一应俱全，同时它支持登陆 Github 或 Microsoft 账号，以在不同设备间同步插件和设置。这样就满足了程序员在不同的工作环境中都能用自己最舒适的编辑器编程的需求。

如果有的功能代码编辑器没有实现，也没有现成的插件，可以自己尝试编写插件[14]。

浏览器扩展

Web 前端工程师在调试网页时，可用的方法有断点调试和控制台日志输出，除此以外还可以借助浏览器扩展。

现代的 Web 开发框架（React、Vue、Angular）等都提供了浏览器扩展，用于显示当前页面中组件的状态、成员变量值、路由信息等，非常直观。有些工具还可以实时设置变量的值，而页面也能立即反应变化，很方便。

除了框架，一些知名库，也提供了开发扩展，比如 Three.js。在移动端，如果没有扩展，可以依靠如 vConsole[16] 这样的 NPM 库，在移动端模拟如桌面浏览器那样的开发控制台。

同样的，如果现成的扩展不能满足要求，也可以自己开发。

个人笔记

Web 前端是一个交叉学科的领域，涉及的知识面非常广。即使一个人的记忆力再好，也总有突然之间想不起某个知识点的情况。特别是在现在技术飞速发展的年代，知道一个东西比记得它的详细内容更重要。因为我们可以将细节记录在笔记中，需要时查询即可。

比如，NPM 有很多有用的库，程序员可以给用过且好用的库打个标签，记下笔记。需要时，查询笔记，使用相应的库即可。

有很多软件可以记录笔记，比如印象笔记和有道云笔记，它们的免费功能就已经够用了。如果觉得放在厂商的服务器上不安全（厂商有跑路的风险），那么也可以记在自己的电脑上，然后用 Git 同步到远程仓库，当在公司工作时，就可以在网页上浏览笔记。

更进一步说，既然我们是 Web 前端工程师，我们可以自己开发一个网页，存放在比如 OSS 的地方，满足我们对笔记的浏览和编辑等要求。

我一直认为自己是“初级”前端开发工程师，一方面我入道尚浅，只有短短几年，另一方面我自知对技术的钻研并不深入，可能是由于环境的原因，当然最重要的是，我幸运的参与到互联网崛起的浪潮之巅。时势造就了一批技能薄弱但备受追捧的“弄潮者”，这在很大程度上影响我们对“技术本质”的洞察力，多年来也一直未有成体系的“前端技术”布道佳作，以至于当下多数人对前端技术的了解，盖始于表述并不严谨的岗位招聘描述，而这正恰恰反映了Web前端开发对自身的模糊定位。对于很多Web前端工程师来说，初尝禁果的快感无法持续很久，就陷入一轮又一轮的迷惘，思索自己的职业规划，试图寻找到适合自己的成长道路、看清自身技能的瓶颈，寻找突破。但遗憾的是，Web前端技术被广泛接纳时日尚短，没有多少励志的成功样板可供遵循。然而情况不总是这么糟，毕竟Web前端技术是一门“技术”，和计算机科学系出同门，只是因为互联网的高速崛起而被蒙上了迷雾，遮住了双眼，让我们傻傻看不清时局。

那么，如何定义Web前端技术岗位边界？Web前端技术的价值体现在何处？前端工程师的价值仅仅体现在物以稀为贵吗？前端工程师的初级、中级、高级和专家之间到底如何界定？当前“我”处在什么位置？接下来的路子应当怎样走？何谓前端技术之“道”？我想多数人都思考过这些问题，本篇“十日谈”里的观点可能有些偏激，但抛砖引玉，读者权且把这些言论当作一个引子吧。

第一日：初尝禁果

【上帝说：“要有光！”便有了光】

万物生灵、阳光雨露盖源于造物之初的天工开物，我们无法想象上帝创造光明之前的世界模样。但幸运的是，前端开发没有神祗般的诡魅。这个技术工种的孕育、定型、发展自有轨迹，也颇有渊源，当然，这非常容易理解。不严格的讲，在杨致远和费罗在斯坦福大学的机房里撺掇出Yahoo！时，Web前端技术就已经开始进入公众视野，只不过当时没有一个响亮的名字。从那时起，“基于浏览器端的开发”就成了软件开发的新的分支，这也是Web前端技术的核心，即不论何时何地何种系统以及怎样的设备，但凡基于浏览器，都是Web前端开发的范畴（当然，这个定义很狭隘，下文会提到）。

在2000年之后浏览器技术渐渐成熟，Web产品也越来越丰富，中国有大批年轻人开始接触互联网，有一点需要注意，大部分人接触互联网不是始于对浏览器功能的好奇，而是被浏览器窗口内的丰富内容所吸引，我们的思维模式从一开始就被限制在一个小窗口之内，以至于很长时间内我们将“视觉”认为是一种“功能”，Web产品无非是用来展现信息之用。起初的入行者无一例外对“视觉”的关注超过了对“内容”的重视，先让页面看起来漂亮，去关注html/css，沿着“视觉呈现”的思路，继续深入下去。因此，这类人是被“视觉”所吸引，从切页面入行，着迷于结构化的html和书写工整的css，喜欢简洁优雅的UI和工整的页面设计，之后开始接触视觉特效，并使用jQuery来实现视觉特效，以此为线索，开始深入研究Dom、Bom和浏览器的渲染机制等，html/css在这些人手中就像进攻兵器，而JavaScript则更如防守的盾牌。

还有另外一群人从另一条道路接触Web前端，即工程师转行做前端，他们有较多的后台语言开发背景，从读写数据开始，渐渐触及浏览器端，接触JavaScript库，起初是在html代码上加js逻辑，后来开始涉及html和css，他们喜欢OO、逻辑清晰、结构悦目的代码，更关注界面背后的“程序语言”和数据逻辑。html/css在这些人手中则更像盾牌，而JavaScript更如进攻的兵器。

应当说这两类人是互补的，他们各自了解浏览器本质的一部分，一拨人对渲染引擎了如指掌，另一拨人则将JS引擎奉为至宝，其实任何一部分的优势发挥出来都能做出精品。大部分前端工程师都能从这两条渊源中找到自己的影子。但，这两类人的思维模式和观点是如此不同，以至于形成了一些不必要的对抗，比如在某些公司，干脆将Web前端技术一分为二，“切页面的”和“写js的”。这样做看上去明确了分工提高了效率，但他对员工的职业发展带来巨大伤害。在第二日“科班秀才”中会有进一步讨论。

我应该属于第二类，即在学校正儿八经的学习C/Java和C#之类，以为大学毕业后能去做ERP软件、桌面软件或者进某些通信公司写TCP/IP相关的程序。校园招聘时选择了中国雅虎，因为当年（08年）雅虎还是有一点儿名气，而且我听说雅虎比较算技术流的公司……自此就上了贼船，一发不可收拾。

在雅虎的这段时间，我有幸接触到一股正气凛然的技术流派，也形成了我对前端技术的一些基本看法，这些基本观点一直影响我至今。

【优雅的学院派】

当年雅虎的技术流派正如日中天，拥有众多“之父”级的高人，所营造出的Hack氛围实在让人陶醉的无法自拔，那段时间我甚至宁愿加班到深夜阅读海量的文档和源代码，感觉真的很舒服，我深深的被雅虎工程师这种低调务实、精工细琢的“服务精神”所打动，而这种不起眼的优秀品质很大程度的影响雅虎产品的用户体验和高质量的技术输出。那么，何谓“服务精神”？即你所做的东西是服务于人的，要么是产品客户、要么是接手你项目的人、要么是使用你开发的功能的人，所以技术文档成为伴随代码的标配。因此，工程师之间通过代码就能做到心有灵犀的沟通。这是工程师的一项基本素质，即，思路清晰的完成项目，且配备了有价值的技术文档，如果你的程序是给其他程序员用的，则更要如此，就好比你制造一款家电都要配备说明书一样。因此，YDN成了当时最受全球程序员最喜爱的技术文档库，这种优雅务实的“学院气息”让人感觉独具魅力。

让人感觉奇怪的是，在中文社区始终未见这种学院派。甚至在具有先天开源优势的Web前端技术社区里也是波澜不惊，可见写一篇好的技术文案真的比登天还难。我所见到的大部分所谓文档索性把代码里输出数据的语句块拷贝粘贴出来，至于为什么数据格式要设计成这样、如果字段有修改怎么做、编码解码要求如何等等关键信息只字不提，或者开发者也没想过这些问题呢。因此，我们一直在强调代码的质量和可维护性，但一直以来都未见效，盖源于缺少这种“服务”意识的灌输。这种意识在下文中还会多次提到，因为它能影响你做事的每个细节，是最应当首先突破的思想纠结。

除了意识问题，另一方面是技术问题，即文笔。这也是工程师最瞧不上眼的问题，难以置信这竟然是阻碍工程师突破瓶颈的关键所在。我已看到过数不清的人在晋升这道关卡吃了大亏，很多工程师技术实力很强，但就是表达不出来，要么罗列一大堆信息毫无重点、要么毫无趣味的讲代码细节，不知云云。除非你走狗屎运碰到一个懂技术的老板，否则真的没办法逃脱码农的宿命。但大部分人还振振有词不以为然。而在Web前端开发领域情况更甚。前端工程师是最喜欢搞重构的，但在快节奏的需求面前，你很难用“提高了可维护性”、“提升了性能”这类虚无缥缈的词藻为自己争取到时间来搞重构，说的露骨一点，可能你真的对某次重构带来的实际价值无法量化，只是“感觉代码更整洁了”而已。我会在下文的“伪架构”中会展开分析前端工程师的这种浮躁献媚的技术情结。而这正是前端工程师最欠缺的素质之一：用数据说话，用严谨科学的论据来支撑你的观点，老板不傻，有价值的东西当然会让你去做。

当然，情况不总是这么糟糕，我们看到中文社区中已经锻炼出了很多写手，他们在用高质量的文字推销自己的技术理念，这是一个好兆头，好的文笔是可以锻炼出来的。而在职场，特别是对前端工程师这个特殊职位来讲，这种基本技能可以帮你反思梳理需求的轻重缓急，从凌乱的需求中把握七寸所在。因为当你开始认真写一封邮件的时候，这种思考已经包含其中了。

所以，雅虎技术的推销是相对成功和远播的。关键在于两方面，扎实的技术功底和高超的写手。而真正的技术大牛一定是集两者与一身，不仅钻研剑道，还能产出秘籍。这也是Yahoo！优雅的学院派气息的动力源泉。国内很多技术团体想在这方面有所建树，应当首先想清楚这一点。

【规范的破与立 1】

雅虎的技术运作非常规范，刚才已经提到，包括技术、组织、文化，一切看起来有模有样，也堪称标杆，自然成了国内很多技术团队和社区的效仿对象。一时间各种“规范“成风、各色“标准“大行其道，结果是质量参差不齐。

我们到底需要什么样的规范？雅虎的技术规范到底有何种魔力？以何种思路构建的规范才是货真价实的？规范有着怎样的生命周期？想清楚这些问题，能很大程度减轻很多Web前端工程师的思想负担，看清一部分技术本质，避免盲目跟风。

我们的确需要规范，但好的规范一定是务实的，一定是“解决问题“的。比如针对项目构建的DPL可以收纳公用的视觉元件以减少重复开发、规定某OPOA项目的事件分发原则以确立增量开发的代码惯性。反之，糟糕的规范却显得过于“抽象“，比如页面性能指标、响应式设计原则。另外，尽管他山之石可以攻玉，但拿来主义有一个大前提，就是你了解你的项目的关键问题，你要优先解决的是些关键问题，而外来规范正好能解决你的问题。因此规范是一本案头手册，是一揽子问题的解决方案，应当是“字典”，而不是“教程“。可见规范的源头是“问题”。所以，当你想用CoffeeScript重构你的项目时、当你想引入CommonJS规范时、当你想在页面中揉进Bootstrap时、当你打算重复造轮子搞一套JS库时、当你想重写一套assets打包工具时，想想这些东东解决了你的什么问题？会不会带来新的问题、把事情搞复杂了？还是为了尝鲜？或者为了在简历中堂而皇之的写上使用并精通各种新技术？

规范之立应当有动因，动因来源于项目需求，项目需求则来自对产品的理解和把握，这是Web前端初级工程师走向中级甚至高级的一次重要蜕变，软件工程领域早就有“架构师”角色，而架构师往往存在于项目需求分析和概设、详设阶段。我看到的情况是，Web前端工程师的思维过多的限制在“界面”之内，向前和产品需求离的太远（认为这是视觉设计师的事）、向后和数据逻辑又隔离开来（认为这是后台工程师该干的事），因此前端规范也大都泛泛，无关项目痛痒，成了玩具。

雅虎技术规范的优秀之初在于它们解决问题。所以，学习使用规范应当多问一句，“他们为什么这样做？”其实，想清楚这些问题时，脑海中自然形成了一种“遇山开山”的创造性思维。

【规范的破与立 2】

如果说新技术的尝鲜缺少针对性，但至少满足程序员的某种洁癖和快感，那么“负担”从何而来呢？对于初学者来说，有价值学习资料可能只有这些规范，如果说规范价值不大，那又当从何入手呢？

刚才我说的不是依赖于规范，而是对规范的反思，摆脱规范灌输给我们的思维定势。新人们大概是看了Wiki中的很多指标、结论、实践，在做项目之初就附加了不少“八股式”的负担，甚至影响我们对项目关键需求和关键问题的洞察力和判断力，负担过重就无法轻装上阵，Wiki中提到的这些指标和规范是结论性的，是大量的实践之后得出的，也只有经历过大量实践才会真正理解这些结论，比如DomReady时间和http请求数是否有因果关系，http请求数增加是否真的会导致页面性能下降，什么条件下会导致性能下降？我们从那些条文和结论中无法找到答案。

举个具体的例子，Kissy刚刚出了DPL，也是一大堆结论，比如他的布局就采用了经典的双飞翼，使用容器浮动来实现，那么，这种做法就是不可撼动的“标准”吗？看看淘宝车险首页，布局容器齐刷刷的inline-block，只要顶层容器去掉宽度，布局容器自身就能根据浏览器宽度调整自然水平/垂直排列，轻易的适应终端宽度了。

再比如，淘宝旅行计划项目中的部署方式，也没有完全使用Loader管理依赖，而是将依赖层级做的很少，业务逻辑使用脚本来合并，这样就可以更容易在build环节加入语法检查和代码风格检查。

类似这种摆脱原有编程思维，有针对性的用新思路新方法解决问题的做法显然让人感觉更加清爽，编程的乐趣也正体现在打破常规的快感之中，小马曾经说过：“制造规范是为了打破规范”，万不要因为这些规范标准加重负担，导致开始做一个简单页面时也显得缩手缩脚，无法放开身手。大胆的动手实践，才能真正得出属于自己的“结论 “和“标准“，才会真正深刻理解那些“结论”的意义所在。代码写的多了，自然熟能生巧，也容易形成成熟的技术观点。

在这个过程中，我们唯一的对手是懒惰，惰于思考，就无法真正发现问题，自然形不成自己的观点。还是那句话，任何规范、方法、结论、实践都是为了解决项目中的问题的，所以，我们所接触到那些看似“八股文”式的规范标准也是为了解决某些问题而提出的，想清楚这些问题，理解方法论背后的“因“，内心自然有“果”。

因此，“着眼当下、对症下药”的品质就显得弥足珍贵了，比如，双飞翼布局方法是为了解决一套（html）代码适应多种布局设计，这里的布局相对于固定的产品来说也是固定的，而无针对终端的自适应（适用于移动端的榻榻米布局似乎还没有最佳实践）。这是双飞翼产生的背景，如今终端环境较之5年前已经翻天覆地，问题早已不在“多种布局”上，而在“终端适应“上，这才是我们面临的问题，需要我们给出新的技术方案。

所以，勤于思考，轻装上阵，大胆实践，勇于创新，发掘问题所在，实打实的解决（潜在）问题，这才是我们真正需要的能力。放下思维定势枷锁，也会有一种豁然开朗的感觉。

第二日：科班秀才

【秀才仕途】

Web前端工程师是一个特别的岗位，只存在于互联网领域。最近几年随着互联网产业的火爆，对前端工程师的需求量暴增，兵源几近枯竭。各大公司技术掌门一定都有过类似的苦恼：“招一个靠谱的前端工程师、难于上青天”。

我想，一部分原因是，当前不少入道的前端工程师大都是转行而来，毕竟，正儿八经的学校里也不会教这玩意，觉得“切页面”有啥好教的，甚至不觉得html/css是一门语言。转行这事自不必详说，大家也各自瞄准当前市场需求，造成的现象是，初级前端工程师堆成山，中高级人才却一将难求，计算机系的科班出身就更加凤毛麟角了。一方面反映了教育部门的后知后觉，另一方面也体现了大部分人急功近利的跟风。当然最重要的原因是，所谓中国“第一代前端工程师”并未做好布道的工作。导致大家对于基础和潜力的态度从之前的忽视演变为如今的蔑视。所谓基础，就是在大学上的那些计算机基础课。所谓潜力，就是戒骄戒躁的务实作风。这些会在后文中多次提到。

对于科班出身的莘莘学苗来说，根正苗红本身就是一种优势，事实证明，这些人在前端技术上的成长轨迹有一定的套路，而且大都能如期的突破技能瓶颈。从一个人大学毕业到他最满意的工作状态，中间会经过几个阶段。

前2年是学习技能的阶段，这个阶段主要精力放在专业技能的提升上，2年内起码要赶上平均水平，即所谓“中级“，在这个阶段的人通常对软技能不怎么关注，沟通能力达不到平均水平，基本上是来啥活干啥活，干不完就加班的这种，对需求的合理性不甚理解，对项目也没什么把控，尽管在技能上有提高的空间，也不是公司最需要的人，但有不少成长空间。

工作2-3年的人在前端技能上趋于稳定，也就是技能上的第一次瓶颈，这种人干活熟练，切页面可能也很快，代码看上去也比较规范，属于熟练工，开始注重沟通技巧和一些职业技能的积累，比如带人带项目，至少有这方面的意识，并有过推动项目、和业务方pk需求的经历，这就达到了中级应当具备的职业技能，但应当注意的是，这时最容易出现偏科的情况，特别是对于那些“专门切页面的“和“专门写脚本的“人，毕竟html/css/js三者不分彼此，三者是一个合格前端工程师都必须要掌握的。如果你觉察到自身有偏废的嫌疑，则要小心了，要清楚的了解自身的差距，并意识到瓶颈的存在，为过渡到“中级“的打下基础。

过了这道坎之后，工作3年以上的人大部分技能也趋稳，有些人对前端新技术有钻研，能够熟练应对日常工作，软技能也ok，具备有针对性的“拿来主义“，代码也具有一定的架构性，开始突破“代码民工”的这一层瓶颈，对团队气氛、培训、工作环境有个性化的要求，一般来讲，这种人是典型的具有潜力的“中级”工程师，但很快会遇到职业发展中的第二个技术瓶颈。

有少数工作3年或4年以上，在不断寻求新的技能上的突破，最明显的一点体现是，开始关注“底层协议”，即HTTP、第三方应用、系统对接、制造工具、工作流程等，这时思考的重点已经脱离了“切页面”，变为“出方案“，比如要架设一个站点，能够搭建站点框架，预见站点后续（前端）开发中的所有风险，并一一给出解决方案。项目后续开发遇到问题只要翻阅你提供的“手册”即能找到答案。这种人是标准的“高级”Web前端工程师。

出方案是一件挺难的事情，它要求一个工程师同时具备经验、技术、气场等诸多硬技能。尤其是对技术底子的要求非常高。

【半路出家】

那么，转行做前端的人又当如何呢？其实发展轨迹和科班秀才们非常类似，只是时间跨度可能会长一些，你要花更多的精力、做更多的项目、更多的反思和总结才能理解某个知识点的本质（比如HTTP协议）。当然这只是一般情况。

此外，这些人还需要摆脱很多思维定势的禁锢。这里我推荐大家阅读阿当的《Web前端开发修炼之道》。当然，如果你有一个靠谱的师兄带你入道，自然幸运万倍。

但不管怎样，我始终认为应当秉承兴趣第一的原则，不管你是误打误撞、还是意欲为之，不管你是科班秀才、还是半路出家，兴趣始终应当是第一原则，然后才是你“想做好“。我对自己的要求无法强加于人，所以很多业界大牛在回顾自己成功之路时，提到最多的是：“热爱你的工作、拥抱它给你带来的挑战”。N.C.Zakas曾经这样勉励大家：

“我对Web开发人员最大的建议就是：热爱你的工作。热爱跨浏览器开发带来的挑战、热爱互联网技术的种种异端，热爱业内的同行，热爱你的工 具。互联网发展太快了，如果你不热爱它的话，不可能跟上它的步伐。这意味着你必须多阅读，多动手，保证自己的才能与日俱增。下了班也不能闲着，要做一些对自己有用的 事儿。可以参与一些开源软件的开发，读读好书，看看牛人的博客。经常参加一些会议，看看别人都在干什么。要想让自己快速成长，有很多事儿可以去做，而且付出一定会有回报。“

第三日，幸福感

【先精通十行？！】

兴趣第一，听上去很美，但现实却不总是这么酷。练就了一身本领，那也要找到对口的怪物来打一打才过瘾。

自然，每个人都想做出好东西，每个工程师也都渴求这样的机遇，用层次分明的设计、漂亮优雅的代码、精妙的细节雕琢，做出美观、安全、实用耐用的产品，不过现实是如此残酷，以至于工程师们一直都缺乏对产品的归属感。作为前端工程师，如何才能在江湖中把握住前进方向、步步走高？毕竟，在职位繁杂的大公司，缺乏人性化的工作流程影响着工程师的工作幸福感。产品从设计之初、到技术方案评审、再到实现，处处充满了妥协，大部分产品都是杂交的产物，人与人相互掣肘，每个人都对产品不满意……，大跃进式的敏捷开发早就被证明百害无一利。但，或许这就是成长的代价。年轻的工程师需要更多的了解需求和设计、产品经理更要懂得软件迭代规律。对于前端工程师来讲更是如此，多学习交互设计和UI，多了解网络协议和软件迭代模型，更能帮助前端工程师和需求方沟通、和后台的衔接、以及控制版本的迭代。

说来奇怪，前端工程师不是写html/css/js的吗，搞懂那些边缘知识有什么用？《Web前端开发修炼之道》中也提到，精通一行需要先精通十行。这里我来解释一下原因。

作为交互设计师的下游，前端工程师学需要习设计知识是很容易理解的，因为它能帮助你更准确的理解设计师的意图，在原型不完整的时候也能正确的反馈设计缺陷，将问题阻挡在设计的环节，会大大减少UI bug数量，比如说，设计师会给出理想状态下的容器样式，却往往忽略了文字溢出折行、长连续字符、容器宽高是否适应内容尺寸变化而变化，溢出部分是作截字还是隐藏等诸多细节，因为设计师不懂“边界值测试”的道理，而这些问题往往在测试阶段才被发现，所以，如果能在拿到UI设计稿时就提醒设计师补充完整这些场景，自然减少测试回归次数。

另外，前端工程师必须要了解网络协议，原因很简单，我们做的产品运行在Web上。很多依赖于Ajax的实现，只有前端工程师才会提出实现方案，产品经理不了解技术瓶颈，后台工程师更不会在意客户端的用户体验，举个简单的例子：通过JS实现一个Ajax，如果Ajax抓取的数据源是一个302跳转，则需要在JS程序中多做一些事情，这就需要前端工程师了解一些HTTP协议。应当说，这是很常见的一个场景。

那么，为什么说前端工程师也要关注代码版本控制呢？因为web开发和软件开发本质无异，同样具有迭代周期，需求不是一揽子提完、一口气开发完的，是有步骤的开发，因此，每次上线开发哪些功能、为后续扩展功能留足哪些接口、代码在可扩展和可维护性上应当作哪些考虑……，这些应当是每个工程师关注的事情，所谓迭代就是指这种需求的叠加，这是软件开发的常态，也是web开发的常态，刚开始，前端工程师总会不断抱怨没完没了的需求，代码起初还算干净，但很快就越来越乱，代码的版本管理对于Web前端工程师来说有些困难，这也使得大部分前端工程师很难上档次，从这个角度讲，前端工程师是需要向后台工程师学习的，他们的开发量不比前端少，维护代码的能力要超过前端工程师。另外，对于刚入行的前端工程师，心态要放对，提需求是产品经理的职责所在，整理出有价值的需求是交互设计师的职责所在，将需求作版本控制分步实现是前端工程师的职责所在，前端工程师没必要去抱怨产品经理提一大堆没规律的需求，而更应当去理解需求缘由，将需求提炼成UC（用例），让需求在自己手中可控制。只是多数前端工程师缺乏提炼、整理需求的能力，一味的在接需求，才会搞的手忙脚乱，带着情绪堆代码。

所以，只有练就了一身本领，才会更有目标的去寻找对产品的责任感和对团队的归属感，不要误以为能切出漂亮的页面就是能力的提高，纯粹的写代码每个人都差不多的，要成为合格的工程师，眼界要进一步放开，前端工程师能做的，不仅仅是切页面而已，作一个精品项目，一定不乏专业的过程把控，这也是大多数人最易忽略的地方。

【励志之本】

其实，除了个人需要明确努力的方向，每个人都更渴望身处一个好团队，谁都不希望有猪一样的队友。我们都很羡慕处身这样的团队，可以放心的将精力放在纯粹的技术上，身边每个人都自觉的补充文档注释，代码也层次清晰解偶充分重用率高，精妙的设计实现可以更快的传播，bug得到的改进建议也是务实专业的，技术在这种良性互动中价值倍增。我想这也算是好团队的一种境界了，这有赖于团队成员水平水涨船高。不过，反观Yahoo的成长之路，他们的技术积淀也是靠点滴的积累，其实他们当初的状况不比现在的我们好哪去，10年的进化，才造就了Yahoo技术团队的专业性和Hack精神，我们每个人才刚刚起步而已。为了积攒工作中的幸福感，多付出一些是值得的。

但我猜，你现在的处境一定不会太过乐观，产品乱提需求、一句话的PRD、不被重视，被生硬的当作“资源“……反正，情况就是这么个情况，要么你选择抱怨下去，要么想办法去改变。“积极主动“是源自内心的一种坚韧品质，也是励志之本，有些人在现实中被磨平了理想，有些人却在黑暗森林中找到了方向，这就是犬儒主义和英雄气概之间的差别。这自不必详说，因为这让我想起了“大长今”，这简直就是前端工程师的励志典范：“这是一个可怕的环境，足以消磨任何人的斗志和信念，所有来这里的人都变得麻木和无所作为，‘多栽轩‘恶劣的环境没有改变长今，但长今却改变了‘多栽轩‘所有的人“。

如果你想做到“资深”，就一定要想清楚这一点，因为你是团队的顶梁柱（业务），也是幸福感的源头（士气）。

第四日，架构和伪架构

【代码设计的本质】

读到这里，你不禁会问，前端领域存在“架构师”吗？这个问题会在后面的“码农的宿命”中展开解释。这里先说下代码架构的一些琐事吧。

什么是架构？架构是由“架”和“构”组成，架，即元件，构，即连接件。因此，架构即是将总体分解为单元，然后定义单元之间的连接方式。架构的含义源自禅宗，而禅宗的基本信条则之一就是真理是无法用语言来描述的。这个基本信条有其背景，即语言具有某种抽象性。而人们对这种抽象性的悟道则直接影响对事物的看法，进而决定了对客观世界的分解方法。

而在编程语言中，同样存在这种禅宗所隐喻的悖论。在面向对象的教科书中，通常举一些显而易见的例子，比如“水果”是一个类，包含有苹果、桔子、香蕉等实例，“蔬菜”也是一个类，包含白菜、冬瓜、茄子等实例。这两个类之间并无交集，因此很容易理解。但实际项目中情况要复杂的多，比如两个图书类目“文学”和“历史”，那么“明朝那些事”应当是“文学”类的实例还是“历史”类的实例呢？即一旦用语言说出了某一事物，即人为的割裂了世界，于是就会陷入迷途。这在程序设计领域情况更甚，也是造成混乱的主要根源，也就是说，如果你的程序可扩展性不好，一定是程序作者对“单元”的定义不够准确，即单元的概念之间不够“正交”。而这种架构终是徒有其形，根基不稳。

因此，变量和类的命名才是真正考验架构功力的关键（命名是否准确清晰、单元之间是否有概念重叠或盲区），而和所谓“组合”、“继承”、“桥接”等模式化的“外表”无本质联系。

【伪架构】

实际情况是，程序员早早的就想让自己和“架构”扯上关系，并自封xx架构师。在项目中应用各种模式分层、解耦方法，每个项目都可以产出一套看上去很复杂的“架构图”，感觉很牛逼的样子，没错，实践这些方法论总不是坏事，但世界观才是方法论的基础，只有在概念上对产品模块有科学的定义，方法论便自然形成了，《编程珠玑》中一再提及数据结构就是静态的算法，在Web前端领域亦是如此，在页面的建模过程中，定义分解维度要比分解方法更加基础和重要。我想阿当可以在《Web前端开发修炼之道》的第二版里加上这部分内容。

真正的高手用记事本就能写出高质量的代码、用cvs就能做到完美的版本控制、用字典式的分解就能做好系统架构，我想，这正是剑宗一派的最高境界吧。

第五日：寻找突破

【动心忍性】

技术流派看上去是如此吸引人，高手就像侠客一般，来去如风潇洒自如。但反观自己怎么看怎么没有侠客那股范儿。尽管上文提到了一些道理，了解这些尽管不是坏事，但缺少实践总感觉是纸上谈兵。更何况，日常的工作又是枯燥无味、繁杂单调。每个人都盼望更高的目标、接触新鲜技术、将新技术运用到日常，在探索尝试之中寻找成就感。这种感觉可以理解，但却缺少更深层次的思考。因为越到最后越会发现一线的工作才是最有挑战的。当然，我说这话的前提是，你能如前文所说具备合格的软技能，需要一些技巧让工作变得工整有序、节奏健康，这样你才能将注意力放在纯粹的代码中，摆脱了外界的烦扰，方能从技术的角度思考突破。这也是从初级到高级的进化过程需要大量的历练的原因。正如玉伯所说，“枯燥是创新的源泉。如果你发现自己没什么新想法，做事缺少激情，很可能是因为你还未曾体验过真正的枯燥的工作”。

关于如何寻找突破，我的建议是马上动手做、不要等，相信自己的直觉（这里和上文提到的先思后行是两码事）。比如，Slide幻灯控件理应支持触屏事件以更好的适应移动终端，或许你在用的Slide幻灯版本很旧、或者时间不允许、再或者你害怕对Slide改造而引入bug，不要担心，大不了多花业余时间，只要想，只要感觉合理和必要，就去做。因为这个过程带来的编程体验才是工程师们独有的美妙体味。我现在还时常深夜写代码，没有打扰、思如泉涌、代码也更加工整严谨，不失为一种享受。因此，用眼睛去观察，用心去感触，“所以动心忍性，才会增益其所不能”啊。

【得与失】

互联网的发展的确太快，Web前端技术也在花样翻新，有人经不起诱惑，开始做新的尝试。前端技术虽然范围广，但各个分支都还比较容易入门，比如服务器端脚本编程、再比如纯粹的WebApp，我认为这两者都是前端技术的范畴，毕竟他们都没有脱离“浏览器”，或者说类似浏览器的环境。NodeJS依赖于V8，WebApp更是软件化的WebPage。只要打好基础，这些方向都是值得深入钻研的，因为，互联网的形态越发多元，新的技术总能找到用武之地，这就要凭借自己的技术嗅觉和产品直觉，寻找技术和业务的契合点。

这看上去是一种放弃，放弃了自己赖以生存的铁饭碗（熟练的切页面至少不会失业），实则不然。这种想法是一种误区，新的选择并不会让你放弃什么，就像学会了开车，并不意味着就不会骑车了。其实改变的是思维方式而已，是一种进步，如果你能想通这一点，你也能跟得上互联网发展的脚步了，打开你的思维，让技术变成你的金刚钻，而不是包袱。

所以，所谓得失之间的权衡，其实就是“解放思想”。做到了这一点，那么你已经在做“技术驱动”了。

【误区】

但是，不要高兴的太早，“技术驱动”是需要大量的积累和经验的。在入行初期，很多人过于着迷与此，从而陷入了迷途。比如有人纠结于是否将dt、dd的样式清除从reset.css中拿掉，原因是觉得这两个标签的清除样式会耗费一些渲染性能；或者是否需要将for循环改为while循环以提高js执行速度。尽管这些考虑看上去是合理的，但并不是性能的瓶颈所在，也就是说，你花了很大力气重构的代码带来的页面性能提升，往往还不如将两个css文件合成一个带来的提升明显。就好比用一把米尺量东西，没必要精确到小数点后10位，因为精确到小数点后2位就已经是不准确的了。这种技术误区常常让人捡了芝麻丢了西瓜。

话说回来，这里提到的怀疑权威的精神是绝对应当鼓励的，但不应当止于表象，如果怀疑dt的清除样式会对性能带来影响，就应当想办法拿到数据，用事实来证明自己的猜测。数据是不会骗人的。而求证过程本身就是一种能力的锻炼。

【技术驱动】

说到这里，你大概对“技术驱动”有那么一点点感觉了。身边太多人在抱怨“公司不重视前端”、公司不是技术驱动的、技术没机会推动产品业绩、我的价值得不到体现？

什么是技术驱动？简单讲，就是技术对业务有积极推动作用。更多的是工程师发起、工程师影响、工程师负责。刚才提到的用数据说话只是一种“驱动”技巧，那么我需要何种数据，数据从哪里来？我来分享一个实际的场景吧。

工程师A被委派一个重要的频道首页，因为是新年版，所以要赶在年前上线。A学了一点点响应式设计，想在这次重构中加上，但谁也没做过响应式设计，需求方根本不懂，设计师也懵懵懂懂，交互设计师太忙，做完交互稿就忙别的去了。A纠结了，按部就班的把项目做完上线发布，尽管不会出什么问题，但总觉少点什么。这时A做了两个决定，1，我要按时完成项目，2，趁机实践我在响应式设计中的想法和思考，若成功，作为附加值赠送给需求方，若失败，权当技术玩具耍一耍罢了。所以A熟练的提前完成了项目，剩下的时间开始考虑如何将首页适应到各个平台中，视觉设计是一大难题，他用吃饭的时间找了设计师收集建议，对窄屏中的内容模块做了看似合理的编排，代码上hack一下，能够正确适配，就发布上线了。这件事情需求方不知道，视觉设计师也不了解，交互设计师更没工夫操心。A感觉挺爽，开始给工程师弟兄们到处炫耀这个好玩的功能，B看了问，手机端访问量如何，A觉得这个问题有道理，就去部署埋点，一周后拿到数据出奇的意外，首先，移动段的访问量稳步增加，趋势健康，再者，移动端首屏焦点广告位的点击率较PC端高了近一倍，这个数据让A喜出望外，兴奋的拿着报表找到交互设计师C和市场研究的同事D，D看了报表之后立即启动一个项目，专门调研公司全站响应式设计页面在PC端和移动端的点击率、PV、UV趋势方面的影响……后来发生的事情就都水到渠成了，设计师C开始注意设计页面交互时（至少是有条件的考虑）对移动端的适配，D的调研报告也放到了UED老大的案头……接下来的事情，你懂得。A被指派要出一套响应式最佳实践和规范，最终，A走在了技术的前沿，也因此拿到了好绩效。

这件事情就是一个典型的技术驱动的例子。谁不让你玩技术了，谁不重视你了，谁把你当工具了，谁觉得你的代码没价值？这世界只有自己把自己看扁，谁想跟你这个蝇头小卒过不去？用实力说话，用数据说话，用独到的见解说话，想不做技术驱动都难。

第六日：码农的宿命

【青春饭】

“码农”是IT从业者一个自嘲的称号，也有从事没有发展前景的软件开发职位，靠写代码为生的意思。但我认为码农是一个爱称，编码的农民，和农民一样有着执着纯真朴实豪爽的共性，仅仅分工不同而已。就好比农业社会对粮食的依赖，工业化进程对计算机应用也有着很强的依赖，大量的需求催生出这样一群人。他们有智慧的大脑，对于编程，设计，开发都有着熟练的技巧，但多数人看来，码农的特点是：

1，收入低

2，工作单调

3，工作时间长

实际上这个描述非常片面，或者说是外行看热闹。第一，全行业比较来看，软件开发领域收入为中等偏上；第二，程序员一般都是有癖好的，沉浸在自己的癖好中是不会感觉单调的；第三，程序员有一定的时间自由度（如果你是一名合格的程序员的话），至少不会像流水生产线工人一样。其实，通过几十年的发展，我们对程序员的定义更加科学，比如很多IT企业都开始建立详细的JM（Job Module），即职级模型，程序员沿着专业方向可以走到很高，甚至可以说，程序员是可以被当成一生的事业的。

然而，有一个非常普遍的观点是，程序员和做模特一样是吃青春饭的，到了三十岁就要考虑转行或者转管理。尽管这种观点颇具欺骗性，但至少它对一种人是适用的，即入错了行的人。如果你骨子里不想写程序，就算年纪轻轻为了生计写几年代码，之后肯定会另有他途。心非所属则不必勉强，但问题是，即便如此，你知道你的心之所属吗？

我们知道，一个成熟的产业一定需要各色岗位来支撑，若要成熟，则需要时间的沉淀，比如实体经济制造业，创意、生产线、高级技工、技术管理四个方面都产出大量的高级人才。因为历史悠久，我们能看得到。而软件产业则不然，九成以上是刚出道的新手，并没有太多“高级”和“资深”的具体样板可供参照，在前端开发领域中情况更甚，绝大部分人根本搞不清楚什么样才是“资深”前端工程师，相比传统软件行业近四十年的进化，我不相信仅有几年光景的前端技术岗位能产出多少货真价实的“资深”。但互联网崛起速度太快，还没有等技术基础打牢，互联网形态就又花样翻新了，这种变化是一种常态，而岗位的设定也在这种变化之中自然的优胜劣汰，比如两年前可能还难以想象数据部门会需要前端工程师，他们甚至不直接和浏览器打交道。前端工程师需要适应这种变化带来的观念冲击，不要以为自己只能做切页面、或者只会给页面搞重构、只会搞兼容性，要把自己放在整个软件行业来看。

所以，由于历史“不悠久”导致的岗位模糊本身不是什么大问题，岗位的演化本身就包含在互联网的发展轨迹之中。所以，当今的互联网IT状况，就好比移动终端的大哥大时代、云计算的肉鸡时代、或者桌面操作系统的DOS时代。因此，前端工程师当前要务是要想清楚看清楚，在互联网中我能做什么，而不是作为前端工程师我能做什么，所以，从这个角度讲，技术是一个工具，放大来看，技术也只是你职业生涯中很小的组成部分，而你的从业积累、和知识面的广度深度才是你随着时间的推移慢慢步入“资深”的原因所在，而不是写了个什么框架就变“资深”了。如果有一天互联网形态固定了，它的岗位可能真正就定型了，才会有真正清晰的职能边界，就像蓝色巨人IBM中的各色岗位一样，边界清晰，权责分明，普通程序员只能实现接口而无机会设计接口、低层级的工程师也无机会跃进式的接触项目架构、技术经理人也不能轻易对产品有决策性影响，到这时，人的能力才真正的被限制在方圆之内，容不得越界，这种环境下人的成长非常缓慢。根本不会有像今天互联网乱局之中所提倡的创新、革命、成长和思想解放。简单讲，一旦产业定型，就不太需要很多“创造”了，更多的是“维护”。所以，我个人宁愿互联网IT“黑暗”的中世纪越久越好，至少对于年轻气盛程序员来说，黑暗的丛林环境才是真正的自然进化最理想的土壤，这时我想起了狄更斯在“双城记”中的开篇。

“这是最好的时代，这是最坏的时代；这是智慧的时代，这是愚蠢的时代；这是信仰的时期，这是怀疑的时期；这是光明的季节，这是黑暗的季节；这是希望之春，这是失望之冬；人们面前有着各样事物，人们面前一无所有；人们正在直登天堂，人们正在直下地狱”。

【半路出家的危与机】

然而，不管怎样，信心的树立不是一蹴而就的，对于转行做前端的人来说更是如此。俗话说，隔行入隔山。每个行业自有其道，自然不是想做就做。前端技术领域半路出家者非常多，我们来分析一下转行的心理。第一，看到前端技术入门简单、互联网对前端技术的需求缺口巨大；第二，前端技术所见即所得、感觉学习起来很快；第三，我身边的某某转行作前端看上去不错、我似乎也可以；第四，我不喜欢我现在做的工作、想换行业、正好前端技术上手较快，就选他吧；第五，我真的喜欢做Web前端，为它付出再多都是值得的。

转行者的心态比较容易走两个极端，一是只看到新行业的好，二是只觉得原工作很糟糕。但不管是什么行业的转行，对自己的职业规划的思考都应当先行一步。即务必首先清晰的回答这些问题：

1，我能做什么？

2，我不能做什么？

3，我的优势是什么？

4，我的劣势是什么？

5，做新行业对我有何好处？

6，换行会让我付出何种代价？

7，如何定义转行成功？

因为面试的时候一定会被这些问题所挑战。如果支支吾吾说不清楚，要么是对自己未来不负责任，要么骨子里就是草根一族，习惯做什么都蜻蜓点水浅尝辄止，也难让人信服你的转行是一个权衡再三看起来合理的选择。我无法帮每个人回答这些问题，但至少有两点是确定的，第一，Web前端技术是一个朝阳行业，绝对值得义无反顾的坚持下去；第二，你将经历从未有过的枯燥、苛刻的历练，所谓痛苦的“行弗乱其所为“阶段。不过话说回来，经历过高考的人，还怕个屁啊。

有心之人自有城府、懂得放弃，看得清大势中的危机、识得懂繁华里的机遇。尤其当立足于Web前端技术时，这种感觉就愈发强烈。因为国内外前端技术领域从2000年至今一直非常活跃，前端技术前进的步伐也很快，对于一些人来说，不管你是在大公司供职还是创业，不管你是在接外包项目还是自己写开源项目，从转行到跟得上新技术的脚步是有一些方法和“捷径”的。

第一，梳理知识架构

我们知道知识积累有两种思路，第一种是先构建知识面、建立技术体系的大局观，即构建树干，然后分别深入每一个知识点，即构建枝叶，最终形成大树。第二种是先收集知识点，越多越好，最后用一根线索将这些知识点串接起来，同样形成大树。第一种方法比较适合科班秀才，第二种方法则更适合转行作前端的人，即实践先行，理论升华在后。比如对“IE6怪异模式“这条线索来说，要首先将遇到的IE6下的样式bug收集起来，每个bug都力争写一个简单的demo复现之，等到你收集到第100个bug的时候，再笨的人都能看出一些规律，这时就会自然的理解IE的hasLayout、BFC和各种bug的原因、你就成为了IE6的hack专家了，当你成为100个知识线索的专家的时候，你已经可以称得上“资深”的水平了。我们知道，10个人中有9个是坚持不下来的，他们会以项目忙等各种理由万般推托，将自己硬生生的限制在草根一族，坐等被淘汰。所以，对于立志作前端的人来说，这种点滴积累和梳理知识非常重要。

第二，分解目标

将手头的工作分解为几部分来看待，1，基本技能，2，项目经验，3，沟通能力，4，主动性和影响力。想清楚做一件事情你想在哪方面得到历练，比如，我之前在做第一次淘宝彩票常规性重构的时候（正好是一次视觉和交互上的全新设计），我清楚的明白这次重构的目的是锻炼自己在架构准富应用时的模块解偶能力，寻找在其他项目中架构的共通之处，所以我宁愿加班或花更多精力做这个事情，当然更没打算向业务方多解释什么，这件事情对我来说纯粹是技能的锻炼。而经过这一次重构之后，我意外的发现对业务的理解更透彻深入、更清晰的把握用户体验上的瓶颈所在。如果一开始就把这次常规改版当成一个普通的项目按部就班的做，我只能说，你也能按时完成项目，按时发布，但真真浪费了一次宝贵的锻炼机会，项目总结时也难有“动心忍性”的体会。

所以，每个项目的每个事情都应当认真对待，甚至要超出认真的对待，想清楚做好每件事对于自己哪方面有所提升？哪怕是一个bug的解决，即便不是自己的问题也不要草草踢出去了事，而是分析出问题原因，给出方案，有目的involve各方知晓……，正规的对待每个不起眼的小事，时间久了历练了心智，这时如果突然遇到一个p0级的严重线上bug（比如淘宝首页白屏，够严重的了吧）也不会立即乱了方寸，这也是我上文提到的心有城府自然淡定万倍，而这种淡定的气场对身边浮躁的人来说也是一种震慑和疗伤，影响力自然而然就形成了。

第三，作分享

做分享这事儿真的是一本万利。有心的人一定要逼着自己做分享，而且要做好。首先，自己了解的知识不叫掌握，只有理解并表达出来能让别人理解才叫掌握，比如如果你解释不清楚hasLayout，多半说明自己没理解，如果你搞不懂双飞翼的使用场景，可能真的不知道布局的核心要素。再者，作分享绝对锻炼知识点的提炼能力和表达能力，我们作为工程师不知道多少次和强硬的需求方pk，被击败的一塌糊涂。也反映出工程师很难提炼出通俗易懂的语言将技术要点表述清楚。而做ppt和分享正是锻炼这种能力，将自己的观点提炼出要点和线索，分享次数多了，自然熟能生巧。档次也再慢慢提高。另一方面，逼迫自己站在公众场合里大声讲话，本来就是提高自信的一种锻炼。

这时，你或许会问，我讲的东西大家都明白，我讲的是不是多余，我第一次讲讲不好怎么办，大家会不会像看玩猴似的看我“这SB，讲这么烂还上来讲”？要是讲不好我以后再讲没人听怎么办，我今后怎么做人啊？

老实说，这是一道坎，任何人都要跨过去的，谁都一样，你敢鼓起勇气在大庭广众之下向爱人表白，就没勇气对自己的职业宿命说不？其实勇敢的跨越这一步，你会意外的收获他人的掌声和赞许，这些掌声和赞许不是送给你所分享的内容，而是送给你的认真和勇气。这个心结过不去，那就老老实实呆在自己的象牙塔里遗老终生，当一辈子工程师里的钻石王老五吧。

【匠人多福】

如果你能耐心读到这里，心里一定有一个疑问，上面说的都是技术上能力上怎样怎样，那我所做项目不给力又当如何？如果项目不挣钱、黄了、裁了，我的努力不就白费了吗？我又有什么绩效和价值呢？

没错，有这种想法的人不在少数。特别是刚出道的校招同学往往更加心高气傲，以为自己有改变世界的本事，一定要参与一个牛逼的团队做一款光鲜靓丽受人追捧能给自己脸上贴金的项目。如果你有这种想法，趁早打消掉这个念头，当然，我们这里先不讨论创业的情形。

第一，如果你刚毕业就加入一个牛逼团队，说难听点，你就是团队中其他人眼中的“猪一样的队友”，不创造价值且拖项目后腿（显然大家都要照顾你的成长啊），按照271理论，你没有理由不是这个1。至少相当长一段时间内是这样。

第二，你在所谓牛逼团队中的创造性受限，因为创新多来自于团队中的“资深“和大牛们，你参与讨论但观点通常不会被采纳，他们只会给你这个菜鸟分活干，想想看，你如何能花两到三年就超越身边的大牛们？甚至连拉近与他们的距离都难。

第三，如果身在牛逼团队，自然心理对周围的牛人们有所期待，希望他们能灌输给你一些牛逼的知识和牛逼的理念。这种思想上的惰性在职场生涯之初是非常危险的。要知道技术和知识本身是很简单和淳朴的，只不过披上了一个光鲜项目的外衣而让人感觉与众不同。

第四，由简入奢易，由奢入简难，做过一个看似光彩的项目，心理再难放平稳，去踏实的做一个看上去不那么酷的产品。这种浮躁心态会严重影响今后的职业发展和成长。

第五，光鲜靓丽的项目被各种老大关注，是难容忍犯错误的，傻瓜都知道犯错误在成长之初的重要性。

就我所看到的情形看，一开始加入看似很牛的项目组，三年后得到的成长，比那些开始加入一个不被重视的项目的同学要小很多，而后者在能力上的弹性却更大。所以，道理很简单，你是要把一个很酷的项目做的和之前差不多酷，还是把一个不酷的项目做的很酷？项目是不是因为你的加入而变得与众不同了？

从这个角度讲，不管是转行的新人还是刚出道的秀才，最好将自己当作“匠人”来对待，你的工作是“打磨”你的项目，并在这个过程中收获经验和成长。付出的是勤奋，锻炼的是手艺，磨练的是心智。因此，你的价值来自于你“活儿“的质量，“活儿”的质量来自于你接手的项目之前和之后的差别。做好活儿是匠人应有的职业心态。想通这一点，内心自然少一些纠结，才会对自己对项目的贡献度有客观的认识，不会感觉被项目所绑架。

做一名多福的匠人，拥有了金刚钻、就不怕揽不到瓷器活儿。但对于人的成长来说，如果说“项目”重要但不关键，那么什么才是关键呢？这个话题还会在接下来的“伯乐与千里马”这篇中给出答案。

【若干年后】

现在，让我们回过头回答一下“青春饭”的问题。在“青春饭”小节中提到，“程序员到三十岁之后需要转行或者转管理吗？”

上文提到，工业化生产的四个领域，1，创意，2，生产线，3，高级技工，4，技术管理。Web前端技术也是如此，可以在这四个领域找到各自的归宿。

第一，“创意“

即和产品需求越走越近，拥有良好的产品感，对产品需求、设计交互把握准确，能够用适当的技术方案推动产品用户体验，属于“架构师”的范畴，因为职能更加靠前，偏“出主意”型的。这种人更贴近用户，需要活跃的思维、广阔眼界、厚实的项目经验。更多的影响产品体验方面的决策。

第二，“生产线“

即前端基础设施建设，优化前端开发流程，开发工具，包括开发环境、打包上线自动化、和各种监控平台和数据收集等，属于“技术支持”的范畴，相比于很多企业粗犷难用的平台工具，前端技术方面的基础设施建设基础还需更加夯实，因为这是高效生产的基本保证。

第三，“高级技工“

即高级前端开发工程师，专职做项目，将产品做精做透，用代码将产品用户体验推向极致，偏“实战”型的，是项目的中坚力量，直接产出成果，影响产品效益。属于项目里的“资深”。

第四，“技术管理“

即做技术经理，这才是多数人所理解的“管理”，其实就是带团队、靠团队拿成果。这类人具有敏感的技术情结，在技术风潮中把握方向，能够指导培训新人，为各个业务输出前端人才，偏“教练”型的，促进新技术对业务的影响。并有意识的开辟新的技术领域。

可见，转管理可不是想当然，也不是所谓做项目变资深了就能转管理，转了也不一定能做好。根据“彼得原理”，即人总是倾向于晋升到他所不能胜任的岗位，这时就又陷入“帕金森”定律所隐喻的恶性循环之中，直到你带的团队整个垮掉。

所以，转管理应当是一件非常慎重的事情，不是所谓程序员混不下去就转管理这么简单。但不管怎样，有一件事情是需要尤其要想清楚，即，转了管理，技术就丢了吗？我们在第七日“伯乐与千里马”中再深入聊聊这个事儿。

第七日，伯乐与千里马

【师兄们的抉择 1】

千里马常有，而伯乐不常有。——韩愈，“马说”。

一个人这辈子能遇到一个好师兄是一种缘分，可遇不可求。很多人工作中的幸福感似乎也源自这种被认同，被师兄的了解和认同，有人能直言不讳的指出你的不足，帮你发现机会，并将最适合你做的事情分配给你，这是莫大的幸运，但如此幸运的人十之一二，大多数人因为缺少伯乐的提点，渐渐辱于“奴隶人之手“，潜力渐失，毁于中庸。

在前端技术领域，这种情况很普遍也很特殊，当然有很多客观原因。即前端技术进入公众视野时间不长，有实力的伯乐更加是凤毛麟角。更何况，Web前端技术还有着一些江湖气，知识点过于琐碎，技术价值观的博弈也难分伯仲，即全局的系统的知识结构并未成体系，这些因素也客观上影响了“正统“前端技术的沉淀，奇技淫巧被滥用，前端技术知识的传承也过于泛泛，新人很难看清时局把握主次，加之业务上的压力，未免过早导致技术动作变形。而这些问题也无法全赖自己全盘消化，若有人指点迷津，情况要好上万倍。因此，前端技术领域，为自己觅得一个靠谱的师兄，重要性要盖过项目、团队、公司、甚至薪水。

这也是上文所说的“项目不重要，师兄才重要“的原因。说到这里就有一个问题，每个人都问下自己，你是想当师弟呢还是想当师兄呢？当师兄有什么好处呢？

没错，很多师兄都是被师兄，甚至没有做好当师兄的准备，更进一步说，不少经理人也都是“被经理人“，没有做好准备就被推到了管理岗位。带人是耗精力的，师兄要做很多思想斗争才舍得把这些宝贵的精力放在那些菜鸟身上，这不是一个技术问题，而是一个道德问题。要记住，没有谁应该无缘无故把自己所掌握技能给你倾囊相授，如此皆命也。读到这里，作为菜鸟，作为学徒，作为新人，作为师弟，你做到对这份命运的足够尊重了吗？

尊师重教的传统美德并没有在技术领域得以很好的延续。也正因为此，人才梯队难建立起来，但对于师兄来说，却是有更多机遇的。

【师兄们的抉择 2】

作为师兄，不管是主动还是被动，肯定会想当师兄对我有什么提升？对于初次做师兄的人来说，最大的提升在于两方面，1，任务分解，2，问题分析。

第一，任务分解，作为师兄要给师弟派分任务，就涉及到任务分解，分解这事儿往低了说，就是派活，往高了说，其实就是做“架构”，比如一个页面，按照什么思路进行模块划分，模块划分是否适合单人开发，如何控制共用样式和共用脚本，我需要为他提供什么接口，如何控制他的代码并入整个页面时不会影响整体页面代码的熵值，这些都是实打实的“架构“应该包含的问题，而从小页面开始就做这种锻炼，做的多了，“架构感”自然就形成了。

第二，问题分析，在之前自己写代码都是单打独斗，什么都是用代码解决问题，但一旦涉及协作，就要强迫自己分析问题，或者说给徒弟分析问题，告诉他应当用什么方法来解决问题，当说到“方法”时，脑子里定形成了一个方案，按照这个方案路子走一定能解决问题。分析问题比写代码要更抽象、更高效，因为在脑子里构建方案要比写代码要快，思考也会更加缜密，当锻炼的多了，思考越来越快，代码的草稿也很快就在脑海中形成了，这也是我们说为什么很多人不写代码但编码思路和水平都很高的原因。

这些工作方法对了，积累多了，就是提高。对于技术经理人来说，也是同样的道理。所以，就像在第五日的“得与失”部分提到的那样，转身师兄、变身管理并不意味着“失“掉技术饭碗，而是一种进步。

【做自己的伯乐】

那么，在前端技术领域里什么样的人才算千里马，其实人人都是千里马，人人都可以发掘自己的潜力，如果上面的文字你能读懂，能认可，这种自我发掘已经开始了，没有一个好伯乐又何妨呢？做一个勤快的小码农，少一些势利的纷争，很快会发现，自己才是最好的伯乐。

但这并不是说，他人对自己的观点不重要，有时甚至要综合各种声音，所以，多找身边的大牛们聊聊天，多找你的师兄和主管，不管他们给你的建议是多么形而上，总有一些声音对你是有益的，多收集，有好处。

第八日，做地球上最牛的UED

【谁推动了历史前进，英雄？还是人民？】

“做地球上最牛的UED！”，这是淘宝UED创立之初的口号，现在被渐渐淡忘了，因为微博上的一些讨论，又想起了这份曾经美好的初衷。玉伯也感叹道：“这愿景曾吸引了多少好汉前往投奔呀。只可惜短短几年间，这愿景好像越来越远了”。问题是，要做好一个团队，靠的是个人、还是整体？愿景是越来越远了吗？

是谁推动了历史的前进，是英雄？还是人民？微观来看，是英雄，宏观来看，是人民。再放大了看，是互联网大潮之崛起推动了前端技术的进步，时势需要UED、需要用户体验。

所以，UED团队的创立发展受这些积极的外因影响，赶上了好时候，成员也跟着沾光。然而，我并不关心这个口号，我只关心体制内的关键人物，那些带动整个团队水涨船高的人们。往往我们发现，某些人的高度代表了整个团队的高度，个体的影响力代表了整个团队的影响力，某个人的水平代表了整个团队的水平。支付宝、淘宝、腾讯、百度、盛大，都是如此。而我们作为普通的个体，正是要励志成为这种人，成为真真用技术推动用户体验前进的尖刀人物。

这时我想起了很多人在知乎上的问题，关于跳槽、关于转行、关于创业、关于各种UED团队。我想，读得懂我上面的文字，你心理也许会有自己的答案。

【归宿】

最后，还有一个不得不说的问题，即归属问题，前端开发应当归属于UED还是技术部门？应当说，当前Web前端技术的价值体现在“用户体验“上。是用户体验这块阵地最后一道坎。也就是说，前端工程师应当重点考虑我所作的页面的感官体验。这是需要一些灵感和感性的，应当看到帅气优雅的界面会心有所动、或者实现一款精巧的小组件时萌生一阵快意。这种所见即所得的美妙编程体验正是其他后端工程师无法体验到的。因此，这种精确到像素级的精工雕琢虽然不直接决定产品生死，但却是提升产品品味和时尚感的要素。物质越来越丰富的今天，大众的更高诉求不就是品味和时尚吗？

如果将前端归到技术部门，一方面和“设计“离的更远，代码写的规规矩矩但渐缺少了灵性，另一方面作为工程师又缺少计算机专业课的功底，才真正丧失了优势所在，如果有一天，前端工程师的平均水平足够高，清一色的计算机科班出身，似乎更合适归入到技术部门。所以，Web前端工程师是“工程师“，需要科学严谨的编程能力，但身处UED所应当具备的美感和灵性是万不可被剥夺去的。

还有一点，Web前端工程师作为UED之中最具实践精神和逻辑思维的工种，是能够将技术对设计的影响发挥到最大，可以催生出大量的创造和革新的，这一点也是传统后端工程师所不具备的。

第九日，前端技术体系

现在越来越感觉到前端技术需要成体系的积累，一方面可以规范我们的前端技术培训，另一方面，作为知识线索为新人做指引，省的走弯路，避免陷入奇技淫巧的深坑之中不能自拔。

之前我整理了一下“前端技术知识结构”，罗列的比较散，但也基本表述清楚了我的观点。今年上半年也在整个研发中心组织了一次前端技术培训，对于前端技术的演化规律也有过整理，都放在了这个ppt中，希望对大家有所帮助。

概观国内前端技术界，其实我不认为和国外顶尖的前端技术有多少年差别，甚至很多方面都走在了他们前面，比如对IE6暴力式的兼容，以及各种外壳浏览器的风靡（呵呵，开玩笑哈）。唯一的美中不足是国外顶尖的前端技术很难第一时间就在国内普及，可能是两方面原因，一是多数人英文底子很差，这可是个大问题啊。二是国内前端技术方面高质量的译文图书实在是少的可怜。那么…

为纪念中央红军长征“乌江天险重飞渡兵临贵阳逼昆明”段 90 周年，追寻革命先辈艰苦卓绝的光辉历程。“乌江天险重飞渡兵临贵阳逼昆明”段长征研学会倡议和发起了开展庆祝“红军长征途经我的家乡90周年”纪念活动。通过活动，力争把“乌江天险重飞渡兵临贵阳逼昆明”这一段的红军故事挖掘出来，宣传出去。把"乌江天险重飞渡兵临贵阳逼昆明"段既凶险又传奇，既险恶又成功的长征征途创建成新时代新长征路上的历史传承路、红色文化路、灵魂精神路、绿色生态路、金色致富路。

活动行程如下:

第一站时间:2025.3.30-31地点:沙土 第二结时间:2025.4.8笔点:龙里

第三站时间:2025.4.9地点:青岩 第四站时间:2025.4.10-11笔点:马铃

第五站时间:2025.4.13-15地点:紫云 第六站时间:2025.4.16-17地点:弄染

第七站时间:2025.4.26上午 笔点:贞丰第八站时间:2025.4.26下午地点:兴义第九站时间:2025.4.27地点:由靖

期待您的参与，共同担起"乡村振兴"和"民族复兴"的历史重任，为实现"中国梦"作努力!此致，敬礼!

“乌江天险重飞渡兵临贵阳逼昆明”段

长征研学会2025年3月19日