Improving Frontend Efficiency with the YuanShi Platform: Team Structure, Collaboration, and Component‑Based Development

Since early 2020 the "Big Front‑end" operations team at Beike spun off the YuanShi team to build a shared platform, producing the kemis‑pc and kemis‑m component libraries and gradually onboarding many product groups such as new‑house, rental, transaction, and efficiency engineering.

Front‑end talent shortage is a common pain point in the industry; the limited number of developers makes it impossible to meet page‑production demand, so teams focus on improving per‑person output through better tools, processes, and standards.

How to improve efficiency? The factors include member experience, team ladder, development model, scenario consistency, tool standardisation, framework uniformity, coding conventions, and quality. These can be split into a tool perspective and a team perspective .

Tool perspective covers development tools ( redskull ), build platform ( Qingchan ), publishing platform, component library ( ant‑man ), scaffolding, the unified Node framework ( hobber ), SSR framework, monitoring ( Lighthouse ), and visual configuration platforms such as HeTu , JieZi , and the marketing activity platform.

Team perspective emphasises clear division of labour, a reasonable team ladder, and unified norms that create a professional, reliable, and fun culture, which together boost communication efficiency and output stability.

The article then describes three stages of team evolution. In the rapid‑growth stage, a "chimney" model created many small front‑end squads, each handling multiple projects, which allowed fast scaling but caused duplicated code, limited technical growth, and communication silos.

During the stable‑and‑growth stage, teams became more settled, introduced a "floating group" of senior engineers to support high‑pressure areas, standardised on React, hobber , and a unified antd version, and achieved better monitoring and performance (e.g., Poison , dllplugin ).

To overcome remaining challenges, the author proposes a component‑centric cooperation model based on "沉淀场景" (scenario‑driven components). Components are classified as:

Basic components (原件) – generic UI, often from antd .

Business components – encapsulate domain logic but stay decoupled from APIs.

Interaction components – data‑exchange widgets such as forms.

Page composition – wiring components together.

By assigning responsibilities to the YuanShi team for basic and interaction components, while product teams own business components and page assembly, the organisation can measure success by component count, coverage, scenario‑driven reuse, and contribution metrics.

Benefits of this model include deeper business understanding for developers, cross‑team knowledge sharing, faster new‑business onboarding, and a stronger technical culture. Risks involve increased communication overhead, willingness to collaborate, and the cost of system refactoring.

Finally, the YuanShi platform aims to provide a unified UI spec, consistent component development guidelines, scenario management (dev‑test‑release‑consumption), a data‑display dashboard, and ecosystem support for performance and security, positioning the team for future collaborative scenarios across B‑end products.