If I am the front end team Leader, how can I make the front end collaboration specification? The Nuggets currently have more than 740 👍, thanks for your support, this article is an extension of the former. Continue my thinking and exploration in front end team management.

In software engineering, there is a software design phase, colloquial speaking, which is to be determined before the start of work, to consider the consideration. This is much cheaper to fix than finding a problem during development.

In textbook terms, software design is the process of turning requirements into software statements. Generally, there are Preliminary design (or Preliminary design) and Detail design. Outline design translates requirements into data and software frameworks, while detailed design refines the framework into concrete data structures and algorithmic expressions of software. This article describes the outline design of the front-end project.

For the front end, ‘software design’ is rarely mentioned compared to back-end development, and it may be that front-end work has always been ‘easy’ and therefore extensive. Typically, you give prototypes and interface documentation and just go dry. But as front-end developers get more complex, or projects/teams get bigger, there is a growing need for proper design before coding.

As a front-end entry-level Leader, I recently faced some problems, such as project division and lack of documentation for project maintenance, which made me start to pay attention to the software design stage. So far, there are at least the following benefits to doing a good front-end profile:

  • In advanceThe design document is the blueprint for development, and subsequent development can follow this document step by step. Good design can keep development on track.
    • In the design stage, we will further comb the business process, deepen our understanding of the business process, and even find out the unreasonable things in the business process.
    • Module split. In this stage, we will identify the boundaries and overlaps between modules and extract the overlapped (shared) parts. In addition, modules are the basic units of development work and the basis for our team’s division of labor and time assessment.
    • Examine key technical points. Put forward a variety of alternatives, fully consider all kinds of risks, choose the plan in line with the actual needs
  • After the event. Design documents after the software maintenance, new functions, have a great help


Let’s start with what the front-end should consider during the software design phase, or what should be included in the front-end summary design document. Of course, these are just some preliminary ideas, and this article will continue to be updated and iterated as we go deeper into practice.


The article Outlines

  • Review of key business processes
  • Key Technical points
  • Module design
    • Entrance layer
    • Page layer
    • Component layer
    • Division of labor
  • The state of design
  • Interface design
  • Release planning
  • validation
  • Project requirements and objectives
  • Document indexing
  • Build instructions
  • Continuous iteration
  • The template
  • conclusion
  • The resources


series

  • If I am the front end team Leader, how can I make the front end collaboration specification? 🔥
  • If I am the front end team Leader, how can I do a good summary design
  • If I am the front end team Leader, how to use Kanban to manage tasks well?


I have little experience and practice in this respect, and I have never been in dachang. Therefore, this article is just my thoughts and attempts, which may not be realistic. If you or your team have better practices in this area, please share them with me. Appreciate 🙏





Review of key business processes

The first thing you need to ensure before developing any product is that you understand the business process, otherwise it will go the other way.

It has happened many times in real life projects: when the project reaches the testing phase, the tester discovers that the business implementation of the application is different from the product definition, or the business process does not make sense. This is a low-level error that can be costly to change and can even cost you all your work.

Well-managed companies have plenty of tools to avoid such mistakes.

For example, define clearly defined requirements documents, which can be written in a standard/Spec style, strictly defining keywords and avoiding ambiguous descriptions.

In addition, various publicity meetings can be held to bring relevant people together and unify the introduction of requirements. These meetings allow brainstorming, refining or refining the definition of requirements, identifying defects and risks, analyzing feasibility, and more. Through continuous communication, members can share cross-knowledge and ensure a consistent understanding of the business.


Therefore, I feel that the front-end should be designed in the same way as the back-end, using tools such as flow charts or sequence diagrams to clearly describe the key business processes. In particular, scenarios involving front and back ends, business interactions across systems/pages/terminals.

For example, let’s say we’re doing a ‘scan login’ feature. We can tease out the business across terminals:


From the business combing above, we can identify the basic behavior and state of the business objects. For example, the state transition diagram of two-dimensional code:


Of course, it is meaningless to simply add, delete, check and change the length to elaborate. We only focus on applying the key business processes.

In short, the sorting of business processes can deepen our understanding of business and is the basis of subsequent design steps and development.





Key Technical points

Describes the key technologies/algorithms used by or involved in the application, which can also be considered as technology selection.

For example, typical live video applications involve various live broadcast schemes:

  • RTMP protocol
  • RTP protocol
  • HLS agreement
  • flv.js
  • WebRTC protocols
  • , etc.

Before starting a project, we need to research and test the key technology points involved in the project. It is best to find several alternatives and compare their advantages and disadvantages horizontally. Choose a solution that fits your project or team’s situation. If you have enough time, you can write some demos and put your foot in the hole.

If there are more than one alternative, finally select the recommended alternative and state the reasons and considerations for choosing it.

