Writing Various Documents

Frontend Component Conventions

Core Principles

Single responsibility: each component has a single, well-defined responsibility.
Data-driven: prefer data-driven control of components; only consider using refs to call component methods when data-driven control is truly impractical.
Component granularity: generally within 300 lines of code; beyond 500 lines, consider splitting the logic or refactoring.

Component Design Principles

Component Categories

Base components: no external dependencies, e.g. pure styling components
Composite components: compose base components with simple interaction logic, e.g. form groups / table pagination
Business components: bound to specific business scenarios, may include state management, e.g. order flows / user info cards

Component Communication

Props: prefer props for parent-child component communication
Events: use the event mechanism for communication between components
State management: use state management tools (such as Redux, Vuex) for complex state
Context: use Context for cross-level component communication

Component Reuse

Abstract shared logic: extract reusable logic into hooks or utility functions
Component encapsulation: encapsulate common UI into base components
Avoid duplicate code: reuse logic with higher-order components or the composition API

Naming Conventions

File Naming

Component files use PascalCase (e.g. UserProfile.vue)
Utility files use camelCase (e.g. formatDate.ts)
Style files share the component's name (e.g. UserProfile.less)

Component Naming

Component names use PascalCase
Base components start with a specific prefix (e.g. BaseButton, BaseInput)
Business components are named after their functionality (e.g. UserList, OrderForm)

Variable Naming

Variables use camelCase
Constants use UPPER_SNAKE_CASE
Boolean variables start with is, has, can, etc.

Style Conventions

CSS Naming

Use the BEM naming convention
Avoid style pollution; use scoped by default

Style Organization

Split style files by component
Extract common styles
Manage themes with CSS variables

Performance Optimization

Render Optimization

Avoid unnecessary re-renders
Use virtual lists for long lists

Loading Optimization

Lazy-load components
Preload resources
Use Suspense appropriately

Testing Conventions

Test Types

Unit tests: test component logic

Testing Principles

Test key business logic
Keep test code concise
Update test cases regularly

Technical Planning

The Five Looks

Look at the industry/trends: study the overall development trends, technological progress, and policy/regulatory changes of your industry.
Look at competitors/competition: analyze the current competitive landscape, the strengths and weaknesses of competitors, and the possibility of cooperation. Look at the best players in your industry, learn from their strengths, see their future clearly, and benchmark against them.
Look at the market/customers: deeply understand market demand, consumer behavior, segment opportunities, and changes in potential customer needs. Who are the customers? What do customers buy? What are the needs?
Look at yourself: assess your company's own resources and capabilities, core competitiveness, organizational structure, corporate culture, and other strengths and weaknesses.
Look at opportunities: identify new business opportunities, blue-ocean markets, or strategic opportunities brought by technological innovation.

The Three Decisions

Decide the tactics: based on the results of the "Five Looks", clarify the company's business tactics for a specific period, including product positioning, market positioning, differentiation strategy, etc.
Decide the strategy (long-term): on the basis of a deep understanding of the internal and external environment, formulate mid-to-long-term development strategies, including but not limited to target market selection, growth path design, and business model innovation.
Decide the plan: turn the strategy into concrete execution plans and action programs, set short-, mid-, and long-term goals, and formulate implementation steps and resource allocation plans.

Root Cause Analysis (RCA)

Root cause analysis is a systematic method for deeply exploring the essential causes of problems, widely used in quality management, project management, incident investigation, and many other fields. Its core goal is to find the root cause of a problem and take effective measures to prevent it from happening again.

The analysis steps are as follows:

