前端架构：设计系统开发的现代蓝图

需积分: 33 177 浏览量更新于2024-07-21 收藏 7.98MB PDF 举报

"《前端架构设计系统》是一本实用指南，旨在将前端开发提升到与后端开发和内容策略并驾齐驱的地位。作者Micah Godbolt针对经验丰富的Web开发者，详细介绍了前端架构的新领域，涵盖了最新的工具、标准和最佳实践，这些都推动了前端Web开发的革新。书中通过实际案例、研究和实用技巧，引导读者理解前端架构的四个核心支柱：代码、过程、测试和文档。首先，"代码"部分着重于HTML、CSS和JavaScript在设计系统中的应用，如何构建高效且无误的代码结构。其次，"过程"涵盖工具和流程，旨在建立一个高效的工作流，确保项目的稳定性和可维护性。"测试"是基石，它强调如何创建一个坚实的基础，以便于网站的持续发展和性能优化。最后，"文档"部分则关注于实时编写文档的方法，帮助团队在整个项目进展过程中保持沟通和知识传递。这本书不仅提供了一套现代的、可扩展和可持续的网站构建蓝图，还鼓励开发者们作为前端架构师的角色承担起责任，争取在项目中赋予前端开发同等重要的地位。作者 Micah Godbolt凭借深入浅出的讲解和丰富的实践经验，为读者提供了实现这一目标所需的策略和技巧。本书适合任何希望提升前端开发效率和质量的专业人士，无论是初学者还是寻求进阶的开发者，都能从中获益匪浅。此外，对于教育机构、企业和销售推广，这本书也是一个理想的资源，因为它既适用于个人学习，也适合团队协作和培训。"

more user friendly for mobile devices, they required development

teams to maintain two separate websites.

Many m.dot sites languished, failing to be updated as frequently as

their larger siblings, or the reduced feature set of the m.dot site

forced users to switch to desktop devices to do anything more than

get directions or place a phone call. Something needed to be done.

Though some considered the iPhone a passing fad, it was soon quite

obvious that the future of the Web lived inside of these small, per‐

sonal screens.

On May 25, 2010, three years after the release of the iPhone, Ethan

Marcotte penned a lengthy article on A List Apart called simply,

“Responsive Web Design.” This article did not describe some new

discipline, or a banner for embattled developers to gather under.

Instead, it described a method for creating a new breed of website

that would respond to the size of the user’s device and mold itself to

that viewport. Responsive web design (RWD) was not some new or

emerging technology, but rather a collection of existing tools and

techniques, including the following:

Fluid grids

Percentage-based widths rather than fixed-pixel dimensions.

Flexible images

100%-width images fill the container they are put inside of, and

flex as the viewport changes size.

Media queries

Being able to specify different styles for different viewport sizes, we

could now change page layout based on the size of the screen.

All of these techniques had been available in the browser for years

before Ethan’s article, but just like Kristina’s call to arms for content

strategy, his description of RWD clearly defined the solution every‐

one was desperately looking for.

In a single article, the web development industry had been

transformed.

The Seeds of Frontend Architecture

It was with this history in mind that I started to think about the

notion of frontend architecture. As a Drupal frontend developer, I

knew full well the frustration that content strategists had felt. The

frontend styling was always an afterthought. It was a layer of

“pretty” applied to the default markup after the designers and back‐

end developers had finished their work. The challenges we faced

couldn’t have been better exemplified than in the order in which

people were brought onto a project. I saw projects start, designs

debated over, functionality developed...and then a frontend devel‐

oper was pulled onto the project to apply whatever design was

tossed over the wall to whatever markup our CMS chose to output.

Having gone through this process several times, I knew the pain I

was going to experience as I tried to deconstruct a set of mobile and

desktop Photoshop files. The goal was to form them into a theme

that could be applied to the div soup that Drupal spit out. Speaking

to Rails friends about the challenges of styling a website navigation,

I eagerly confessed, “One does not simply change Drupal navigation

markup,” and it was true! Once that markup was set, and the devel‐

oper had moved on to another task, the chance of modifying the

combination of divs, lists, and links was all but a dream. This inevi‐

tably led to some ridiculous CSS hacks to make a design that was

never meant to fit the default navigation markup actually work in

production.

For many years, frontend developers’ worth was measured by their

ability to create these Frankenstein-style design patterns. “Now if I

put a pseudo element on the third nested div, and use a background

image from this sprite...” was our battle plan, and it was terrible. We

were patching up holes in a failing levy, hoping that we could launch

the site before we got swept away by waves of technical debt.

This process wouldn’t be sustainable as the complexity of our

projects grew. So instead of doing things the way we’ve always done

them (because they’ve always worked in the past), I began to imag‐

ine how a project would differ if we made frontend development “a

critical asset worthy of strategic planning and meaningful invest‐

ment.” What if we had a voice in things like CSS frameworks, docu‐

mentation tools, build processes naming conventions, or even the

markup itself?! I started to wonder what a large-scale project would

look like if UX development fed backend development, instead of

the other way around.

Would this create a revolution? Would others pick up the same

torch and start to “Learn it. Practice it. Promote it.”? Before we

could all rally under a single banner, we needed to understand what

that banner stood for. What should we demand? How could we

accomplish our goals? What might we be called?

What’s in A Name?

In backend development, where planning and scalability are key,

software architects are highly valued. They are invited onto a project

long before development begins, and they have discussions with cli‐

ents about the architectural needs for their soon-to-be-built plat‐

forms. What technology stack are they going to use? What are their

content types? How is content created, stored, and displayed back to

the screen? The role of a software architect is to make sure that

nothing is ever created by chance, but rather guided by an overarch‐

ing architecture.

I realized that what frontend development was missing was architec‐

ture. We were being asked to do all our work piecemeal, as an after‐

thought. It didn’t take long for me to convert databases and web

servers to Sass folder structures and build systems, and the title of

frontend architect was born.

Now, every job title needs a job description. What would a frontend

architect do? How would they impact a project given the proper

opportunity? These ponderings led to a lightning talk about fron‐

tend architecture at my company’s annual retreat, and a speaking

opportunity at CSS Dev Conf that led me to focus my thoughts into

a concise 45-minute presentation.

On October 13, 2014, given to a packed room inside a New Orleans

conference center, “Raising a Banner for Frontend Architecture” was

a rallying cry for the developers who had already been on the front

lines of this fight. I wanted them to know that they were not alone,

and that there were others out there to support them and back them

up. I spoke to project managers, salespeople, and developers alike,

outlining the power of a properly architected frontend and the value

that it brought to the team and to the client.

After the talk, I heard story after story of developers who finally

understood who they were, and the role they played in their organi‐

zation. Many people found themselves performing the role of

frontend architect, but had never taken on that title, or felt confident

enough to ask for the authority the position should carry. The weeks

after CSS Dev Conf saw many people changing their Twitter bios to

剩余196页未读，继续阅读

vanridin

粉丝: 108
资源: 1187

前端架构：设计系统开发的现代蓝图

基于SSM+mysql的企业人事管理系统源码数据库论文.doc

我要写个ppt，关于数字孪生、bi业务系统前后端设计、业务数据对接的内容

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend.

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is he

aiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend.

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is h

tar -czvf frontend_0724.tar.gz frontend

fcitx-frontend-qt5

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2569

最新资源