前端开发的工程之美

回顾一年的开发实践，有三个概念的轮廓越来越清晰：技术、工具、工程。理清这三者的关系，才能找准自己的定位与发力点。

纯粹的技术，可以近似理解为规范——HTML/HTML5、CSS/CSS3、Ja vaScript这类语言规范，以及各家浏览器的具体实现。而工具，则是在技术之上封装出来的各种通用库和框架，比如jQuery、Backbone、RequireJS等等。那么，如何看待这两者呢？技术无疑是地基，必须扎实。工具则更像“说明书”，照着用就能快速上手，但不必过于执着，否则很容易触到成长的“天花板”。有趣的是，技术和工具常常被混淆，例如简历上那句经典的“精通xxx”，后面跟着一串工具名，乍一看颇具威慑力。可惜，实战中的笔试题，往往能揭示出技术掌握的实际情况。

至于工程，简单说就是一个产品的完整开发过程。与技术、开源工具的普适性不同，每个产品的开发流程都有其独特的工程特性。正确的思路应该是：从具体的工程需求出发，去设计工具链和代码架构。反过来，如果看到一个“时髦”的工具就盲目引入，往往无助于达成工程目标，甚至会让事情变得更复杂，适得其反。要知道，所有开源工具都源于作者解决自身实际问题的需求，需求不同，工具的适用性就需要我们审慎掂量。

一切都要以工程需求为出发点。话说回来，记得我刚加入豆瓣时，也曾急于推动建立一个统一的UI库，但最终效果并不理想。现在看，UI库的方向没错，但作为切入点，时机早了。应该首先沉下心来分析：我们产品前端开发最核心的工程需求究竟是什么？

以我这一年的工作为例，工程上就呈现出两个显著特点：快速迭代和多版本并存。硬件开发追求完美，是因为犯错的成本太高。相比之下，Web产品则幸运得多——任何问题都可能在下次上线时得到修正。所以，对于Web开发而言，工程上的关键问题其实是：迭代的轮子，转得够不够快？而限制速度的主要瓶颈，往往就是代码的维护难度。

如何把维护难度降下来？这涉及到代码质量、复杂度、业务耦合度等多个因素。关于代码质量控制，第一步是建立规范、统一风格，在此之上可以引入自动化检查工具，当然，人为的Code Review也必不可少。至于如何控制单位模块的复杂度、实现解耦，这就和代码的组织方式紧密相关了。可以说，组织方式是目前前端开发领域的一个重要议题，社区里热议的AMD、包管理工具、自动化构建工具，都是为了解决这个环节的问题，其灵感也多源于Ja va、Ruby、Node.js等后端语言。那么，该如何选择或决定是否自研工具呢？答案依然要回到具体的工程需求上去找。

来看一个实际案例：临时在全局导航栏上加一个用户提示框。单纯从技术实现看，这事儿毫无难度，但放到工程维度，就没那么简单了。你可能会面临下面这些状况：

1. 导航栏是跨产品线共用的。

2. 各产品线的代码可能位于不同的代码仓库。

3. 这个提示框是临时的，需要快速上线和下线。

4. 它只对首次注册的新用户展示。

5. 它还存在多个测试版本。

如果再赶巧导航栏本身正在进行A/B测试，情况就更复杂一些了。

如果用传统方式处理，大概是这样的：

1. 虽然导航模块是全局的，可以把提示框的HTML片段写进去，但相关的CSS和JS需要分别部署到全局的样式文件和脚本文件中。这就带来一个问题：模板里可以判断是否展示提示框，但CSS和JS无法做条件判断。等到提示框要下线时，开发者得翻遍三个文件去找代码删除。

2. 如果一些产品线位于独立的代码仓库中，那么上述所有麻烦都要重复一遍。

3. 假如类似的临时需求多起来，维护成本会直线上升。

4. 在提示框不显示的情况下，与之相关的CSS和JS代码就成了全局文件里的冗余。

5. 如果需要维护多版本，复杂度还会成倍增加。

类似的场景在实际开发中相当普遍。靠加人手来解决吗？随着需求增长，人力永远会不够用。我们最终选择和工具团队合作，通过对模板系统进行改造，比较完美地解决了这个问题。

新方案下，提示框被定义为一个独立的模块文件，内部自包含了所需的HTML、CSS和JS代码。在其他模板中引用这个模块后，渲染时模板系统会自动完成以下处理：

1. 收集：将页面所有模板中用到的CSS和JS分别收集起来。

2. 去重：自动去掉重复引用的部分。

3. 生成：动态生成最终的外部引用文件。

这样一来，当模块被使用时，相关代码会自动并入外部文件；当模块被移除时，相关代码也随之被清除，管理起来异常方便。实际效果，不妨去看看豆瓣首页的网页源代码，就能一目了然。