The original plan was to write this article during the Chinese New Year, but it was already April.
Take a look back at what you did and what you should have done but didn’t do from the time you returned to CrowdSourcing in 2018 to the time you left at the end of your life cycle.
Design/Interaction
The old system design style is upgraded and optimized.
In the early stage, due to the problems of product-level planning, color matching, interaction and LOGO of each system were different due to different product positioning and preferences of different product managers.
The old system was relatively old in color matching, so we adjusted and updated the overall color matching through a period of research and communication with the superior leaders. And the interaction of the old system has been improved, so as to sort out a complete set of design specifications.
Design specification mainly from spacing, alignment, color, layout, font, icon, copywriting, data entry, data display, data visualization, information feedback, micro-effect of these aspects of sorting and constraints.
In the interaction of customer service group, product group and some customers, and reference to some books to sort out a set of interaction principles.
I also worked out a new communication process.
Componentized/microfront-end
Why do we put these two together? Let me draw a picture.
Each column is a separate system (a separate domain name, a separate template engine, and a variety of front-end stacks all in one place) with different color schemes and interactions.
For example, we had a requirement to modify some header information, and finally we found that all systems needed to be modified. After counting, more than 10 systems needed to be modified at the same time, which caused problems in maintenance and release.
So we made the above design changes, and we did a two-piece thing on the front end.
componentization
The main differences between b-end products and C-end products are as follows:
- B-side products pay more attention to the clarity of business processes. When the business complexity of a page is high, the interaction between components will be very complicated. This leads to a large number of component types and small animations.
- There may be dozens of interfaces on a page at the same time, and to ensure the simplicity of the server, the data volume provided by the backend is extremely large.
- Compared with c-side products, B-side products are more complex at the business level, that is, the difficulty of reusing data structures and business components.
So the following adjustments were made
Micro front-end
After the development of the component library, the primary task is how to quickly change the components in, and the effect.
The current micro front-end schemes are investigated, and there are several schemes:
- Distribute the packets through routes. Our current system is routed, so we don’t want to change the route.
- Distribute by iframe. Our system is embedded in the peer system itself, so try not to have multiple layers of iframe embedded.
- Web Components.
Finally, we chose JQ and AngularJs-related projects to be embedded as components and React related projects as components.
Common components/components are written in React and compiled to support JQ and AngularJS.
This raises the question of how to ensure that all systems are updated when the public part is distributed among them.
The following figure
APP design
In the second half of the year, we received a new task to complete a version of APP on the basis of existing products, and integrate the current different product lines into the APP.
On the business
Each product line is an independent business, and independent teams may be responsible for it. According to the traditional model, repeated modifications in the same project will bring a lot of communication and cooperation costs, and the code can not be maintained.
Technology selection
After the investigation, we analyzed
- The native. We are the front end team, and we are good at the front end and the server side. We have no technical reserves or personnel reserves for Android and IOS.
- Weex. Ali is the main, side understanding, basically in a semi-updated state.
- Hybrid model. It is relatively simple and easy to use, but the overall performance is slightly worse, and the package size is slightly larger.
- RN. The technology stack matches, the community is extensive, and there are many projects that can be referred to at present.
Eventually we decided to use RN for development. For us, the details of development can be overcome, but we just need to achieve the separation of multiple businesses.
The final plan is as follows:
The application layer
The development of the entire application layer follows the basic framework mentioned in the previous article with some changes to the overall architecture.
Just post a drawing of the structure
Team management
I have been working as a Leader for 5-6 years. There are more than 20 leaders when there are many people, and 2-3 leaders when there are few. Let’s summarize some of my feelings.
Do technology or management
Technical people all have a big common problem (I also) that is, I think my own project is the most appropriate and awesome, this person does something completely inconsistent with my idea, but I can not get started quickly.
In fact, no one is right or wrong in this matter. As managers, we should ensure the continuation of team technology according to the overall planning, and give more tolerance and space to other students in other aspects.
As a manager, we need to listen to everyone’s voice and support everyone’s growth just like parents.
Get people to do what they can do, want to do, and need to do, and help team members find their place and role in the team.
Focus on the front End
This topic has been heard in a variety of contexts. What does it mean to be valued? It’s really a question of voice.
In order to get the right to speak, we need to be relied on first. From the earliest 3-5 members of our team only responsible for front-end related work, gradually we began to have our own independent business, until I left our team and took charge of the development of the entire application layer.
On “Money”
Programmers are very thin-skinned, in the long salary this matter is rarely mentioned, also met a lot of managers before, as long as you do not mention, certainly will not fight for you.
Why is that? Is nothing but afraid of troublesome leadership, in case the leadership does not agree with me have different ideas?
Only by sacrificing a small part of their own interests to strive for the interests of the team can the team have more executive power and cohesion.
On “Superior and Subordinate”
Serve as Internet person more should be service consciousness, who is superior in the end who is subordinate, important??
Conclusion:
I would like to thank the students who support my team for their support and my leaders for supporting me.
It is a pity that the application layer is not completely finished, and the front-end tool chain is not finished either. I hope the team members can continue to work on it.
Everyone leaves or stays at some point in their life for a variety of reasons. Keep going.
Finally, attach the head pictures of some students drawn by our team Zhiming (various reasons have not been completed), come on ヾ(◍°∇°◍) Blue ゙.