第 2 章 Alpha 项目

第 2 章 Alpha 项目

在过去的一年里,我有幸以架构师的身份参与了 Red Hat 公司的一个项目,该项目希望将已有的网站组件共享到公司的多个网站中。在构建 Redhat.com 一段时间之后,我知道自己还是面临很多挑战。我花了一些时间建立起开发团队对我的信任,最终得以全权负责整个项目的架构。

这个机会非常难得,因为有了它,我们才能解决“先有鸡还是先有蛋”的问题。我的团队有机会去搭建一个庞大的、有足够技术支撑的设计方案,并且整个方案最终会被展现在一个流量很大的站点中。这将会成为一个标志性的项目,能够让我在后续其他项目中推广前端架构设计的理念。

2.1 慢而有力的开端

能够在这个时候与 Red Hat 公司合作,我的团队实在是太幸运了。我们对旧站点进行了重新设计之后,并没有马上着手开发新功能。虽然我们时不时也需要处理一下 bug,但毕竟还是有几个月的时间去研究如何为这个系统设计全新的架构。

尽管在 Redhat.com 生产环境中仍然有大量的遗留代码,我们还是选择了从零开始。因为原来的站点是基于块(一行接一行的独立内容)设计的,所以我们新开发的网页元素可以布局在已有内容块的上方或下方。我们不需要重写侧边栏的样式,也不需要频繁地改变 HTML 标签的样式。实际上,我们相当于在旧站点中构建全新的网站。正如船上的甲板可以一块一块地被替代,我们希望最终也可以替换原有的系统,完全使用新的系统。

既然自由发挥的空间这么大,我们完全可以创建一张很长的愿望清单,并且真的去实现它们。这个愿望清单包括以下方面。

模块化内容

  我们非常推崇 Brad Frost 提出的原子设计方法论(http://patternlab.io),希望尽可能复用小的组件,而不是弄出几十个、甚至上百个不同的内容块。

全面测试

  我们之前经常出现这样的情况:大量的前端代码合入到主干,然后导致几个月前的代码出现运行问题。这样太浪费时间了,所以我们决定要像测试后端代码一样测试我们的新框架,达到一样的代码覆盖水平。

流式处理

  我们希望引入 Git 工作流程,用它来管理应用代码简直是游刃有余,但是我们要将功能分支分解为更小的、模块化的代码块。另外,也要把过去一直采用的容易出错的手动步骤自动化:更新样式表、创建图标字体、部署新代码等。

详细的文档

  这个新系统的受众很广,包括前端开发人员、后端开发人员、设计师、市场经理、运维人员,以及其他产品开发角色。我们希望每个人接触这套系统时,都能找到适合自己的、详细的文档。

这四个方面需要一点时间去开发、配置和完善。在最初几个月里,我们的开发效率确实不如以前。但是一旦新系统有了一定的基础,我们很快就感受到了它的优势。

当再次遇到包含 2 个,甚至多达 12 个内容块的页面需求时,我们发现工作量比以前少得多。我们不再需要独立对待每一个内容块,而是将内容块拆分为最小的独立可重用组件,并根据需求决定是否新增布局或组件。

最终,每一个需求都会产出详尽的文档、全面的回归测试方案以及符合最初架构设计规范的源代码。

虽然这些工具和流程需要一些时间来打造,但是效果实在太好了,现在我们已经开始嘲笑自己的工作有多么简单了。当然,工作简单是好事,这意味着我们可以少做一些重复的工作,把更多时间花在系统设计上。最终,在我们设计的系统中工作会感到愉悦,面对每一个用户需求,我们都会感到兴奋,因为又有机会将系统变得更强大了。

2.2 全副武装

有了这些经验后,我相信我们编写的代码、开发的流程、磨练的技术能够充分验证这套方法论的合理性,并成为说服其他人在项目中使用它的坚实基础。

使用本书提到的流程、技术和书中讨论的经验,我希望你在下一个项目中能够有自信为自己的前端架构而战。争取尽早参与项目,以能够在项目的重要决策中发挥影响力;挑战现有的工具和流程,构建更智能、可重用性更高的代码;争取使你的前端工作产生更大的影响力。扛起前端架构师的旗帜,和我一起战斗吧!

目录