1、Algorithm 一道算法题
给你一个字符串
s，找到s中最长的回文子串。如果字符串的反序与原始字符串相同，则该字符串称为回文字符串。
示例 1：
输入： s = "babad"
输出： "bab"
解释： "aba" 同样是符合题意的答案。
示例 2：
输入： s = "cbbd"
输出： "bb"
这道题可以用中心扩散法求解。即假定某个字符串为回文子串的中心，然后设定2个指针同时由中心的左侧和右侧进行移动，对比左右2个指针上的值是否相等，如果相等，则继续向两边移动指针，否则终止得到当前中心的最长回文子串。
遍历整个字符串，得到所有中心的最长回文子串，然后选取最长的一个。
/**
* @param {string} s
* @return {string}
*/
var longestPalindrome = function(s) {
const len = s.length;
if(len < 1){
return ""
};
let start = 0,end = 0;
// 遍历字符串，寻找回文子串的中心
for(let i=0;i<len;i++){
// 回文子串长度是奇数
const len1= expandAroundCenter(s,i,i);
// 回文子串长度是偶数
const len2 = expandAroundCenter(s,i,i+1);
const len =Math.max(len1,len2);
if(end - start < len){
start = i -Math.floor((len-1)/2);
end = i+Math.floor(len/2);
}
}
return s.substring(start,end+1);
};
function expandAroundCenter(str,left,right){
// 以 left 到 right 的字符为回文串中心进行扩展
while(left >= 0 && right < str.length && str[left] === str[right]){
left--;
right++;
}
return right - left -1;
}
2、Review 读一篇英文文章
How We Build Micro Frontends Building micro-frontends to speed up and scale our web development process.
我们如何构建微前端 构建微前端以加快和扩展我们的Web开发流程。
At Bit , we build tools for over 100,000 developers working with components. Our tools help developers build, reuse, and collaborate on independent components to speed up development and improve application quality.
在 Bit，我们为超过100,000名开发人员构建工具，这些开发人员使用组件进行开发。我们的工具帮助开发人员构建、重用和协作独立的组件，以加快开发速度并提高应用程序质量。
Since day one we’ve been dogfooding our own tools, while letting components drive our architecture and development process. A great advantage of this is the ability to enjoy the benefits of Micro Front-Ends
从一开始，我们就一直在使用我们自己的工具，让组件驱动我们的架构和开发流程。这样做的一个巨大优势是能够享受微前端的好处。
By splitting the front-end monolith into smaller codebases, front-end teams can enjoy similar benefits to those of microservices: maintainable codebases, autonomous teams, independent releases, and incremental upgrades.
通过将前端单体应用拆分为更小的代码库，前端团队可以享受与微服务类似的好处：可维护的代码库、自治的团队、独立的发布和增量升级。
Micro frontends are usually thought of as a composition of independent frontends that happens at runtime, either on the server or on the client-side.
微前端通常被认为是在运行时（无论是在服务器端还是客户端）组合独立前端的方式。
While runtime integrations have their benefits (smaller payloads for example) but they’re not, by any means, the only way to achieve “a composition of independently deliverable frontend applications” (to quote Cam Jackson).
虽然运行时集成有其优点（例如较小的负载），但它们绝不是实现“独立可交付前端应用组合”的唯一方式（引用Cam Jackson的话）。
This new way of building and collaborating on frontend apps, is, in our view, the core element of micro frontends.
在我们看来，这种构建和协作前端应用的新方式是微前端的核心要素。
With the right component model and the right tools, any team can adopt a modular approach to building web applications, and enjoy these benefits.
通过正确的组件模型和正确的工具，任何团队都可以采用模块化的方式构建Web应用程序，并享受这些好处。
For us, composing frontend apps in build-time brings the best of both worlds — the safety and robustness of “traditional monoliths” and the simplicity and scalability of micro frontends. For that, we use Bit, an open-source library that helps in making each component completely independent, and our cloud platform that lets teams efficiently collaborate and integrate together.
对我们来说，在构建时组合前端应用程序带来了两全其美的优势——“传统单体应用”的安全性和稳定性以及微前端的简单性和可扩展性。为此，我们使用Bit，这是一个开源库，可以帮助使每个组件完全独立，并使用我们的云平台让团队高效地协作和集成在一起。
In this article, I’ll show how we, at Bit, are building micro-frontends. I’ll explain how it helped us achieve goals such as decoupled codebases, fully-autonomous teams, independent incremental upgrades, and near 100% modular code reuse. I hope you’ll find this shared knowledge useful.
在本文中，我将展示我们在Bit公司如何构建微前端。我将解释它如何帮助我们实现解耦的代码库、完全自治的团队、独立的增量升级以及近乎100%的模块化代码重用。我希望你会发现这些分享的知识有用。
If you head over to the Bit.cloud’s homepage, you’ll notice something strange happening every time you hover over a component.
如果你访问Bit.cloud的首页，你会注意到每当你将鼠标悬停在一个组件上时，会发生一些奇怪的事情。
Once the mouse enters a component, a highlight turns on, indicating the component’s name, independent version, and scope in which it is published and exposed. As you scroll, you’ll notice that the entire page is made of components that are independently built, versioned, and shared by different teams, in different codebases, using different build processes, and are all integrated together into one cohesive-feeling product.
一旦鼠标进入一个组件，一个高亮显示会打开，显示组件的名称、独立版本以及它所发布和暴露的范围。当你滚动页面时，你会注意到整个页面由独立构建、版本化和由不同团队在不同代码库中使用不同构建流程共享的组件组成，并且它们都被集成到一个统一的产品中。
What you see there is a real demonstration of how our team is using modern component-driven technologies like React and Bit to build micro front-ends.
你在那里看到的是我们团队如何使用现代的组件驱动技术，如React和Bit，来构建微前端的真实演示。
On this page, you will see two sets of components, developed by two teams. One is the “base-ui” set of components, owned by our front-end infrastructure team. The second set is “evangelist’”, owned by our marketing team.
在这个页面上，你会看到两组组件，由两个团队开发。一组是我们前端基础设施团队拥有的“base-ui”组件集合。第二组是我们市场团队拥有的“evangelist”组件集合。
Components from both sets are integrated together to quickly compose the homepage you look at, as well as other pages like the Enterprise Page or Support Page, and even to compose more applications.
这两组组件被集成在一起，快速组合成你所看到的首页，以及其他页面，如企业页面或支持页面，甚至用于组合更多的应用程序。
If you click on the scopes of the components you’ll be able to see our codebase architecture and our organizational structure with your own eyes.bit.dev/enterprise
如果你点击组件的范围，你将能够亲眼看到我们的代码库架构和组织结构。
One scope of components is called “base-ui”. This is the most basic component design system of Bit.dev, that contains basic elements like “paragraph” for example. It is owned by the frontend infrastructure team and developed in its own decoupled codebase. All these components are published and shared on Bit.dev. There, they can be easily discovered and integrated into new projects by any other team that needs them. And, the team building base-ui can keep incrementally sending updates to specific components. bit.dev/teambit/bas…
一个组件范围被称为“base-ui”。这是Bit.dev的最基本的组件设计系统，包含基本元素，比如“段落”等。它由前端基础设施团队拥有，并在其自己的解耦代码库中开发。所有这些组件都被发布和共享在Bit.dev上。在那里，它们可以被其他需要它们的团队轻松发现和集成到新项目中。而且，构建base-ui的团队可以持续地向特定组件发送更新。
The second scope is called “evangelist”. This is our concrete marketing-oriented system of components, used to build the marketing pages on our applications. It is autonomously owned by the marketing team and developed in a decoupled codebase. All of these components are published and shared on Bit.dev, and are maintained by the marketing team.
第二个范围被称为“evangelist”。这是我们具体的面向市场的组件系统，用于构建我们应用程序上的营销页面。它由市场团队独立拥有，并在解耦的代码库中进行开发。所有这些组件都被发布和共享在Bit.dev上，并由市场团队进行维护。
In this example, the marketing team was decoupled from the team building the Bit.dev web platform. This team works in a different codebase, releases changes through its own decoupled build pipeline, and can constantly deliver incremental upgrades.
在这个例子中，市场团队与构建Bit.dev Web平台的团队解耦。这个团队在一个不同的代码库中工作，通过自己的解耦构建流程发布变更，并可以不断进行增量升级。
Each team builds its components, with the flexibility to split vertical ownership by features etc, in their own smaller and decoupled codebase. They use Bit to independently version, build, test, package, and publish each of their components. They use the bit.dev platform to host and expose components to other teams, so they can integrate and collaborate.
每个团队在自己的较小和解耦的代码库中构建其组件，可以根据功能等将垂直所有权进行拆分。他们使用Bit来独立地对每个组件进行版本控制、构建、测试、打包和发布。他们使用bit.dev平台来托管和暴露组件给其他团队，以便进行集成和协作。
Every team at Bit enjoys a similar workflow. All teams work together to share and integrate components with each other, without stepping on each other’s toes. Close to 100% of the components written in our codebase are shared and reused, including not only front-end components, but also many other aspects of our system, such as “Search” features, “Playground” features, and even certain fullstack features that include both frontend and backend functionalities. We find this to be of great value.
Bit公司的每个团队都享受类似的工作流程。所有团队共同努力，相互分享和集成组件，而不会互相干扰。我们代码库中几乎100%的组件都是共享和重用的，包括不仅仅是前端组件，还包括我们系统的许多其他方面，比如“搜索”功能、“Playground”功能，甚至包括前端和后端功能的某些全栈功能。我们认为这具有很大的价值。
KPIs and benchmarking we took for ourselves and for other teams show a variety of positive things happening when adopting this component-driven design. For example, the number of releases can go up by as much as 30X(!), the time spent on integrations is cut by over 50%, the composition of new features becomes a matter of hours or days, and even on-boarding new developers can become a simple matter of hours instead of weeks. You can hear more about this change and what it can do for a fast-growing start-up first-handed at this great episode of the HeavyBit JAMStack podcast.
我们为自己和其他团队制定的关键绩效指标和基准测试显示，当采用这种基于组件的设计时，会发生各种积极的变化。例如，发布次数可以增加多达30倍(!)，集成所需的时间减少了50%以上，新功能的组合只需要几个小时或几天的时间，甚至新开发人员的入职时间也可以从几周缩短到几个小时。你可以在HeavyBit JAMStack podcast的这一优秀节目中第一手了解这种变化以及它对快速增长的初创公司的影响。
So what are micro front-ends, really?
那么，什么是真正的微前端？
In recent years, microservices allowed backend architectures to scale through loosely coupled codebases, each responsible for its own business logic and exposes an API, each independently deployable, and each owned and maintained by a different team.martinfowler.com/articles/mi…
近年来，微服务使得后端架构通过解耦的代码库进行扩展，每个代码库负责自己的业务逻辑并暴露一个API，每个代码库可以独立部署，并由不同的团队拥有和维护。
This paradigm provides great advantages to help accelerate, scale, and make the development process more efficient.
这种范式提供了很多优势，可以加速、扩展并使开发过程更加高效。
The idea of micro front-ends is to bring the same advantages to the modern development workflow. It means breaking down monolithic projects into smaller, more manageable pieces, which are independently developed and owned by respective teams, with the power to build and ship simultaneously.
微前端的理念是将相同的优势带入现代开发工作流中。这意味着将庞大的项目拆分成更小、更易管理的部分，由各自的团队独立开发和拥有，并具备同时构建和发布的能力。
This concept can provide great advantages like simple, decoupled codebases, autonomous teams, independent releases, and incremental upgrades. The development process is greatly accelerated, scaled, and made more efficient.
这个概念可以带来很多优势，比如简单的解耦代码库、自治的团队、独立的发布和增量升级。开发过程大大加速，扩展性增强，效率提高。
So why is this possible now, but not before?、
为什么现在才有可能实现这一点，而以前却不行呢？
Up until recently, most web applications were still being built as single monolithic projects. GatsbyJS’s Founder Kyle Mathews put it well saying that “Websites today are still made the same way they were 20 years ago, with a cumbersome monolithic approach to building sites, storing data, and delivering content. It’s time for a new way to build the web.”
直到最近，大多数Web应用程序仍然是作为单一的巨大项目构建的。GatsbyJS的创始人Kyle Mathews很好地表达了这一点：“如今的网站仍然以繁琐的巨大方式构建，存储数据和提供内容。是时候采用一种新的构建Web的方式了。”
Yet today, components are the standard primitive of the modern web. Only now these modular and reusable pieces are reaching their true capacity as the building blocks of our web applications, enabling the modular decomposition of traditional monoliths. Now, to tap into this opportunity, there’s a need for a shared infrastructure that facilitates modular component-driven design for teams building web applications together.
然而，如今组件已成为现代Web的标准基本单元。现在，这些模块化和可重用的组件作为我们Web应用程序的构建块，正发挥出它们真正的潜力，实现传统巨大项目的模块化分解。为了利用这个机会，需要一个共享基础设施，以促进团队共同构建Web应用程序时的模块化组件驱动设计。
This is where new tools like Bit come in, to provide the necessary toolset required to adopt and enjoy component-driven development at the architectural and organizational level, and fulfill these potential benefits.
这就是新工具如Bit的用武之地，它提供了在架构和组织层面上采用和享受组件驱动开发所需的必要工具集，并实现这些潜在的好处。
Bit lets developers decouple the development, reuse, and release of independent components so that they can be efficiently developed, reused, and integrated to compose different applications. This makes Bit a powerful tool for use-cases such as design-systems and shared components, but also for building micro front-ends.
Bit允许开发人员解耦独立组件的开发、重用和发布，以便能够高效地开发、重用和集成这些组件来构建不同的应用程序。这使得Bit成为设计系统和共享组件等用例的强大工具，同时也适用于构建微前端。
At Bit we’ve been working with micro front-ends since day one. That’s how we designed and battle-tested our own tools, so that they can help other teams build better with components. Today, our tools help over 100,000 developers enjoy similar benefits.
从一开始，Bit团队就一直在使用微前端。这就是我们设计和经过实战测试自己工具的方式，以便它们可以帮助其他团队更好地使用组件进行构建。如今，我们的工具帮助超过10万名开发人员享受类似的好处。
In this article, I’ll share how our own team is building micro front-ends with components. I’ll show and explain how we are able to split web development into decoupled and maintainable codebases, make it easy to replace or integrate new features and technologies, free teams to independently build and release changes to production without stumbling on each other’s toes, achieve up to 100% component reuse, and build both a scalable architecture and organization structure that smoothly grows as we do.
在本文中，我将分享我们团队如何使用组件构建微前端的经验。我将展示并解释我们如何将Web开发拆分为解耦且可维护的代码库，如何轻松替换或集成新的功能和技术，如何使团队能够独立地构建和发布生产环境的变更而不会互相干扰，如何实现高达100%的组件重用，以及如何构建可扩展的架构和组织结构，使其能够随着我们的发展平稳增长。
Our shared component infrastructure
我们的共享组件基础设施
Naturally, different teams use different stacks and tools to build their technologies.
不同的团队自然会使用不同的技术栈和工具来构建他们的技术。
For the development of our web platform and websites we chose React. With the release of features like Hooks and Context-API, React became a great choice for us to develop modern applications from smaller, independent, and reusable pieces.
对于我们的Web平台和网站的开发，我们选择了React。随着Hooks和Context-API等功能的发布，React成为我们从较小、独立和可重用的组件构建现代应用程序的绝佳选择。
For a shard infrastructure that supports component-driven micro front-ends, we used Bit’s open-source tools and cloud platform.
对于支持组件驱动的微前端的共享基础设施，我们使用了Bit的开源工具和云平台。
Apart from dogfooding our product on a daily basis, Bit provides us with a few necessary features for adopting our micro front-ends architecture:
除了每天在我们的产品上进行自我使用外，Bit为我们采用微前端架构提供了一些必要的功能：
- Our OSS tools let us develop many modular components in any given codebase, with a modular workspace that helps us build with independent components. Components can be independently developed, rendered, built, tested, versioned, published, and even go through CI without being coupled to any specific project.
我们的开源工具让我们能够在任何给定的代码库中开发许多模块化组件，使用模块化的工作区帮助我们使用独立的组件进行构建。组件可以独立开发、渲染、构建、测试、版本化、发布，甚至可以通过CI进行处理，而不与任何特定项目耦合。
In addition, Bit provides two more critical features: First, it provides universal control over the dependency graph of all components. It automatically resolves each component’s dependencies, and lets you know exactly what should change whenever there’s a change to any dependency. Second, it provides 0-config reusable and customizable development environments so that components can go through their own build pipeline in separation from any larger project, and these changes can be built across the entire dependency graph of components.
此外，Bit还提供了另外两个关键功能：首先，它提供了对所有组件依赖图的通用控制。它会自动解析每个组件的依赖关系，并在任何依赖关系发生更改时告知您需要进行的确切更改。其次，它提供了零配置的可重用和可定制的开发环境，以便组件可以在与任何较大项目分离的情况下通过自己的构建流程。这些更改可以在组件的整个依赖图中进行构建。
This sounds like a lot, and it is, but Bit actually makes it quite simple to build independent components that can be developed and released on their own.
听起来很多，而且确实是，但Bit实际上使得构建独立组件并能够独立开发和发布它们变得非常简单。
- Our cloud platform provides teams (including ourselves) with a collaboration hub where everyone can publish components, easily document them (bit automates this process), discover and install them. This lets our teams share and reuse close to 100% of the components we build.
- 我们的云平台为团队（包括我们自己）提供了一个协作中心，在这里每个人都可以发布组件，轻松地对其进行文档化（Bit自动化了这个过程），发现和安装它们。这使得我们的团队可以共享和重用我们构建的几乎100%的组件。
To make sure each frontend gets its own independent and fast build process, Bit also provides a unique CI/CD process that is 100% component-driven, which means that different teams can safely integrate changes without having to wait, fight over master, or break anything. Developers can continuously and safely propagate changes to components across all impacted applications.
为了确保每个前端都拥有独立且快速的构建过程，Bit还提供了一个独特的CI/CD过程，完全基于组件驱动。这意味着不同的团队可以安全地集成更改，而无需等待、争夺主分支或破坏任何东西。开发人员可以持续而安全地将更改传播到所有受影响的应用程序中的组件。
Instead of building every monolithic project in one build process that all teams have to go through, the component-driven CI splits the build process so that it only runs on the components that actually changed, and propagates the changes infinitely up their dependency graph, to build every impacted component, on every page, in every app.
与让所有团队都必须经历的单一构建过程不同，组件驱动的CI将构建过程拆分，只在实际发生更改的组件上运行，并沿着它们的依赖图无限传播更改，以构建每个受影响的组件，在每个页面的每个应用程序中。
This lets us free the release pipeline of different teams from each other, so that each team can independently and continuously release changes and updates to production. It also means about 50X faster builds, since not everything is built. And, we can pinpoint issues and bugs down to specific components.
这使得我们可以将不同团队的发布流程相互解耦，以便每个团队可以独立而持续地将更改和更新发布到生产环境中。这也意味着构建速度提高了约50倍，因为不需要构建所有内容。我们还可以将问题和错误精确定位到特定的组件。
Successful changes can be automatically translated into pull-requests that are automatically sent to all relevant projects, so that their maintainers can safely adopt the changes and make sure their applications are always up to date with the latest versions. Bit.dev also provides us with an overview of all components in our different projects, so that we can monitor and regulate exactly who’s using which component in what version.
成功的更改可以自动转化为拉取请求，并自动发送到所有相关项目，以便其维护者可以安全地采纳这些更改，并确保他们的应用程序始终与最新版本保持同步。Bit.dev还为我们提供了对不同项目中所有组件的概览，以便我们可以监控和调节谁在使用哪个组件的哪个版本。
Conways’ Law states that there’s a strong correlation between software architecture and the organizational structure. That is very true when building micro front-ends, as the main goal is to make the organization more efficient. Decoupling codebases, enabling integrations, or splitting the release pipeline, are all ways to build better software as well as autonomous agile teams.
康威定律指出，软件架构与组织结构之间存在着很强的相关性。在构建微前端时，这一点非常正确，因为主要目标是使组织更加高效。解耦代码库、实现集成或拆分发布流程，都是构建更好的软件以及自治敏捷团队的方法。
A small team empowered to make decisions and relentlessly drive toward their goals will deliver results and insights much more quickly than a larger group. After all, who knows the product’s users and problems better than the team who owns it, right?
一个小团队在拥有决策权并不懈努力地追求目标时，将比一个较大的团队更快地交付结果和见解。毕竟，谁比拥有产品的团队更了解产品的用户和问题呢，对吧？
Thanks to the flexibility of our component-driven architecture, we were able to assign team ownership and a much more dynamic, vertical and context-relevant way. Instead of having a “front-end team” for bit.dev and a “marketing website team” work together on a monolithic app, we completely separated these teams in every way.
由于我们的组件驱动架构的灵活性，我们能够以更加动态、垂直和与上下文相关的方式分配团队所有权。与其让“前端团队”和“营销网站团队”在一个单体应用程序上共同工作，我们在各个方面完全将这些团队分开。
To start with, a few developers are considered the “front-end infrastructure team” and are reporting directly to maintain the bit.dev platform’s basic set of components. On this team there’s also a designer, a product manager and a few more stakeholders. They build, release, and update their features independently from other teams that use them.
首先，一些开发人员被视为“前端基础设施团队”，直接向维护bit.dev平台的基本组件报告。在这个团队中还有一个设计师、一个产品经理和几个其他利益相关者。他们独立地构建、发布和更新他们的功能，与其他使用这些功能的团队无关。
The “Component Search” team, responsible for the complex search feature on bit.dev, is made of a few developers (both front and back), one NLP researcher, and a product manager. It exposes components for other teams to integrate into their products.
负责bit.dev上复杂搜索功能的“组件搜索”团队由几个开发人员（前端和后端）、一个自然语言处理研究员和一个产品经理组成。他们提供组件供其他团队集成到他们的产品中。
The “Component Discovery” team includes a few developers, a part-time designer, and a part-time product manager, to build the set of components used to document, visualize, and interact with the components shared on the bit.dev platform. In fact, thanks to Bit, the same documentation components are used both in Bit’s local development workspace, as well as in the cloud platform, are all built by this team.
“组件发现”团队包括几个开发人员、一个兼职设计师和一个兼职产品经理，用于构建一套用于文档化、可视化和与bit.dev平台上共享的组件进行交互的组件集。事实上，多亏了Bit，这个团队构建了在Bit的本地开发工作区和云平台中使用的相同文档组件。
A few more developers were assigned to the marketing team to build the marketing set of components, along with a few marketers and a designer, and these components are used to compose our marketing website as well as a few more applications.
还有一些开发人员被分配到营销团队，与几个营销人员和一个设计师一起构建营销组件集，这些组件用于构建我们的营销网站以及其他一些应用程序。
The customer success team, with its own developers, builds and maintains its own set of components that implement different user interactions used across the Bit.dev platform, and even in additional websites and applications, we build.
客户成功团队拥有自己的开发人员，构建和维护实现Bit.dev平台上不同用户交互的一套组件，甚至在其他网站和应用程序中也使用这些组件。
And so the list goes on, while each feature becomes a team autonomously responsible for building and shipping components, for other teams to integrate and use as well.
如此循环往复，每个功能都成为一个团队独立负责构建和发布组件，供其他团队集成和使用。
Simple, decoupled codebases
简单、解耦的代码库
Decoupling codebases makes features easier to develop, test, maintain, replace, or upgrade. We wanted to be continuously able to add new technologies and features.
解耦代码库使得开发、测试、维护、替换或升级功能更加容易。我们希望能够持续地添加新的技术和功能。
Each of our teams works in a completely different and decoupled codebase. It develops, tests, and maintains its features without the limitations and pains of working inside a complex monolith with other teams.
我们的每个团队都在完全不同且解耦的代码库中工作。它们在没有与其他团队在复杂的单体应用程序中共同工作的限制和困扰下开发、测试和维护其功能。
The source-code for each feature or product is naturally much smaller and simpler than that of the entire application, which makes each codebase much easier to develop, test, and maintain without the limitations and pains of working together inside a monolith.
每个功能或产品的源代码自然比整个应用程序的源代码要小得多，也更简单，这使得每个代码库在没有与单体应用程序中共同工作的限制和困扰下更容易开发、测试和维护。
If you look back at the “base-ui” and “evangelist” examples on the bit.dev homepage, you’ll notice that each set of components is developed in a different codebase. Both sets are decoupled from each other, and are integrated together to create different pages, features, and applications.
如果你回顾一下bit.dev首页上的“base-ui”和“evangelist”示例，你会注意到每个组件集都是在不同的代码库中开发的。这两个组件集彼此解耦，并在一起集成，以创建不同的页面、功能和应用程序。
Since all codebases are decoupled from each other, and each is composed mostly if not entirely out of components, it also becomes much (much) easier to gradually refactor parts of our applications, so that we can quickly and safely add or replace technologies.
由于所有代码库都彼此解耦，并且每个代码库主要（如果不是完全）由组件组成，因此逐渐重构我们应用程序的部分变得更加容易（非常容易），这样我们就可以快速而安全地添加或替换技术。
Over time, having to clearly define what code belongs in each codebase, is a great way to better understand the architecture we’re building, and the role of each part inside it.
随着时间的推移，清楚地定义哪些代码属于每个代码库，是更好地理解我们正在构建的架构以及其中每个部分的角色的好方法。
Independent release pipelines
We are able to split and decouple the release pipeline of different teams from each other, so that every team can independently build and release changes to multiple applications, without waiting for versions to bloat or fighting over master branches.
我们能够将不同团队的发布流程分割并解耦，使得每个团队可以独立地构建和发布对多个应用程序的更改，而无需等待版本膨胀或争夺主分支。
As mentioned above, through Bit and Bit.dev we are able to assign a custom yet standardized build pipeline for every team’s set of components. So despite being built separately, all components can go through the same tasks and tools.
正如上面提到的，通过Bit和Bit.dev，我们能够为每个团队的组件集分配一个自定义但标准化的构建流程。因此，尽管是分开构建的，所有组件都可以通过相同的任务和工具进行处理。
Then, the (50X faster) component-driven CI process on Bit.dev (in Beta) maps and builds changes up the propagating dependency graph of all dependent components across every single page and every single application.
然后，在Bit.dev上（测试版中）进行的基于组件的CI过程（构建和持续集成）会在所有相关页面和应用程序中的依赖关系图中映射和构建所有依赖组件的更改。
Put into simple words, every team can make a change to any component, independently build these changes, and learn if and how it breaks other components and other teams across all relevant applications.
简单来说，每个团队都可以对任何组件进行更改，独立构建这些更改，并了解它是否以及如何影响其他组件和其他团队在所有相关应用程序中的情况。
If all is well, the changes are automatically translated into a Pull-Request that is sent to all relevant projects, so that their owners can update their components. They even get notifications and reminders via Slack. In the Bit.dev “Projects” feature (another one of our teams), we can view and monitor who adopted which PR and where.
如果一切顺利，这些更改会自动转化为拉取请求，并发送到所有相关项目，以便其所有者可以更新其组件。他们甚至会通过Slack收到通知和提醒。在Bit.dev的“项目”功能（我们的另一个团队）中，我们可以查看和监控谁采用了哪个拉取请求以及在哪里采用。
So instead of messing with cumbersome iframes or finding alternative solutions, we rely on build-time integrations that do not couple our release processes together. For now, this works amazingly well for us, and our component-driven CI will be out of Beta within weeks, so feel free to take a test drive when it’s out too. In the future, we do have a plan to go all the way and enable component-driven deployments to applications.
因此，我们不再使用繁琐的iframe或寻找替代解决方案，而是依赖于构建时的集成，这样就不会将我们的发布流程耦合在一起。目前，这对我们来说非常有效，我们的基于组件的CI将在几周内推出测试版，所以当它发布时，可以随时进行测试。在未来，我们计划进一步实现基于组件的应用程序部署。
More incremental upgrades
更多的增量升级
Now that our codebase is built from decoupled smaller codebases, which are built with modular components that are independently versioned, we have gained a very useful ability to easily add, replace, hotfix, or even rollback a single component or feature.
现在，我们的代码库是由解耦的较小代码库构建而成，这些代码库使用独立版本化的模块化组件构建。因此，我们获得了一个非常有用的能力，可以轻松地添加、替换、修复甚至回滚单个组件或功能。
Teams can make case-by-case decisions, rapidly change and deliver upgrades and features, and treat refactoring as a gradual on-going process that can be done one piece at a time. Also, our entire software become more resilient, as it becomes almost impossible for developers to break things outside the scope of their components.
团队可以根据具体情况做出决策，快速更改和交付升级和功能，并将重构视为逐步进行的过程，可以逐个部分地完成。此外，我们的整个软件变得更加弹性，因为开发人员几乎不可能在其组件范围之外破坏其他部分。
One thing that we especially enjoy, is the ability to respond fast to user requests. When a developer asks for a new component build environment that support a certain Stencil version, for example, we can create and add it in a few hours instead of weeks. And, since much of Bit is open-source, we can make it easy for people to extend or replace any part of their toolset on their own. This makes our entire team much more efficient.
我们特别喜欢的一点是能够快速响应用户请求。例如，当开发人员要求支持特定Stencil版本的新组件构建环境时，我们可以在几个小时内创建并添加它，而不是几周的时间。而且，由于Bit的许多部分是开源的，我们可以让人们轻松地自行扩展或替换他们的工具集的任何部分。这使得我们整个团队更加高效。
We publish all our components to Bit.dev. There all our teams share, discover, collaborate, and reuse components with each other in fun and effective way.
我们将所有的组件发布到Bit.dev上。在那里，我们所有的团队可以以有趣而有效的方式共享、发现、协作和重用组件。
Added features such as visual component documentation, a smart component search, and even live simulations all help to make all our components discoverable so that we don’t have to maintain any additional documentation websites, registries or tools.
增加的功能，如可视化组件文档、智能组件搜索甚至实时模拟等，都有助于使我们所有的组件可被发现，这样我们就不必维护任何额外的文档网站、注册表或工具。
This collaborative system makes it easier for developers to share code, suggest feedback, and ensure consistency. We especially enjoy the fact that it helps new developers who join the team cut their learning curve, as they can find and start using existing components so that they can hit the ground running and start building.
这种协作系统使得开发人员更容易共享代码、提供反馈意见并确保一致性。我们特别喜欢它能帮助新加入团队的开发人员缩短学习曲线，因为他们可以找到并开始使用现有的组件，从而能够快速上手并开始构建。
It’s also a useful way for us to improve collaboration between developers and other stakeholders like our designers and product who can now see all our components.
对于我们来说，这也是改善开发人员与设计师、产品等其他利益相关者之间协作的有用方式，他们现在可以看到我们所有的组件。
Some say micro front-ends is nothing but a “good component model”. For us, it was a good component model as much as it was a better way to build our own team, improve the way we work, build better modular software, and deliver it faster and more often.
有人说微前端只是一个“好的组件模型”。对我们来说，它不仅是一个好的组件模型，也是构建我们自己团队、改进我们的工作方式、构建更好的模块化软件并更快更频繁地交付的更好方式。
For larger organizations, independent team delivery is a true game-changer in their ability to build and ship successful web applications. So is the ability to standardize component development, and allow teams to share and collaborate with each other.
对于较大的组织而言，独立团队交付能力是构建和发布成功的Web应用程序的真正改变游戏规则的因素。同样重要的是，能够标准化组件开发，并允许团队之间共享和协作。
For smaller teams, adopting a flexible and scalable architecture will improve their ability to grow, rapidly add new features, onboard new people, and focus on core technology and innovation instead of on less important things.
对于较小的团队来说，采用灵活可扩展的架构将提高他们的增长能力，快速添加新功能，引入新人，并将重点放在核心技术和创新上，而不是其他不太重要的事情上。
I hope you’ll find something in the idea of component-driven micro front-ends that can be useful for you, and thanks for reading!
希望你能从基于组件的微前端的理念中找到对你有用的东西，谢谢阅读！
3、Technique/Tips 分享一个小技术
网页开发时经常有“头图”的需求，即一个横贯整个屏幕上端的图片。 一般的做法是定义一个固定高度的块级元素，如 200 像素高，屏幕较小时图片两侧内容隐藏。 然而，问题是固定的高度对于在笔记本这种小屏幕上进行显示时，头图高度过高会导致下面主体内容不能在一屏内显示。
能否采用一种方式使得“头图”能根据屏幕宽度和固定的宽高比例对高度进行调整呢？
我们可以采用 padding 百分比进行固定比例的控制，让小屏幕下的头图高度天然等比例缩小。
HTML：
<div class="box">
<img src="https://demo.cssworld.cn/images/4/cover-5-1.jpg">
</div>
.box {
padding: 10% 50%;
position: relative;
}
.box > img {
position: absolute;
width: 100%;
height: 100%;
left: 0;
top: 0;
}
效果图：
这里 box 块级元素的宽度为 auto，会自动铺满父容器。效果图中笔记本宽度为 1046 px，高度为 0。设置了 padding: 10% 50%，padding 的宽高百分比是相对于本元素即 box 元素的宽度进行计算的，因此 box 的padding-box的高度是209.188 px。
box 内的 img 元素的定位方式为绝对定位，它的包含块由其祖先的 padding-box 组成，而非 content-box，因此 img 的宽度等于 box 的宽度为 1046px，高度为 box 的 padding-box 的高度为 209.188 px。
4、Share 分享一个观点
在每次失败后加一个 yet（目前），能极大地鼓舞自己继续朝着目标前进。
比如：我这次失败了，是因为目前还没有掌握所需的技能，但是我会继续更加努力，让成功早日来临。