Define the problem: clearly state the specifics of the problem, including key information such as when and where it occurred, its scope of impact, and its severity.
Data collection and information organization: obtain all data and facts related to the problem through observation, records, interviews, document review, and other channels.
Layered cause analysis:
- Direct cause analysis: identify the surface causes that directly led to the problem.
- Root cause analysis: dig further into deeper causes, which may involve organizational culture, policies, processes, personnel skills, equipment and tools, etc.
Use analysis tools: common tools include the following
- 5W1H analysis (What, Where, When, Who, Why, How)
- Fishbone diagram (Cause and Effect Diagram)
- The "Five Whys" of asking why five times in a row, and Logic Tree analysis
Verify the root cause: confirm whether the identified root cause is accurate and reliable, by reproducing the problem scenario or finding other evidence.
Develop solutions: formulate corresponding improvement measures for the identified root cause, ensuring that these measures solve the problem at its source rather than merely addressing surface symptoms.
Implement and track: execute the improvement measures and continuously monitor their effects to verify whether they effectively prevent the problem from recurring; adjust and optimize the plan when necessary.
Continuous improvement: make the results of root cause analysis part of the organization's learning and improvement process, driving continuous improvement in overall business performance and quality.

SWOT Analysis

Strengths, Weaknesses, Threats, Opportunities

Strengths: internal strengths
Weaknesses: internal weaknesses
Threats: external threats
Opportunities: external opportunities

Leverage, Pause, Defend, Achieve

Leverage: make good use of strengths
Pause: slow down and remedy weaknesses
Defend: defend against threats
Achieve: capitalize on opportunities

Frontend Quality Assurance Plan

Three Stages, Four Dimensions

	Before (development stage)	During (integration stage)	After (production stage)
Infrastructure	Testing services (lanes, cloud real devices) Technical architecture standardization Supply chain quality General high-concurrency solutions Logging services	Branch management Build and deployment Static scanning (checklist)	Monitoring (errors, experience, public sentiment) Positioning systems Metric inspection Security
Testing	Standardized processes and methods Test case management API testing	Automated testing	Regression testing Crowdtesting
Risk control		Release freeze periods Gray release, progressive rollout	Backup, degradation Feature switches
Management	Technical proposals SOP Requirement management	Code Review	Development process metrics Online incident management

Development Stage

Testing Services

As the fundamental means of quality assurance, testing depends heavily on a well-established testing environment, powerful testing tools, and efficient testing services for its efficiency and accuracy.

For compatibility testing: advanced tools can simulate rendering pages on multiple devices with one click and automatically generate reports through screenshot comparison, significantly improving the speed of problem location. If they can automatically flag the device models with issues, they greatly simplify the discovery of compatibility problems.
For automated testing: convenient script recording allows even non-programmers to quickly create automated test cases without manually writing code to drive the test flow. Tools like NetEase Airtest have this capability, which can greatly expand regression test coverage and execution efficiency, reduce the burden of manual testing, and ensure that product quality is continuously and effectively verified.

Technical Architecture Standardization

Technical architecture standardization is based on best practices, and its core goals are to improve development efficiency and ensure development quality. Key mechanisms:

Preventing and eliminating potential problems: through hard constraints on design, technical architecture standardization can effectively prevent or reduce failure risks caused by human error. Pre-established technical specifications and framework constraints reduce the probability of mistakes as developers follow the standards.
Complexity control: facing the complexity challenges brought by ever-growing requirements and expanding technical scale, technical architecture standardization decomposes and simplifies system structure by adopting frameworks, componentization, and architectural patterns such as MVVM, thereby effectively managing and reducing implementation-level complexity.
Team collaboration optimization: by constraining development patterns and unifying the team's development style, technical architecture standardization helps maintain code consistency and maintainability, avoids extra complexity caused by individual style differences, promotes efficient collaboration among team members, and further improves overall project quality and stability.

External Dependency Quality Management

Common dependencies generally include: CDN, network, containers, APIs, base frameworks/libraries, SDKs (tracking, monitoring, etc.), bundling tools, and so on. The key is to form two judgments:

