第 1 章 前端架构原则

第 1 章 前端架构原则

前端架构是一系列工具和流程的集合,旨在提升前端代码的质量,并实现高效、可持续的工作流。

当思考前端架构师的角色时,我总会联想到传统的建筑设计师。

在建设过程中,建筑设计师需要设计和规划方案,并且跟进施工过程。这与前端架构师的工作有着异曲同工之妙,不同的是后者建造的是网站,而不是建筑物。比起浇筑混凝土,建筑设计师会在设计工程构图的工作上倾注更多的精力。同理,相比编写具体的代码,前端架构师更专注于开发工具和优化流程。

下面,我们来深入分析前端架构师的工作职责。

体系设计

  试想一下,如果一栋建筑没有明确的构造设计,所有的重要事项都由建筑工人直接决定,那么就可能会出现这样的情景:第一面墙用石头垒,第二面墙用砖头砌,第三面墙用木头搭,第四面墙因为追求时髦而留空。

  虽然网站的整体外观和风格基调完全由经验丰富的视觉设计师决定,但前端架构师掌控着背后的前端开发方法和系统设计哲学。通过设计所有前端开发人员都要遵循的系统规范,前端架构师清晰描绘了产品和代码的最终形态。

  一旦前端架构师建立起了系统设计的规范,项目就拥有了可以衡量代码质量的标准,否则我们如何判断代码是否达标呢?一个精心设计的系统,应当具备完善的检验机制,并做出适当的取舍,以保证系统中的代码有实质的价值,而不是简单的堆砌。

工作规划

  有了清晰的结构设计之后,就需要制定开发工作流了。开发人员写一行代码并且提交到线上需要经过什么步骤?举一个最简单的例子,这个过程包括使用 FTP 登录服务器,修改一个文件并保存。然而,对于大多数项目而言,完整的工作流可能会用到多种工具,如版本控制器、任务调度器、CSS 处理器、文档工具、测试组件和服务器自动化工具等。

  前端架构师的目标是设计出能流畅运转的系统。这个系统不仅能高效快速地启动,还可以通过语言分析、测试用例、文档记录等方法持续地提供有效的反馈,并且大幅减少由于重复操作而产生的人为错误。

监督跟进

  前端架构设计绝不是一劳永逸的工作。没有任何设计在一开始就是完美的,也没有任何计划可以一步到位。客户和开发人员的需求会随着时间改变。在某个阶段运行得很好的开发流程,随后也可能需要重新调整,以便提高效率、减少错误。

  前端架构师的一个非常重要的能力,就是能够持续地优化工作流程。如今各种各样的构建工具可以让我们很方便地改变工作方式,并通知到每一位开发人员。

  有些人问前端架构师是否等同于管理角色,不再需要写业务代码。我以过来人的身份向你保证,前端架构师不仅要写更多代码,更要会用多种编程语言,还要使用大量的工具。代码量并未减少,只是代码的读者发生了改变。前端开发人员面向终端用户写代码,而前端架构师面向的则是团队里的开发人员。

像盖房子一样搭建站点

前端架构需要争夺属于自己的优先权,正如我们很难想象有人会在不咨询建筑师的前提下,就建造一座摩天大厦。但事实上,很多大型的网站项目就是这么直接开始的。

借口数不胜数:“我们预算不够了”“哪有时间做这个”“等设计做完了再说吧”;甚至更糟糕的是,你只是被毫无理由地突然空降到项目组——所有的设计已经定稿,开发工作也如火如荼地进行了几个月,而你只有几个月的时间把别人扔过来的一堆设计稿奇迹般地且完美地实现成一个个的网页。这当然不可能开发出实用性强、可扩展且稳定强大的网站。

作为前端架构师,我们认为有多个关键的决策需要在项目启动之初就制定下来。如果等到开发阶段的后期再考虑,不是已经用不上了,就是一开始错误的决定已经造成了无法挽回的损失。一旦做出这些决策,我们的任务就是去辅助视觉设计、平台开发、底层结构,使之能最大程度地满足需求。

如果没有前端架构师的提前介入,项目就有可能陷入两难境地:或是将视觉设计、平台或底层结构推翻重做,或是让前端开发人员自己去克服困难。经验告诉我,推翻重做通常不会有什么好结果。

有什么难题

我知道,这不是一个轻松的任务。我所提议的改变需要耗费不少的成本,而且任何一个负责做这些决定的人都需要权衡各种利弊。对于那些没有与前端架构师一起工作过的人来说,这将会存在很大的风险。

正如人们争论“先有鸡还是先有蛋”的问题,我们面临的窘境是,如果要说服老板们为一个完善的前端架构系统花费时间和金钱,他们往往会要求提供这种架构的成功案例,而这显然需要你曾经参与过类似的项目。问题是,如果你总是被要求证明这种工作流程是有效的,又怎么会有机会去实际地为某个项目设计前端架构呢?

对于我和这本书来说,很幸运,我最近被委以重任,为一个大型的网站建立新的架构系统。我有充足的时间思考和规划这个新系统,并制定新的代码标准、工具和开发流程。一旦这个项目开始成形,我就得到了一个很可贵的机会,去证明合适的架构设计有多么强大的可扩展性和可持续性。

目录