前端架构设计(txt+pdf+epub+mobi电子书下载)


发布时间:2021-08-03 20:46:44

点击下载

作者:迈卡·高保特 (Micah Godbolt)

出版社:人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

前端架构设计

前端架构设计试读:

前言

排版约定

本书使用了下列排版约定。

●楷体

表示新术语。

●等宽字体(constant width)

表示程序片段,以及正文中出现的变量、函数名、数据库、数据类型、环境变量、语句和关键字等。

●加粗等宽字体(constant width bold)

表示应该由用户输入的命令或其他文本。

●等宽斜体(constant width italic)

表示应该由用户输入的值或根据上下文确定的值替换的文本。该图标表示提示或建议。该图标表示一般注记。该图标表示警告或警示。本书适用对象

本书不是一本技术手册,虽然书中使用了大量的代码示例;它也不是一本纯理论图书,虽然讲“为什么这么做”的部分和讲“怎么做”的一样多。因此,本书既不适用于单纯寻求技术答案的开发者,也不适用于只想了解梗概信息的项目经理。

本书适用的对象是那些想从更宏观的角度理解前端开发的从业人员。我撰写此书的目的在于激励和鼓舞开发人员去承担起前端架构师的职责,以及力争在下一个项目中把前端开发作为头等重要的任务。

本书也同样写给那些具备一定技术头脑,并且想要理解当前日新月异的前端环境的管理者。本书涵盖了可以把项目前端开发水平提升到全新高度的多种工具、标准和最佳实践,并对此进行了有力的论证。使用代码示例

补充材料(代码示例、练习等)可以从 https://github.com/micahgodbolt/front-end-architecture 下载。

本书的目的是要帮你完成工作。一般来说,如果本书提供了示例代码,你可以把它用在你的程序或文档中。除非你使用了很大一部分代码,否则无需联系我们获得许可。比如,用本书的几个代码片段写一个程序就无需获得许可,销售或分发 O'Reilly 图书的示例光盘则需要获得许可;引用本书中的示例代码回答问题无需获得许可,将书中大量的代码放到你的产品文档中则需要获得许可。

