前端开发的工程之美

前端开发的工程之美


总结一年的工作心得，三个概念越来越清晰：技术、工具、工程。搞清楚才知道空白、着力点在哪里。

纯粹的技术约等于规范，HTML/HTML5、CSS/CSS3、Javascript之类的语言规范，以及浏览器的具体实现。工具是技术之上封装的各种通用库和框架，比如jQuery、Backbone、requireJS等等。对待技术和工具，技术自然是最基础的，工具是照着“说明书”就可以很快上手，对工具不必太执念，否则会很快遇到成长的“天花板”。技术和工具很容易混淆，例如在简历上常常可以看到精通xxx，后面一串工具名，确实很唬人。可惜我们的笔试题会揭穿他们对技术掌握程度的真实情况。

工程简言之是一个产品的开发过程。与技术、开源工具所具有的通用性不同，每个产品的开发过程都有其工程上的特点。从工程需求出发，设计工具链、设计代码架构才是正确的思路。相反，看到一个“时髦”的工具就加进来，不能更好达到工程的目的，甚至复杂化，事得其反。所有开源工具都源于作者的实际需求，需求不同，工具的适用性不同需要审慎考量。

工程需求是出发点。记得我刚来豆瓣时，便急于想建立一个UI库，最终的效果并不好。UI库的想法是对的，但做为切入点早了。应该首先分析产品前端开发的工程需求到底是什么。

以我今年的工作为例，工程上有两个显著特点：快速迭代和多版本并存。硬件要追求完美，是因为它犯错的代价太大。web产品相比，可以及时在下一次上线中得到修正。所以对于web开发，工程上的关键问题其实是：迭代转的是不是足够快。代码的维护难度是主要限制条件。

如何把维护难度降下来。维护难度跟代码质量、复杂度、业务耦合度等因素相关。关于代码质量控制，首先建立规范统一代码风格，在此之上可以有自动化的检查工具，同时离不开人为的code review。控制单位模块的复杂度和解耦跟代码组织方式相关。对于现在的前端开发来说，代码的组织方式是一个重要话题，前端社区里热议的AMD、包管理工具、自动化构建工具都是为了解决这个环节的问题。灵感也多源于java、ruby、nodejs等这些server端语言。如何选择工具，或是自主开发工具？还是要回到具体的工程需求上。

案例分析：临时在导航上加一个提示框。技术实现毫无难度，工程上就不那么简单了。也许面临下面的问题：

1. 导航是跨产品线的

2. 各产品可能是在不同的代码仓库

3. 它是临时的

4. 只有首次注册的新用户才能看到

5. 它有多个版本

如果正巧碰上导航正在A/B测试情况又复杂一些了。

传统做法：

1. 导航模块虽说是全局的，可以把提示框的html部分写在里面。它相关的css和js要分别部署到全局的css和js文件中。这样带来的问题：模板里可以判断是否出现提示框，css和js则无法做这样的判断。提示框下线时，要找到三个文件删代码。

2. 如果有的产品在不同代码仓库中，重复1的各种麻烦。

3. 如果类似的临时需求多了，维护成本将骤增。

4. 提示框不显示的情况下，与它相关的css和js冗余在全局文件里。

5. 多版本维护的复杂度加倍。

相似的场景在开发中十分普便。通过加人解决？随着需求增加，人力永远不够。我们跟工具团队合作改造模板系统比较完美的解决了这个问题。

提示框做为一模块文件，内部包含了相关的html/css/js。引用它之后，模板系统在渲染时，会自动做以下处理：

1. 收集。将页面中各个模板中的css和js分别收集起来。

2. 去重。去掉重复的引用。

3. 生成外部文件。

当模块出现时，css和js分别自动并入外部文件。去掉模块时，相关的代码自然移除，非常方便。效果其实可以看看douban首页的源文件。