Do a good job of research and selection of technology in advance, determine the feasibility, not in a passive situation development.

As for how to select the technology, I am the Leader of the front end team in if. How to formulate the front end collaboration specification? Have a simple discussion, can refer to.





Module design

Modern front ends are developed with a componentized mindset, where our application is essentially a component tree composed of components of different granularity, which is ultimately reflected in the directory structure of the project. During the design phase, we can identify various pages and components based on product prototypes or UI designs.

Normal applications can be divided into three levels:

Entrance layer

A slightly more complex application may have multiple portals, and the pages rendered by these portals may vary widely. Here is a common partition:

  • By subsystems: foreground and background, for example.
  • By role: for example, administrator, common user
  • By entry: mobile, desktop, etc


Page layer

The next step is to identify the various pages that correspond to our front-end routing configuration rules. Take the following simple application for example:

As for the division of modules, I suggest using mind maps for organization. Module partitioning is where you can convene a meeting with the rest of the team to brainstorm. By referring to the product prototype, we can identify the boundary and intersection of various modules or components, discuss how to design the data flow of the page, the interface of components, etc., which can make use of the collective wisdom, make the module split more reasonable, and promote team members to get familiar with the structure of the project in advance.

Therefore, software design is not the work of architects or designers alone, and everyone should be encouraged to participate in it. Design documents are the output of the whole software team and the knowledge precipitation of the team.

The above application, divided by the page layer, results in something like this:

At this stage we will determine the following:

  • Page and routing design, determine the hierarchical relationships between pages
  • Page interaction process and data transfer

There are a few guidelines you can follow for routing design. I recommend Restful URL guidelines, and this article is good.

Data is transmitted between routes in the following ways:

  • Small amount of data: can be passed through routing variables (e.g/posts/:id) or as a query string. And if you’re usingFront-end routing pattern based on the History API, you can use HistorystateObject to store some state (Max. 640K)
  • Large amounts of data: It can be stored in global variables, or in a state manager mechanism, either in memory, which is lost once the page is refreshed. You can also consider storing it in a local cache, such as LocalStorage


Component layer

Ok, then go down to split, but do what you can. For a very complex project, with hundreds or thousands of components that may change in the future, considering these breakdowns at the design stage can take a lot of time and the benefits may not be obvious.

So how do you get granularity? In fact, the main purpose of the component layer design stage is to find out the repeated, or similar structure of components, extract them out of a unified design, reuse in multiple pages. Not all components are listed.

In the React Component Design Practice Summary 02 – Component Organization, I describe how the React component is organized and broken down. The following centralized models are proposed:

  • Container components are separated from presentation components. Or separate the view from the logic, the business component from the dumb component. Purely logical things are much easier to use in Hooks
  • Pure and impure components. Pure components can be thought of as completely dependent on external inputs
  • Stateful components and stateless components
  • Layout components and content components
  • Uniformly design interfaces for components of the same type. For example, form components should keep their interfaces uniform

As in the example above, the declaration page has a lot of form items and changes frequently, plus you’ll find that it has a similar structure to the preview page, and there may be a desktop page behind it.

After some discussion, we decided to use configuration files to dynamically render the form page and preview page. Realize a set of configuration control mobile application form, desktop application form, mobile preview, desktop preview page.

For application scenarios like the one above, prior component layer design is necessary.



Division of labor

Once the modules are broken down clearly, we can make reasonable division of labor and time evaluation for these modules. There are basically three steps:

After identifying the various modules through the above steps, we then need to determine the dependencies between these modules that affect whether they are implemented as a whole. Finally, the implementation priority of these module clusters is determined according to the business priority or dependency relationship.

Ok, now you can organize these module clusters into a list by prioritizing them, plus evaluation time (person days). If you use Kanban for project management, you can post them as a task unit in kanban.

1. Foo function -c 2D-d 1D-F 3D 2. Bar function -e 1D-h 0.5D 3. Baz function -g 1D 4Copy the code


There are many strategies for the division of tasks, such as:

  • Horizontal partitioning
    • Common Components vs Business Components (interconnecting business)
    • Top-down vs. bottom-up (component tree)
  • Vertical division: Division of labor according to independent vertical modules





The state of design

Front-end componentization is accompanied by various data-driven or data-stream-driven development patterns. In this model, the front-end application can be summed up in the following equation:

view = f(state)
Copy the code

That is, a view is a mapping of data or data flow. You can see the importance of state management to modern front-end development.

State design is similar to back-end object model design. You need to abstract the various object models based on the business and page rendering requirements, as well as tease out the relationships between the object models. This phase may require close integration with the back end to determine the proper object structure.

Of course, the design of the state also depends on the state management scheme you choose. The idea of different state manager schemes is quite different: if you choose Redux, the state of your application is a tree of objects; If you choose Mobx, your application’s state may consist of multiple model objects, closer to the traditional OOP pattern.

