前端开发的工程之美

来源:kejunz 的分享@kejunz

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

纯粹的技术约等于规范,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分别自动并入外部文件。去掉模块时,相关的代码自然移除,非常方便。

上述包含的细节就不展开了。css的引用支持sass和source map,js目前支持导入。后续还有完善的空间,不过已经可以解决不少工程上的问题。《打造facebook》一书中说facebook会集合公司里最好的工程师开发工具。我们恰好也是这样。

 

收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部