"Front-end" Craftsman Series (2): Qualified craftsmen, how to implement value | JD Cloud technical team

1. "Technology despises the chain?"

If you are a technical person, I believe you all know that there is a mutual contempt chain in the technical circle. From the perspective of technical people's own cognition, this chain is nested layer by layer with business value as the center, just like an onion. Specifically The description will not be repeated here.

Go out and turn left, just grab someone and ask. This kind of self-deprecating view is a bit similar to the self-deprecation of "programmers must wear plaid shirts" and "you only work with computers". Have fun, there is nothing wrong with it. But apart from jokes, a qualified technical person must always keep in mind his own value in an enterprise, and constantly expand the value through technological improvement, so that in the current environment, personal value and corporate value can be formed. Forward cycle. Then let's talk about how front-end functions can achieve value in different business scenarios.

2. "Technical people, are you valuable?"

When it comes to business value, there is a key word, which is "specific business context". Some people will say that technology is technology and is universal. Why should the concept of business be introduced into the value of technology? My answer to this question is also quite simple: technology itself has no business attributes, but the business environment in which the technician is located determines what type of value output the technician should provide to the environment at this moment.

For the job responsibilities in the front-end field, as mentioned in the previous article ( "Front-end" craftsman series: what should a qualified craftsman do (1)" ), "Its job role should pay more attention to the two parts of 'collection and presentation'", which means This functional positioning determines its value positioning in specific business scenarios.

First of all, the large-scale division is carried out from the coarse-grained level, and the B-side and C-side are divided first. From job recruitment, job positioning to OKR formulation and performance evaluation at home and abroad, we must first make the most basic distinction from the end type, because the B-end and C-end have different requirements for the front-end technology stack, technical depth and output value. Similarly, even the B-side R&D personnel are not familiar with native and multi-terminal R&D fields. If there is a position adjustment, there will be a relatively long technology switching period. Depending on the soft quality of the personnel, this period ranges from one month ranging from one quarter to the next.

What is B-side R&D?

The B-side usually refers to "Business-side R&D", but the current job descriptions of many companies for the B-side R&D also include the R&D of the A-side (that is, the business administrator Administrator). The characteristic is that most of the business is operated and empowered by the "enterprise-level background management system based on the Web technology stack with the PC browser as the runtime environment".

As for the technical value of B-end R&D personnel, depending on the business field, it can be divided into enterprise-level applications (such as Feishu, Tencent documents), commercial solutions (toB, toG business, such as some enterprise security business and commercial business) ), business background management (management background that assists C-end business logic), and other subdivision directions. The former is used for commercial realization, so these background projects have certain requirements for user experience. The requirements are relatively low.

What is C-end research and development?

The C-side is also called "Client R&D", which can be subdivided into device-side R&D (IOS, Android, Hongmeng), H5 R&D, and small program R&D from the perspective of technical job requirements.

Obviously, the basis of dimension division is the code running container, so is there a R&D solution of "one-time development, multiple operations"? This created the role of multi-terminal research and development. The corresponding technology stacks are solutions represented by React Native, Flutter, and Taro. Due to the different implementation schemes for multi-terminal, each has its own advantages and disadvantages. The specific selection According to the business background, the R&D team is required to make the most suitable technology selection based on business attributes (whether there is a preference for special terminals), team costs, maintenance costs, R&D efficiency, community activity, and the durability of future technology stacks.

Because the output of the C-end directly faces users, and the number of users is large, the C-end page has high requirements for special indicators such as design, interaction, business availability, and whether the user experience is good. Therefore, in technology-based enterprises, some enterprises For each of the special projects, there will be a group of people doing special optimization and improvement processing.

The following is a brief introduction to the focus of C-end R&D in different R&D stages.

  • Design stage: R&D personnel need to pay more attention to the rationality of design manuscripts and UI cutouts;
  • R&D phase: R&D personnel need to have more frequent, more reasonable, and clearer code comments;
  • Testing phase: Before testing, R&D personnel need to ensure the quality of use cases. After testing, R&D personnel pay more attention to quality indicators such as the bug rate of thousands of lines of code;
  • On-line stage: R&D personnel need to ensure that the on-line process is truly unmanned, automated, and log-detailed. Therefore, the processing scripts at each stage of the CI/CD on-line process must be completely rigorous and available;
  • After going online: R&D personnel need to monitor the running status of the online code on the user's device side through the monitoring, alarm and log platform. In case of abnormal operation, the R&D personnel need to be notified by the alarm platform in a timely manner, handle the online failure reasonably according to the SOP and stop the loss in time, and the bugfix will be launched after the repair;