If OOP design is used, UML diagrams can be drawn to visually represent the structure and relationships of objects:

(Photo credit:Zongren. Me / 2016/12/30 /…)


My React Component Design Practice Summary 05 – State Management article has spent a lot of time introducing the ideas and development patterns of various state managers, so I won’t expand on them here:

Redux state design:

Mobx state design:





Interface design

If the front end team takes the lead in interface design, or uses the BFF architecture (the back-end that serves the front end), we need to design the various interfaces during the design phase.

General dominance in the back-end hands, however, because the front concern for business degree is low, the back-end generally considering interface requirements at each end, database storage efficiency, maintainability and so on several aspects to design the interface, then the front is the user interface, we have a responsibility to verify whether the backend interface conforms to the requirements.

I am the front end team Leader in if. How can I make the front end collaboration specification? Various interface specifications have been mentioned. I will not repeat it here.





Release planning

Through the above steps, we have a pretty good idea of what we need to do and how long it will take. Next,

You should have a release plan that, for a large project, can be broken down into milestones, with an estimated release date. It is up to you whether you will work overtime or not. As a Leader, you should consider various influencing factors comprehensively and arrange version release plan realistically and reasonably.

The release plan may also need to be reviewed by the PM and project manager, and as a front-end project, the development plan often relies on the back-end team.


This release plan will include the following:

  • The version number
  • Release time
  • Contains the main modules





validation

Validation, or ‘test guidance’. In addition to the test cases provided by the test team, what else is important from a development (white box) perspective?

The product or test may only consider the operation of the application at the business level, and we need to take full account of anomalies, performance bottlenecks, and risk assessment from a development perspective. Clarify the risk response plan waiting.

These situations can also be fed back to the test team to refine the test use cases.


Project requirements and objectives

Some requirements are determined in advance, typically browser compatibility requirements for the front end. Don’t wait until the project goes live to ask me for IE6 compatibility!

These project requirements may affect our evaluation of development costs, selection, testing and other factors. Basically, for a front-end project, these are the requirements to ask in advance:

  • Browser compatibility
  • Operating environment, such as operating system, applets, etc
  • Point in time
  • Requirements for performance indicators, such as first screen indicators and data volume indicators





Document indexing

Front-end project development can be associated with many documents that are scattered, and it is best to gather them together in the design document for easy reference. Such as:

  • The requirements document
  • DEMO, UI design draft
  • The test case
  • Interface documentation
  • UI design specification document
  • Front-end specification document
  • .





Build instructions

If your project requires a design build process, this can also be mentioned in the design document.

For example, how to compile and run? How to test and debug? How to deploy or distribute? How is the code organized? Develop workflows, coding conventions, and more

New members can use these instructions to get started quickly.


Continuous iteration

A design document is not a one-off; it should follow the project through iterations, or it loses its meaning.





The template

Finally, standardize the format and content of some design documents

# XXX Outline design document

# # backgroundFill in the background of the project, or the purpose/starting point of the development or refactoring.## Key business processesYou can place key business process diagrams, state diagrams, object diagrams, and so on. Comb through key business processes## Key technology descriptionOptional, describe the key technologies, algorithms, selection conclusions used in the project, etc## Module split

- The entrance- Page routing- Component designs can be described using mind maps## State designDescribe the key domain objects involved in the application, such as appearance, behavior, and relationships. If OOP is used, UML can be usedInterface designOptional, as in the problemProject requirements and objectivesProject objectives, operating environment, compatibility requirements, performance metrics, and so on# # to verifyOptional, risk assessment, exception consideration, special test rules, test guidance, and so on## Division of labor and version planningOptional, can be maintained in a separate document or kanban## Build instructionsOptional, project organization, build, test instructions## Document indexIndexes and links to related documents## ReferencesExternal references to index pages in documents## CHANGELOGThis section lists the history of changes to this document. You must specify the content of the modification, the date and by whom it was modifiedCopy the code

Many developers don’t like to document, including me. We make excuses: ‘I don’t have time to do design’, ‘THE time I spent writing a design document, MY development is already done’.

These ideas were obviously not true, and the take-home message to me was that we were going to have to work on a team basis, that we weren’t going to ask for detailed design documentation, and that we were going to have to be rough when time was tight. It’s acceptable to wait for more time to review supplements; Or if the project is developed in multiple cycles, we can do detailed design at the beginning of each cycle.


conclusion

In modern software development, how to do the detailed design step? Here’s an answer:



It is basically consistent with what I have introduced above. A software ‘summary’ design document basically contains these chunks.

In this paper, to the end.


The resources

  • How to write a good software design document?
  • Software design document writing overview
  • In modern software development, how to do the detailed design step?