Author: JD Retail Liu Weidong
This article is the first in a series of articles, and it is a brief introduction. The purpose is to let front-end practitioners and non-practitioners who are interested in this field have a no-threshold understanding of the topic of "front-end".
"What is the front-end function"
Speaking of "front-end", Wikipedia's positioning of this technical role is "front-end (English: front-end) and back-end (English: back-end) are general terms that describe the beginning and end of a process. The front-end acts on collecting input information , back-end processing. The interface style and visual presentation of computer programs belong to the front-end.” For front-end R&D personnel currently serving Internet companies, the definition of this job is very clear. The front-end is a relative concept to the back-end, and its job role should pay more attention to the two parts of "collection and presentation".
From the above concepts, the normal responsibility of front-end R&D is to display data and business logic through coding work, and users interact with the system through the operation interface (or other delivery methods), and finally the user's interaction information can be expected according to the functional logic The transmission to the back-end service is submitted to the business back-end and further downstream algorithm layer for processing.
"What does coding work involve?"
The upstream stakeholders of the front-end R&D personnel include product and UI design, and the necessary input includes product documents and UI design manuscripts. The downstream stakeholders are back-end R&D personnel, and the necessary output is a complete set of interface interaction and logic processing implementation code.
The product should output PRD (abbreviation of Product Requirement Document) to the R&D team to describe the specific functional details of the product or iteration in detail, and carry out "language analysis" with R&D personnel and designers through the requirements review meeting. Interoperability conversion and translation" work, which can clearly express all product logic to different professionals, which is the most important link in the delivery of all requirements. For new or complex requirements, it is necessary for interaction designers and product personnel to jointly output interaction design manuscripts to explain the logic of product requirements from another dimension. From the perspective of the clarity of front-end R&D personnel's understanding of requirements, interaction design manuscripts Rigorousness and quality are very important.
UI designers need to design and draw materials such as UI style, color system, and dynamic effects of the interface according to product requirements documents and interactive design manuscripts, and output UI design manuscripts to R&D personnel. This work needs to be carried out by front-end R&D, product and designer personnel. Multiple rounds of communication to finalize all element details. The design quality of the UI design manuscript and the fineness of the description of the product logic directly affect the coding design method and efficiency of the front-end R&D personnel. Confirm and even redesign the details of the design manuscript with the designer. If this happens, it will definitely have an impact on the project schedule. Finally, the interface output of the front-end research and development must pass the acceptance test of the UI designer to complete the interface coding work.
The connection with the back-end R&D personnel is the top priority in the R&D work. In the end, a set of code packages recognized by the front-end and back-end R&D personnel that have passed the self-test of the smoking use cases is the qualified output at this stage. Interface specifications, conventions, and docking partners with a high degree of tacit understanding are the ideas that the industry continues to improve efficiency and reduce costs in the process of R&D debugging, joint debugging, and smoke testing. "Everything is a matter of people" and "agreement is greater than habit" all put forward requirements for soft power and rigor of process.
The last step in the R&D process is to go online after UAT acceptance. The "pipeline automation" method must be used to go online, which is what everyone often calls "CI/CD". Only by doing this can we ensure that the main version code is completely consistent with the online code version, and that the main branch will not become a decoration because the local code is compiled and packaged artificially and released online; all online-related merging, compiling, packaging, The core processes such as publishing are all scripts that are automatically run by the pipeline and deployed on each node of the pipeline in advance, so as to avoid online problems caused by human "errors".
"On the line?"
Going online is a topic worth discussing, because for R&D, only codes that go online and have expected or exceeded business value can be considered as making a little contribution to the company and society, and personal value can be displayed at work. be reflected. Is the completion of the online development the end of the research and development work? For many R&D teams, this is the final step. However, the R&D process only stops here and does not meet the standard of "qualification". A set of code, only after it goes online, can it be tested and used by real users, and the output of the R&D personnel can be regarded as the "beginning of life". Questions such as "whether the performance of the product meets expectations", "whether there is a boundary exception", "whether there is a situation where the page cannot be opened", "whether there is an abnormal display", etc. Topics that need attention.
Therefore, R&D personnel need to reserve in the code package in advance the grasp of "communication" with real online users, and make improvement measures that can improve user experience by analyzing users' "usability and performance", for example, "special logic customization Buried point reporting", "border monitoring", "system runtime monitoring", etc., only when these are done, can it be said that a user's function is really launched, and there will be the possibility of refined operation in the future. However, for many developers, "online is the end of demand", "online problems are fed back by business", "is there any customer complaint?" are all common psychology in R & D.
So how to establish a communication channel with users in a "pre-determined" way? Because this article is an article in the front-end field, we only talk about the front-end part this time.
"Communicate with users"
Effective communication requires effective information as a carrier. For technical implementation, it is to bury the core code blocks reasonably. When a special user behavior occurs, when the code processing logic goes to an abnormal processing unit, when a situation that is not covered by the code processing logic occurs, the buried point reporting code will trigger execution and send to the centralized buried point service Send a message. Through the analysis of the buried point information triggered by this user behavior, the technicians can obtain the "on-site reproduction" of the "normal or abnormal" situation of the user in the process of browsing or operating the page. Of course, this recurrence can be data information , it can also be screenshots or video backtracking. The specific method to use to reproduce user behavior should be "effective" as the goal, and factors such as "user traffic cost, R&D cost, performance impact, and storage cost" should be considered to make the final selection. .
"Real-time OR T+1"
For the monitoring of business front-end user behavior and trigger logic, there are two types of real-time monitoring and asynchronous monitoring.
In scenarios such as real-time attention to user behavior and real-time analysis, it is necessary to use real-time monitoring. This "real-time" is generally enough at the second level, and it is also possible to use the minute level for some services, depending on the needs of the business. For real-time monitoring, the reporting behavior is triggered and reported from each user's device. For large-volume businesses, the collection, reporting, collection, storage, analysis, and report generation of this amount of data are quite costly. Resources. In order to reduce costs and improve efficiency, the buried point service will first sample user data according to special rules (such as normal distribution) to reduce the consumption of resources and manpower in the process of analysis and report generation.
In scenarios such as user-side log query, recurrence of special boundary scenarios, and log troubleshooting and locating faults, "real-time" is not necessary. In this scenario, T+1 query is generally used, but the topic of storage period of a large number of level logs is introduced. , general enterprise application-level user logs are enough to save for 14 days, because for C-side logs, it is more about the recurrence, processing and follow-up of on-site failures. If the algorithm strategy needs user logs, It only needs to process user logs once within a certain period of time by using processing tasks, and store key data such as output labels and behavior characteristics. Basic user logs should still be archived or cleared to release resources to provide more valuable latest logs. use.
To sum up, real-time monitoring and non-real-time monitoring respond to two scenarios: real-time corresponding to "service availability, online runtime exceptions" and other usage demands, and non-real-time corresponding to "performance indicators, user log query, user behavior recurrence", etc. Use demands.
"follow-up"
After that, I will continue to talk about some topics related to "user experience, efficiency improvement, and page construction".