The above is just a brief discussion of the differences in the basic quality requirements of R&D personnel for B-end business and technology. Based on the above business background, the following explains how to do the corresponding work well from the perspectives of technology, human resources and team capability design.

3. "B side, how to do it well?"

If you are doing B-side research and development of business delivery, after doing a good job of business support, find a way to achieve more efficient and high-quality delivery through "low code" or "zero code".

There are many specific implementation schemes, such as AntDesign, FusionDesign, and many commercial designs. The implementation idea is to establish a set of general and reusable material components based on business scenarios. It can be assembled and assembled. Some people think of Lego blocks, but this kind of design has relatively high requirements for application scenarios. If you want to use this kind of solution (especially for complex business scenarios, you can only use low-code solutions), you must Further thinking about data communication, UI communication and other issues between materials, it is even necessary to iterate the DSL analysis engine with the development of business materials.

For front-end personnel, the efficiency of the initial construction is actually reduced, but if it is used, the longer it is used, the more abundant materials will be deposited, the higher the matching degree with the scene, and the higher the delivery efficiency. However, from the perspective of cost, part of the R&D cost will also be transferred to the improvement of packaging and rationality of back-end services, and the entire business delivery will be tilted towards the construction-driven perspective. The reduction of comprehensive costs needs to be combined with the dimensions of overall R&D delivery. Consideration, but how to consider, whether the caliber of consideration is reasonable, and whether it can be implemented, each R&D team must "cross the sea and show their magical powers".

However, the selection of the low-code solution for B-end business delivery, from the perspective of manpower, as long as the data and code are safely handled, the "build + outsource" approach can be completely handled.

If you are doing research and development of commercialized B-end products, then you need to be more focused on product demands, constantly communicate and research with products and customers, and even go to on-site communication to discover the real experience and functions encountered by users in the process of using the product. problems, so as to continuously improve product iteration and optimization. "Low-code" and "zero-code" efficiency improvement solutions can only be used as tools for product incubation, but whether they can be used or not depends on your own evaluation.

4. "C-end, how to do it well?"

If you are delivering C-end products, you should pay attention to the smoothness and rationality of the R&D process, whether the code isolation, data isolation, and release isolation of the R&D environment, test environment, pre-release environment, and online environment are good, and resolutely avoid Abnormal business or surge in workload due to environmental pollution;

You should pay attention to the degree of restoration of the UI design manuscript, whether the dynamic effect is smooth, whether the page loading efficiency is good, whether the crash rate meets the standard, and whether the buried points are reported normally.

It is worth mentioning here that the buried point is a matter. For the C-end business, special work is required to handle the buried point work. The quality of the buried point work directly affects whether the business can get the correct user data after the functional requirements are launched. Then make adjustments to the business operation strategy. Therefore, the cost input of quality burying is necessary and should be valued by the R&D team. Otherwise, it will appear that there is no problem with the function and there are no customer complaints, but the business does not know it because it has received wrong user behavior data, but preconceived that its strategy is too "wow" or too "wow". result. If you make a wrong decision based on the wrong burying point but don’t know it, the impact on business value will be huge. What’s more serious, you will find out that you made a mistake after a long time. The best business opportunity has long since passed by. went.

If you are doing C-end infrastructure work, congratulations, you may be very close to the position of architect that many R&D personnel envy.

You need to pay attention to topics such as technology stack selection, material and component construction, event building platform, design intelligent delivery, multi-terminal compilation, rendering engine, etc., which are farther away from business but closer to technology. Achievement can give you more sense of accomplishment. However, because it is farther away from the business, it is necessary to avoid the situation of "self-indulgence". You need less annual planning and more quarterly planning and OKR of technical user pain point research trips. In business scenarios, your technical value can be reflected.

5. "Value, value, or value"

Please keep in mind, if your code is not online, if your code does not withstand the user's postgraduate entrance examination, if you do not pay attention to the quality and function related alarms after the code is online, if you do not pay attention to business and user behavior Data, the value of your work will be greatly reduced, or even worthless, because there is no difference between you and the one who works in the same way for the normal operation of the business.

Source: JD Cloud Developer Community

Author: JD Retail Liu Weidong (please do not reprint without authorization)

{{o.name}}
{{m.name}}

Guess you like

Origin my.oschina.net/u/4090830/blog/8805034