Whether the dependency is reliable: for example, if something goes wrong, can you find the maintainer? If a core dependency crashes, is there a fallback/degradation plan?
Whether the dependency is fully decoupled: for example, certain configurations should not exist across projects or teams, otherwise they will inevitably hurt each other
- CDN: the main problem is node failure
- Network: the main problem is hijacking. Once a resource is hijacked, the response lacks the cross-origin Access-Control-Allow-Origin: * header, which causes the resource to be rejected by the browser due to CORS, and the page breaks
- Container: WebView can have all kinds of problems
- APIs: monitor API exceptions; also consider monitoring API call volume
- Base frameworks/libraries: in principle, versions need to be locked. Don't fully rely on developers following semver — any change can cause a failure.
- SDKs: introduced SDKs can also cause problems. Monitoring SDKs must be loaded first, and must be loaded synchronously — consider inlining them to avoid network loading failures
- Bundling tools: detect ES6 code, detect circular references, detect duplicate packages, etc.

Logging

Scenarios that need logging: tracking a metric, troubleshooting problems, monitoring exceptions
Places that need logging: proactive monitoring (APIs, business exceptions, etc.), passive monitoring (network/resource latency and success rate, page performance, JS errors)

Technical Proposals

Technical proposals are usually led by the backend. After all, business logic mainly lives on the backend, while the frontend is only responsible for presentation. And since the backend involves database tables, caches, APIs, system call relationships, logic flows, etc., it is easy to draw a bunch of diagrams to explain. Without a clear guide, the frontend often doesn't know what to write in a technical proposal.

A technical proposal has three main purposes:

Think through key questions in advance: for example: scope of impact, dependent resources, data sources, core logic, API design, fallback plan, monitoring plan, testing plan, launch plan
The basis for scheduling: only by breaking down a large requirement can an accurate schedule be given
Peer review: from a team management perspective, each subdivision generally has at least a primary and a backup owner (or several people). During reviews, pull in the relevant owners as needed to help sweep for mines

SOP

An SOP (Standard Operating Procedure) is a process-standardized action guide. The standard an SOP should meet is that any newcomer can complete the entire operation step by step just by reading the document.

Requirement Management

Things requirement management can do include:

Question necessity and reasonableness: ask why first, for everything. Requirements with no clear benefit or unmeasurable benefit, decided on a whim, should be rejected or deprioritized (some things change if you just wait)
Large or exploratory requirements can be carried out in phases
Clarify what needs to be done: it should fall within the scope defined by the problem and the goal
Don't easily accept requirement changes: even for reasonable changes that must be accepted, put some pressure on the requester
Judge the product manager themselves: for example, someone who has just joined the team and proposes a fairly large requirement will very likely produce many requirement changes

Integration Stage

Branch Management

Pushing directly to master locally is forbidden; modifying master directly on the remote is forbidden
Merging into master must go through a PR, and approval is required before merging
Lock the branch used for production releases to prevent other branches from being deployed to production by mistake

Release Freeze / Gray Release / Progressive Rollout

A release freeze is a risk-control measure that avoids launching during holidays — not only because increased user volume can amplify the consequences of a failure, but also to avoid having no one available to fix bugs during vacations
Gray release mainly avoids an all-at-once launch, which would let potential failures go fully live in an instant
Progressive rollout is a fundamental philosophy, reflected not only in the release process but also in daily work

Code Review

What needs to be reviewed:

Code quality (pre-validation, boundary conditions, reuse, technical implementation, logging...)
Code readability (point out what is hard to understand, improve naming, add comments...)
Finding problems (technical implementation issues, business logic issues...)

Production Stage

Monitoring

The responsibility of a monitoring system is to discover problems as quickly as possible.

By monitoring approach
- Passive monitoring: passively listening via window.onerror
- Proactive monitoring: proactively reporting via try catch
By monitoring target
- Experience monitoring
- JS error monitoring
- Supply chain monitoring

References:

Backup, Degradation, Switches

Every key feature must have a backup plan, so that when problems occur it can automatically degrade, or be controlled via a switch to close the entry point.

Incident Management

Clarify the problem
Stop the losses in time
Locate the cause
Review and summarize