我们很希望但并不强制要求你在引用本书内容时加上引用说明。引用说明一般包括书名、作者、出版社和 ISBN。比如:“Frontend Architecture for Design Systems by Micah Godbolt (O'Reilly). Copyright 2016 Micah Godbolt, 978-1-491-92678-9.”

如果你觉得自己对示例代码的用法超出了上述许可的范围,欢迎你通过 permissions@oreilly.com 与我们联系。®Safari Books Online

Safari Books Online(http://www.safaribooksonline.com)是应运而生的数字图书馆。它同时以图书和视频的形式出版世界顶级技术和商务作家的专业作品。

技术专家、软件开发人员、Web 设计师、商务人士和创意专家等,在开展调研、解决问题、学习和认证培训时,都将 Safari Books Online 视作获取资料的首选渠道。

对于组织团体、政府机构和个人,Safari Books Online 提供各种产品组合和灵活的定价策略。

用户可通过一个功能完备的数据库检索系统访问 O'Reilly Media、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 以及其他几十家出版社的上千种图书、培训视频和正式出版之前的书稿。要了解 Safari Books Online 的更多信息,我们网上见。联系我们

请把对本书的评价和问题发给出版社。

美国:

O'Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

中国:

北京市西城区西直门南大街 2 号成铭大厦 C 座 807 室(100035)

奥莱利技术咨询(北京)有限公司

O'Reilly 的每一本书都有专属网页,你可以在那儿找到本书的相关信息,包括勘误表、示例代码以及其他信息。本书的网页地址是:

http://shop.oreilly.com/product/0636920040156.do

对于本书的评论和技术性问题,请发送电子邮件到:

bookquestions@oreilly.com

要了解更多 O'Reilly 图书、培训课程、会议和新闻的信息,请访问以下网站:

http://www.oreilly.com

我们在 Facebook 的地址如下:

http://facebook.com/oreilly

请关注我们的 Twitter 动态:

http://twitter.com/oreillymedia

我们的 YouTube 视频地址如下:

http://www.youtube.com/oreillymedia电子书

扫描如下二维码,即可购买本书电子版。第一部分引言Web 在诞生之初,形态其实是比较简单的。这里的“诞生”指的是 20 世纪 90 年代初期,而“简单”指的是一个网站能把自己的入口放在雅虎导航页上,并且访问者计数器能在使用表格布局并且满屏 GIF 动图的网页底部不停地闪烁。不过,这的确是那个年代你所需要的一切。只要你能给 webring带来流量,所有的网站管理员都会满意。那些网站管理员是谁呢?没错,其实他们就是那些域名的拥有者。那时,网站还是简单的存在,管理员就是它们的主人。这些人习惯性地使用混乱的 HTML,还搞不清楚到底是不是应该关注新出现的层叠样式表(CSS),甚至他们当中大多数人已经把 JavaScript 作为过时的东西抛弃了。不过,正如所有的媒介一样,网站也会进化。JavaScript 仍然被广泛使用,CSS 也不仅仅用于设置页面的字体类型和字体颜色。网站的管理员最终发现,他们走到了一个十字路口。网站的流量在持续增长,Web 技术也在持续发展(比如透明 GIF 等)。有太多的新事物和新技术需要学习,有太多的工作要做。最后,网站管理员不得不把网站的建设进行分工。一方面,他们很喜欢“网站正在建设中”这个标志以及到处可见的 marquee 标签;另一方面,Perl 是世界上最好的语言,毫无疑问它能够让网站永葆生机。当网站管理员聘请另一个人来维护他们珍贵的域名时,他们需要决定自己是继续做一个写各种 标签的大师,然后雇用写 Perl 脚本的新手,还是自己去学习 Perl。最终他们做出了决定,由此现代的 Web 开发团队开始成型,就像听到巨型海螺的召唤。早期的网站管理员在每一个阶段和十字路口,都会发现他们自己需要专注于开发过程中一个很小的部分。他们当中有些人会专注于服务器提供的文件服务,有些人想提高查询数据库的能力,而另外一些人则乐于创作各种图形和图像。更新的、更专业的角色也吸引了其他人到这个行业,包括艺术家、作家、商业分析师、工程师、数学家等。随着这些角色的发展,以及相关的人员越来越成熟,Web 开发逐渐催生了一系列新的名称和新的分支学科。那些决策者

在 Web 开发的早期,有些人认为网页中的文本内容跟设计、代码甚至搜索引擎优化(众所周知,搜索引擎就是抓取页面中的关键字)一样重要。在此之前,网页内容往往是被放到后面处理的。“先随便填一些 lorem ipsum字符到设计稿里,赶紧做后面的。”最终在网站上线之前,客户才会填上真实、优质、受启发的内容,并且一直以来都是如此。

这些内容的拥护者,终于坚定直接地宣称 Web 的本质就是内容,因此网站内容值得我们花费时间和精力。尽管这是一场恶战,不过他们开始被邀请参加早期的规划会议,偶尔也被邀请参与编辑策略的制定。他们不断取得进展!虽然这个过程困难而且孤独,但是结果是值得的。

就这样,他们作为开拓者在孤独地前进。直到关键的一天,他们碰巧遇到另外一个同样拥护内容的人,才意识到原来他们不是在孤军作战。友谊的星火以燎原之势发展成方方面面的合作,最终他们成立了社区,继续致力于向人们宣传网站内容的重要性。

很多年过去了,但是关于网站内容的争论远远没有结束。即使多一个设计师被要求在主页上“随便填充点内容”,我们也能马上听到远处抗议的呐喊声。2008 年 12 月 16 日,Kristina Halvorson 在 A List Apart 博客(http://alistapart.com/article/thedisciplineofcontentstrategy)上站出来发声,举起了内容策略的大旗。她要求我们传播这种理念,“要把网站内容作为一个值得做出战略规划和有投资价值的关键元素来对待”。其他内容策略的践行者们开始学习、使用和推广它,成为了内容策略师。由此,一个新的分支学科诞生了。

Kristina 的文章并不是最早提出内容策略这个概念的,却是最早定义出内容策略的核心、精神和目标的。一夜之间,内容拥护者们的共同诉求被赋予了一个名字。他们即将迎来一个新的时代,博客、播客和会议都围绕着一个简单的观点来讨论——“内容很重要”。响应式Web的出现

与此同时,一个身着黑色高领毛衣的男人出现了,并且颠覆了人们对互联网接入设备的理解。在 Web 历史上,我们第一次被迫接受这么一个事实:人们并不是只有坐在舒适的办公室或起居室,使用高速的宽带网络,对着分辨率为 1024 像素×768 像素的电脑屏幕时,才会去浏览网站。iPhone 的出现,使人们迎来了一个多分辨率、多功能、连接速度不稳定以及多种输入模式的多终端时代。作为开发者,我们不能再对用户和他们用来浏览网站的设备做出任何假设。

为此,我们尝试过很多解决方法。我们尝试使用双指缩放、双击缩放、直接显示原网站,或者把移动设备重定向到一个精简的便于移动浏览的“m.dot”网站。然而,没有一个方案能够真正解决问题。双指缩放的操作不便于导航,尤其对于购买商品或注册服务,而且增加移动流量意味着损失收益。虽然 m. 网站对移动设备更加友好,但是这样就要求开发团队去维护两个独立的网站。

很多 m. 网站被冷落了,它们也很难和 PC 版主站保持同步更新,或者部分功能缺失而迫使用户切换到桌面设备,来做一些比获得指引或者打个电话更复杂的事情。我们必须做出一些改变。虽然有些人觉得 iPhone 已经过时,但是很明显,Web 世界的未来在移动设备上。

2010 年 5 月 25 日,iPhone 发布 3 年后,Ethan Marcotte 在 A List Apart 上发表了一篇题为“Responsive Web Design”的长文(http://alistapart.com/article/responsive-web-design)。这篇文章并没有介绍新的学科知识,也没有打出口号,让困境中的开发者聚集起来;而是描述了一种创建新型网站的方式,这些网站可以根据用户访问设备的尺寸来做出响应,并且调节自身大小来适配对应的视口。响应式 Web 设计(responsive Web design,RWD)不是一种新科技,而是现有工具和技术的一个集合,包括以下内容。

流式网格

用基于百分比的宽度代替固定像素的尺寸。

自适应图片

用 100% 宽度的图片填充它们的容器,并且随着视口大小的改变而改变。

媒体查询

允许对不同的视口大小使用不同的样式,我们现在可以基于屏幕的大小来改变页面布局。

在 Ethan 发表这篇文章的几年之前,所有的这些技术其实早就可以在浏览器中使用。不过,正如 Kristina 为内容策略发起的号召,Ethan 对 RWD 的描述清晰地定义了每个人都在迫切寻找的解决方案。

一篇简单的文章,使 Web 开发这个行业发生了变化。前端架构的种子

根据这段历史,我开始思考什么是前端架构。作为一个 Drupal 的前端开发人员,我对那些内容战略家过去所面临的窘境感同身受。编写前端样式总是作为延后的事情来考虑,它是在设计师和后端开发人员完成工作之后,再给默认的标记加上一层漂亮的外表。对于我们所面临的挑战,没有什么比不同角色进入项目的先后顺序更能说明问题。我见过一些项目在启动之后,先是讨论设计方案,然后开发功能,最后才把前端开发人员加入到项目中,让他们把设计师扔过来的各种设计实现成 CMS 输出的标记。

经历了几次这样的流程之后,我知道当我尝试去解构那一堆移动端和桌面端的设计稿时,我将会非常痛苦。这样做的目标是把它们制作成一个主题,应用到 Drupal 输出的一堆 div 标签上。跟一些使用 Rails 的朋友谈及编写网站导航样式所面临的挑战时,我迫不及待地承认,“开发者不愿意对导航的标记进行哪怕是一点点的修改”,而事实的确如此!一旦这些标记被定下来,开发人员马上就会进入到下一个任务,这时候如果想修改一下 div、列表或者链接,那简直是痴心妄想。毫无疑问,这将会产生一些奇怪的 CSS hack 去实现某些设计,而这些设计往往都难以跟实际生产环境中的默认导航标记相匹配。

多年以来,前端开发人员的价值体现在创建弗兰肯斯坦风格的设计模式的能力上。“现在,如果我给第三层嵌套的 div 添加一个伪元素,并且给它设置一个雪碧图的背景图……”,这是我们的技术方案,它很糟糕。我们一直在填坑,还奢望能够赶在技术债务把我们拖垮之前把网站发布出去。

随着项目复杂性的增长,这样的流程不是长久之计。所以,我开始思考,如果不再使用传统的方式去开发(因为以前这种方法一直都是可行的),而是把前端开发当作“一个值得做出战略规划和有投资价值的关键元素”,会使项目产生什么样的变化。如果我们在 CSS 框架、文档工具、构建流程的命名规范,甚至标记本身这些方面拥有话语权会怎样?我开始思索如果是 UX 开发去主导后端开发,而不是反过来,那么一个大规模项目会变成什么样子。

这样能引起一场变革吗?其他人愿意跟随并开始“学习、使用和推广它”吗?在形成一股力量之前,我们需要了解目标。我们争取的是什么?我们怎样实现目标?我们会被赋予什么样的称呼?前端架构师的含义

在后端开发领域,系统规划和可扩展性非常关键,因此软件架构师备受重视。早在开发工作启动之前,他们就被邀请加入到项目中,而且他们会跟客户讨论即将建成的平台的架构要求。他们将会使用什么技术栈?内容类型是什么?这些内容如何被创建、保存以及展示在屏幕上?软件架构师的职责就是要保证项目中每一步都在总体架构的指导下进行,而不会随机决定。

我意识到前端开发领域缺少的就是架构。我们总是被要求做一些零碎的工作,而且优先级也不高。我没用多长时间就从数据库和 Web 服务器切换到 Sass 文件夹结构和构建系统,因此前端架构师的头衔就这样诞生了。

现在,任何一个职位名称都需要一个职位描述。前端架构师是做什么的呢?如果有合适的机会,他们会对项目产生什么样的影响?这些思考促使我在公司年会上做了一场关于前端架构的简短演讲。另外,在 CSS 开发者大会上的发言机会也让我将想法认真总结成了一个精简的 45 分钟演示。

2014 年 10 月 13 日,在新奥尔良会议中心一个拥挤的房间里,“举起前端架构的旗帜”成了在一线奋斗着的开发者们共同的诉求。我希望他们知道,他们不是孤军作战,有很多人在支持他们。我跟项目经理、销售人员和开发者沟通,给他们描绘拥有良好前端架构的意义,以及它为团队和客户带来的价值。

在这次演讲之后,我听到了很多故事,都是关于那些终于弄清楚自身定位以及在公司中所扮演的角色的开发者们的。很多人现在才发现,其实他们一直扮演着前端架构师的角色,却从来没有拥有过这个头衔,或者没有足够的信心去争取这个职位所应具有的权力。在 CSS 开发者大会召开几周之后,我发现很多人把他们在 Twitter 上的个人简介改成了“前端架构师”。而我,作为他们中的一员,从那以后,就在这条路上坚定地走下去了。不管我现在的工作头衔是什么,我都是一名前端架构师。第1章前端架构原则

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

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

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

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

体系设计

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

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

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

工作规划

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

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

监督跟进

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

模块化内容

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

全面测试

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

流式处理

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

详细的文档

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

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

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

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

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

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

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

任何一栋建筑都需要稳固的基础、四面墙体和一个屋顶。这些要素都是必不可少的。基础支撑着墙体,墙体支撑着屋顶,而屋顶保证你安全并且免受风吹雨淋之苦。如果一名建筑师不能提供上述要素,那么他必定是不称职的。作为前端架构师,我们在构建新网站时也承担着相似的责任。我们必须驾驭必要的工具和流程,而这两者正是成功构建网站的要素。3.1 围绕四个核心工作

本书接下来将讨论前端架构的四个核心。这四个核心的主题、技术和实践是构建可扩展和可持续优化的系统的基础。它们引发了在任何前端开发项目中都需要进行的一系列讨论。这些讨论会帮助我们确立对项目的整体期望,包括代码质量、实现每一项需求所需的时间和工作量,以及保证所有开发工作能够按时完成的工作流。

当然,本书所探讨的四个核心绝不是唯一的方法,甚至都算不上最好的方法。每一个决定都应该视项目的实际情况而定,有时候最好的决定甚至是什么都不做。不同于世界 500 强公司的那些需要持续多年面向客户的项目,小规模或者临时过渡的项目并不需要特别复杂的基础架构。

不要以为掌握了接下来的内容就可以高枕无忧。前端架构师的成长之路不是一蹴而就的,而是需要保持不间断的学习状态。这种状态决定了我们的水平和价值。对于前端开发领域的广泛涉猎使我们能够很快上手各种新技术和方法论。

我们的强项之一是花一个小时就能了解某个新框架或者 Gulp 插件,找出其亮点和不足,并确定它在项目中的可行性。因此,如果你迷失在本书接下来的大量技术和概念中,请记住:并没有人精通每一种技术。就我个人而言,我也只精通这些内容的一小部分,胜任一大部分,而余下部分则是入门水平。

好了,关于这些核心的介绍差不多了。接下来让我们深入分析它们的具体含义。3.2 四个核心的含义

代码

归根结底,所有的网站都是由一堆文本文件和资源文件组成的。当我们面对制作网站所产生的大量代码时,就会发现为代码和资源设定一个期望是多么重要。

在代码部分,我们会专注于如何实现系统架构中的 HTML、CSS 和 JavaScript。

流程

既然早已过了 FTP 上传文件的时代,那么现在重要的是思考怎么用工具和流程构建一个高效且避免出错的工作流。工作流变得越来越复杂,那些用于构建它们的工具也同样如此。这些工具在提高生产力、加快效率和保持代码一致性上带来了惊人的效果,但也伴随着过度工程化和抽象化的风险。

正如工作流在演变,工作的方式也在进步。我们不再浪费时间把一些 Photoshop 设计稿重构成 CMS 模板页面。因为逐渐把设计的环节转移到浏览器中,并书写响应式的网页框架,所以在实现 CMS 的界面之前,我们往往已经开始编写所有的 HTML 和 CSS 代码。要实现这个颠覆性的角色转变,就需要改变现有的开发流程。

测试

要构建一个可扩展和可持续优化的系统,必须保证新代码与老代码能够很好地兼容。我们的代码不会独立存在,它们都是大型系统中的一部分。创建覆盖面广泛的测试方案,能确保老代码还能正常运作。

在这个部分,我们会探讨三种用于测试网站的不同方法。根据团队的规模,测试方案有时会细分为很多部分,如前端、后端和运维。而深入理解每个部分将会有助于你和其他团队高效沟通。

文档

一般而言,如果不是团队中的重要成员要离开,我们几乎都不会意识到文档的重要性。等到那个时候,大家将不得不停下手头的工作,优先编写所有的文档。作为前端架构师,你要善于在项目开发的同时编写良好的文档。

这个部分将会介绍团队需要编写的各种文档类型、发布文档的工具,以及阅读这些文档的用户角色。第二部分代码核心好程序绝非偶然天成。这并不是说开发人员天生懒惰或者不值得信赖,而是因为独立工作的时候,我们针对同一个问题能提出各种不同的解决方案。不同于走迷宫,解决问题几乎不会只有一种方法。我们每个人的经验、观点和习惯各异,因此解决同一个问题的方式也不尽相同。开发人员意见纷纭是很正常的。这种从不同角度看待问题的能力使得我们团队越来越强大。但是在输出方案并且实际应用于设计系统的时候,我们既不希望也不需要在程序中反映出这些差异。即使开发人员都能以同样的方式解决问题,我们也不能保证代码适用于系统的其他部分。这就无异于开发人员写出一个精致优雅的 Bootstrap 主题,但项目需要的却是个性化主题。这一部分将帮助我们探讨如何提高 HTML、CSS 和 JavaScript 的代码质量,编写类、设计函数,以及声明接口。接下来的章节并非面面俱到。作为一名前端架构师,你的工作是不断地探索和评估新的技术、平台、方法和框架。世界上没有一刀切式的解决方案,而前端架构师的使命正是将项目的需求与前端开发的实际情况相结合。第4章HTML

作为前端架构师,你面临的第一个挑战就是标记的规范化,换言之,你希望开发人员写出或 CMS 产出什么样的标记。如果没有 HTML,Web 就不复存在。因此我们暂且把 CSS 和 JavaScript 放一边,先单独看原始的内容和控件。

文字、图片、链接、表单和提交按钮都是所有 Web 真正需要的元素,也是在 Web 上创建所有东西的基础。初始的标记做得不好,你将要写很多不必要的 CSS 和 JavaScript 来弥补。而初始的标记做得好,你就能写出更具可扩展性和可维护性的 CSS 和 JavaScript。4.1 过去处理标记的方法

过去,不少前端从业人员来自出版界,或者曾与出版界的设计师、产品负责人共事,因此 HTML 的布局跟手册、杂志或报纸等传统材料非常相似。现如今二者不能等同了。但是在响应式设计成为业界标准之前(甚至之后的一段时间),大多数网络媒体资源都被视为多页印刷品的集合。项目分工之后,你会被指定负责某个页面,从头开始创建 DOM。

过去,我们的标记通常被细分为两大阵营:程序式和静态式。下面就来看一看。4.1.1 程序式标记:自动化程度100%,可控程度0%

在 Web 出版领域,前端团队没有标记的控制权是非常普遍的。这通常是由于在前端团队参与项目之前,项目的功能开发(包括 HTML 输出)就已经进行了几周甚至几个月了。如果标记源码被复杂的渲染过程打乱,而且还来自不同的模板,那么情况就会变得更加糟糕。

这意味着,对于任何不熟悉 CMS 后端复杂性的人而言,更新标记将会异常困难。而往往到了这个时候,后端开发人员已经开始着手别的任务了,没有时间回过头来进行任何重大的修改。

这种制约因素的影响是,为了把内容更好地嵌入到 HTML 中,CMS 编辑人员和后端开发人员宁可写一堆标记和 CSS 类名。最终,他们编写的代码如下:

Drupal.org 首页的这一段代码显示了一个简单的页面顶部,即使在填充内容之前都可以包含 10 层嵌套,更可怕的是,在实际应用中这还不是一个特别夸张的现象。经验告诉我们,它还可能嵌套得更多。

以前,这种“div 乱炖”或许确实有助于我们把静态 Photoshop 图像做成标记化的页面,但随着我们的需求日渐成熟,我们急需更好的方法来驾驭它们。4.1.2 静态标记:自动化程度0%,可控程度100%

如果我们的项目规模比较小,或者任务只是开发一个需要填充一大块主体区域的页面,那么编写静态标记更为方便。虽然这种情况灵活性很大,但是也意味着我们必须负责维护所有的代码。一个原本在 CMS 模板中很容易的改动,现在需要每个页面单独手动修改。所以我们会写成这样:

为了保持简洁,“语义化”的标记是首选,应用样式所依靠的是 HTML5 元素名称和它们的层级关系,而非 CSS 类名。我们的标记中没有 CSS 类名,主导航的样式会自动继承到二级导航的锚点上,我们深受其害,最终往往写出这样的后代选择器:header > section > nav > div > ul > li > a { color: white;}header > section > nav > div > ul > li > ul > li > a { color: blue;}

过去,这种静态标记的方式使得对于任何一个悬停状态或激活状态选择器,代码至少得写这么长。你根本不想看三级导航会被写成什么样。我们还是赶紧跳过这部分,看一下现在是如何处理的。4.2 平衡可控性和自动化

作为前端架构师,你需要评估标记产生的过程。你对内容的顺序、使用的元素和 CSS 类名有多大的控制权?这些元素在将来改动起来会有多大难度?模板是否易用,或者是否只有后端开发人员才能更改?甚至,你的标记全是基于模板系统的吗?你可以通过系统做出更改,还是需要手动处理?通过回答这些问题,你可能会颠覆自己构建 HTML 和 CSS 的方法。模块化标记:自动化程度100%,可控程度100%

我们都在追求的理想状态是,网站上每一行 HTML 都由程序自动生成,而作为前端开发人员,我们只需要管理这个用来产生标记的模板和流程。遗憾的是,现实通常并非如此。即使在最好的情况下,也存在用户生成的内容,而这些内容几乎都无法自动添加 CSS 类名来标记。无论 CMS 系统自动生成 HTML 的能力如何,让 CMS 决定类似表单和导航栏这样的标记,有时候会更简单。但是就算你已经把理想状态实现了 90%,标记的模块化方案仍然可以给你带来理想的灵活性和必要的自动化。

模块化标记和程序化标记的区别在于,对于使用什么标记输出既定内容,我们不会完全任由 CMS 决定。这使得我们可以为两个不同的导航实例使用一样的标记,虽然 CMS 生成的标记可能完全不一样。模块化标记和静态化标记的区别在于,程序化地执行完之后,我们还可以通过一套类名系统给标记动态添加 CSS 类名,并且不再通过元素标签和层级关系来决定视觉外观。让我们看一下如何用 BEM 原则模块化地实现一个简单的导航:

乍看上去,这种方案似乎相当冗长。这一点我没有什么好辩解的,但我要说的是,它的冗余程度其实是恰到好处的。给每个元素都添加了相应的 CSS 类名之后,我们就不再需要依赖那些只为了样式标签而存在的 CSS 类名或元素的层级关系来决定视觉外观了。相比动态标记,这个标记更清晰,并且我敢说,这也让标记的组织形式更“模块化”了。这个导航可以作为网站的导航通用模板,不用改任何一个标记就可以在多处复用。因此,这种标记并不是先等 CMS 创建完成再另外添加样式标记的,而是创建的同时就添加了样式标记,然后整合到网站的整个导航系统中。4.3 这一切背后的设计系统

要使用这种模块化方法,我们首先需要改变构建页面的方法和思路。单独的静态“网页”其实根本就不存在。所谓的“网页”其实是过去的产物。那么什么是当前我们真正需要去创建的“页面”呢?是某个 URL 的内容吗?如何保证每次访问某个 URL 的时候都访问到同样的内容呢?如果你登录了会如何呢?如何使这个 URL 的内容根据时间、地点或者浏览器的不同而有所不同呢?越早地意识到我们现在所做的工作不是单纯地实现某个页面,而是设计整个系统,就能越早地开始创造那些真正让人惊艳的 Web 作品。

设计系统是网站视觉语言的程序化呈现。设计师创造的视觉语言,是用来描述网站如何通过视觉与用户沟通的工具。它集合了颜色、字体、按钮、图片样式、排版布局和界面版式,用来传达情绪、意义和目的。

正如词可以分为名词、动词和形容词等,作为前端开发人员,我们的工作就是把视觉语言拆解成最小单元。拆解之后,我们可以创建规则,对这些最小单元进行重组。只有将视觉语言充分拆解之后,我们才能知道如何重新把它们连成“句子”,组成“段落”,合并为“章节”,最后创作成一部精彩的“小说”。转换的目标是创建具有可扩展性和可维护性的代码库,以便如实地重现视觉语言能表达的任何东西。

在后面的章节中,我们将进一步创建设计系统,但是在目前的阶段,认清我们正开发的是什么很重要,因为在着手开发之前,我们需要先决定设计系统要如何建立在标记之上。4.4 模块化CSS理论的多面性

如今,CSS 理论几乎和 CSS 或 JavaScript 框架一样多。但 CSS 或 JavaScript 框架的用法较为繁琐,而且必须成套使用,而 CSS 理论更多的是阐释 HTML 和 CSS 之间的关系,而不是预编译的代码库,因此使用起来更为灵活。

你好像每天都会听说一个新的方法,例如使用新的命名空间、扩充数据属性,甚至是在 JavaScript 里定义 CSS。这些理论都有它的亮点,能够在如 HTML 和 CSS 的关系方面给你一些新的启发。

当然,没有哪个方法论是完美的,你可能会发现,一个项目与某一个方法契合得最好,但是另一个项目却更适合用另一个方法。所以,你完全可以创造自己的方法论,或者将一个现有的理论根据自己的需求进行改造。因此,如果你犹豫不决,不知道如何选择方法论,最好是看一些比较杰出的方法论,根据你手头的项目来分析其中哪些可用,哪些不可用。4.4.1 OOCSS方法

下面的代码片段展示了如何使用 OOCSS(Object-Oriented CSS,面向对象的 CSS)方法创建一个 HTML 切换。

Title 1

...
...

OOCSS(http://oocss.org/)有两个主要的原则:分离结构和外观,以及分离容器和内容。

分离结构和外观,意味着将视觉特性定义为可复用的单元。前面那段简单的切换就是一个简短的可复用性强的例子,可以套用很多不同的外观样式。例如,当前的“simple”皮肤使用直角,而“complex”皮肤可能使用圆角,还加了阴影。

分离容器和内容,指的是不再将元素位置作为样式的限定词。和在容器内标记的 CSS 类名不同,我们现在使用的是可复用的 CSS 类名,如 toggle-title,它应用于相应的文本处理上,而不管这个文本的元素是什么。这种方式下,如果没有应用别的 CSS 类名,你可以让 H1 标签以默认的样式呈现。

当你想提供一套组件让开发人员组合起来创建用户界面时,这种方法非常有用。Bootstrap 就是一个特别好的例子,它是一个自带各种皮肤的小组件系统。Bootstrap 的目标是创建一个完整的系统,而且这个系统能够创建开发者可能需要的任何用户界面。4.4.2 SMACSS方法

同样以切换组件为例,按照 SMACSS(Scalable and Modular Architecture for CSS,模块化架构的可扩展 CSS)方法,写出来的代码如下:

Title 1

...
...

尽管 SMACSS(https://smacss.com/)和 OOCSS 有许多相似之处,但 SMACSS 的不同点是把样式系统划分为五个具体类别。

基础

如果不添加 CSS 类名,标记会以什么外观呈现。

布局

把页面分成一些区域。

模块

设计中的模块化、可复用的单元。

状态

描述在特定的状态或情况下,模块或布局的显示方式。

主题

一个可选的视觉外观层,可以让你更换不同主题。

在前面的例子中,我们看到了模块样式(toggle、toggle-title、toggle-details)、子模块(toggle-simple)和状态(is-active)的组合。对于如何创建功能的小模块,OOCSS 和 SMACSS 有许多相似之处。它们都把样式作用域限定到根节点的 CSS 类名上,然后通过皮肤(OOCSS)或者子模块(SMACSS)进行修改。除了 SMACSS 把代码划分类别之外,两者之间最显著的差异是使用皮肤而不是子模块,以及带 is 前缀的状态类名。4.4.3 BEM 方法

这里同样以切换组件为例,使用 BEM(Block Element Modifier,块元素修饰符)语法写出组件代码:

Title 1

...
...

BEM 是我们要看的第三个方法,是 SMACSS 的另一个方面。BEM 只是一个 CSS 类名命名规则。它不涉及如何书写你的 CSS 的结构,而只是建议每个元素都添加带有如下内容的 CSS 类名。

块名

所属组件的名称。

元素

元素在块里面的名称。

修饰符

任何与块或元素相关联的修饰符。

BEM 使用非常简洁的约定来创建 CSS 类名,而这些字符串可能会相当长。元素名加在双下划线后(例如 toggle__details),修饰符加在双横杠后(如 toggle__details--active)。这里的 details 是元素,active 是修饰符,这个约定使得 CSS 类名非常清晰。使用双横杠是为了避免块名被混淆为修饰符。

这种方法在 OOCSS 或 SMACSS 里使用的好处是,每一个 CSS 类名都详细地描述了它实现了什么。代码中没有 open 或者 is-active 这样只在特定背景下才能理解的 CSS 类名。如果单独看 open 和 is-active 这两个名字,我们并不知道它们的含义是什么。虽然 BEM 方法看起来很累赘、很冗余,但是当看到一个 toggle__details--active 的 CSS 类名,我们就知道它是表示:这个元素的名称是 details,位置在 toggle 组件里,状态为激活。4.5 选择适合的方案

当然,最重要的还是要找到一个适合的解决方案。不要因为一套规范很流行或者别的团队正在使用就选择它。这三种方法都提供了类似的工具,并且以相近的方式在系统中使用。

在 Red Hat 网站中,我们使用了 SMACSS 和 BEM 相混合的方案,这一点将在第 7 章中详细讨论。不要害怕尝试、混合或者创造出独一无二的方案!你要做的是理解这些方案背后的原则,说出为什么你的方案能够解决项目面临的挑战,并且确保团队乐意使用一个统一的方案。如果你决定使用 OOSMABEM,大胆去做吧!我期待能够读到关于它的东西。第5章CSS

这个行业最好的事情之一是:我们可以随意地和其他开发人员坐下来,喝点咖啡聊聊工作。这似乎无关紧要,但我告诉你,这非常重要!我们在一个以标准开放、软件开源、信息自由、学习便捷为基础的行业中工作,使用的工具和技术变化之快令人难以置信,但正是这样一个开放的行业氛围使得我们能够紧跟趋势。这可能会让你感到惊讶,但在一些领域里,你永远不会,也不可能在一些商业场合坐下来与同行讨论具体工作内容,除非他们付钱让你这么做。在那些领域中,每一个知识、每一个技巧、每一个预设、每一个宏命令、每一个文档,以及每一个捷径都可能被挂牌出售,而你最不想做的事情就是跟潜在的竞争对手一起坦诚地交换那些信息。

但 Web 领域不同,我们正是依赖分享知识才变得更加强大。我们发表博客文章、录制视频教程、创建公共代码仓库、在 Stack Overflow 上发表帖子、回答 IRC 的问题,以及发布代码到 CodePens、Gists、Sassmeisters、JSbins 和 Pastebins 上,所有的这些都是为了让其他人可以学习到我们所了解的东西。喝杯咖啡,讨论现行的 Web 开发实践和新的 CSS 框架,这就是我们如何分享知识以及如何在这个行业中学习的最基本表现。

因此,在我们从事的行业中,邀请同行一起出去喝咖啡不仅是可接受的,而且还会被当成一种有意义的行为!这些咖啡会帮助我们学到新的事物,获得新的商务联系,找到新的工作,甚至交到很好的朋友。可以说,多年以来的喝咖啡、喝酒、喝茶或者红茶菌的经历,使我相信一起喝东西时的交流是我们这个行业宝贵的无形资产。

坚持用咖啡或者酒精促进谈话的好处在于,我们会不断了解人们对什么感兴趣,以及人们在朝着什么方向努力。这对我来说很重要,不是因为我依赖别人来知道下一步该做什么,而是因为我能够验证我所学习的东西以及我自己的发现。每一年我都会回顾我的 CSS 方法是如何发展的。所以,无论我最新痴迷的是预处理、构建工具、样式驱动的设计,还是基于组件的设计系统,我都会因为和别人有完全相同的发现而感到很兴奋。

我现在编写的 CSS 跟三年前的大相径庭。每建设一个网站,我都会从中学到新的东西,并尝试应用到下一个项目中。这是一个逐步发展的过程,我把学到的东西和读到的东西集聚到一起,并尝试用改进的方案解决我所面临的特定问题。每一次迭代都提升了我的技术,也大大加深了我对可扩展性和可维护性设计系统的理解。

每次迭代都会带来一些激动人心的讨论,也许是与各种各样的同事、业内同行,也许是与一些参会者。我会因为每次谈话中的共鸣而感到狂喜,比如发现我并非唯一使用数据属性或可选样式来处理组件变量的人!

作为一名前端架构师,你可能不需要知道不起眼的 Opera Mini 版本上的每一个细微的 CSS bug,但是你必须理解 CSS 的主要发展趋势,并能制定会让团队获得成功的计划。如果你不了解目前 CSS 的发展趋势,或者没有快速领悟,那么尝试和其他开发人员多喝几杯咖啡吧,或者在你下一次参加行业会议时,多花一些时间与参会的同行进行社交互动。但是在你做这些事之前,请阅读下面的章节,你会了解几年前 CSS 技术的情况,当时写的 CSS 为什么不生效,以及现在的 CSS 技术发展成什么样。

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载