The words written in the front:

For the content involving “desensitization” in the article, the link is often a ring set a ring, unable to output, I’m sorry… With an idea that has been brewing for a long time, I turned on my computer and wanted to make a note of some thoughts. About the title, about the “front-end,” about the “architecture.” In fact, there is a lot to say, but the first few words were typed up and deleted. Trying to find a good place to start. But it always seems to go wrong. To get back to this topic, perhaps we should start slowly with previous knowledge.

Past knowledge

Admittedly, for a long time, when I was mostly focused on business, I was a little sniffy about the word “architecture.” Especially “front-end architecture.” Think that the “front-end” software engineering is relatively weak, still struggling to mature language field, to the existing software engineering slowly close to the direction, really need the so-called “architecture”?



I always feel like at this stage,

  • The so-called front-end architecture is more on paper, with the past software engineering ideas and concepts on their own.
  • The so-called students doing architecture are mostly showing off their technical depth and vision. When they see cutting-edge technologies, whether they are suitable or not, they will make plans and push them to the business to achieve their KPI
  • The “technical architecture” is nothing more than a subjective set of ideas and concepts that form a seemingly systematic way of organizing code so that you can say at the end of the business: look, based on how versatile and extensible my architecture is, how elegant the code looks…

Coming back to my current position, I can see that different students in the current team have two understandings and views on the word “architecture” :

  • Or, like me before, I sniffed that what’s so great about doing architecture is that the boss assigns you an “easier job” to do projects without being pressured by the business. Also have to force a line every day serious hard code code students to accept your momently thought out of the Idea.
  • Or at the other extreme, students who are engaged in architecture are considered inferior and conceptually superior to those who are engaged in business. And desperately want to lean in the direction of “architecture.”

But one day, I need to think about the lack of infrastructure from the perspective of the team and how to help the team. It turns out that the word “architecture” is neither “unbearable” nor “easy” as I expected. At the same time, there is no other people’s eyes so NB, superior. Instead, there is a growing sense of humility and even panic, and when we think about it, yes, we may have misunderstood “architecture” itself. We put a lot of executive fantasy on him ourselves.

Architecture as I understand it: the team, not the architect

The first one I want to say is this, because TA should be the major premise, if the students who are engaged in architecture do not think about problems and solutions from the perspective of the team, but say what should be done according to their own past experience and judgment. It is bound to be looked down upon, and even a drag on business and efficiency.

  • Architecture must not be just what you want, it must not be just what the boss wants, it must be what the team wants.

Before I officially took on the task of planning and thinking about the team’s infrastructure direction. Last year, I worked as a “SWAT” — literally a “flexible resource” — within the team for a period of time, supporting the team in any direction. Doing “team support” this period, participated in the various forms of business project, the production, operation, long-term and short-term, the consumer side, merchants side, front desk, attaches great importance to the content and experience background attaches great importance to the efficiency and structured, and so on a series of different projects, including some special is not transparent to the business directly. The current level of participation varies, but overall the process has made me feel one thing:

  • Can’t rely on imagination and experience to judge what the team needs? The answer must be to talk to your team, to your team members, or to engage in different forms of “them” to find out what they want.

Collecting information and questions is the first step in making decisions and plans. We all know this when we say it, but we may not be able to imagine it when we actually do it. Here’s an example:

  • You want to make a tool, make it for the new person, you have to stand in the new person’s point of view to use it, find out if it is really useful. It is important to practice TA from a project practice perspective, and not just to be happy with what works for you, because you are not a real user of the “architecture” direction yourself
  • A more typical example is front-end automated testing. The first thing to do before doing this is to figure out if the team needs him or her at the current time point and in the current team situation. And then how to land this thing at the team level. Instead of making a plan for yourself. The current team doesn’t need it, so what’s the point of refining the solution?

One aspect of the “architecture belongs to the team” view is that, as mentioned above, TA’s requirements and solutions should come from the current team. Another aspect is that the architecture’s progress and design must also be transparent and open to the team. If progress and solutions cannot be kept open and transparent to the team at all times, it will be difficult to ensure that the initial direction remains consistent when it comes to the final output.

Since the first half of this year, the content of our weekly meeting has changed a little, from the regular meeting of sharing within the team to an exchange meeting always focusing on team infrastructure construction, team development and personal development. A weekly routine, called “weekly summary of infrastructure progress and problems”, was inserted. Be open and transparent and open to discussion. Give yourself and your team a face-to-face opportunity. Make sure it is what everyone wants, and at the same time, I hope it can subtly form everyone’s sense of direction and overall view of team building.

Architecture as I understand it: it is horizontal and global

This should be the most basic requirement of “architecture”. In other words, it is necessary to keep an overall view and understanding of the whole team and the development of the whole industry. And on this basis, based on the current situation of the team to make a basic judgment of the future. “Judging” is as simple as it is difficult. It’s simply a matter of taking a few multiple choice questions and choosing something to do this year or in the near future. How can you make sure your choice is the right one for the current team? Do things in different stages.

I remember in the first half of this year when I started trying to take on the infrastructure convergence of the front end team. Combined with the current situation of last year and this year, sorted out a simple frame diagram. in”The prostrate of the front end of hand washing on the engineering road”There was Po in the article. There have been some updates and tweaks since. Roughly as follows:



It boils down to

  • Two centers (end and efficiency)
  • Eight direction
    • Base library + Functional Components +UI Framework (corresponding to “Efficiency”)
    • Extension of “end” (corresponding to “end”)
    • Specifications and engineering processes
    • A tool to link
    • Data and Performance
    • Automated testing + continuous integration
    • The front security
    • Services and surroundings

Of the eight directions, the implementation of the two centers is bound to be the focus of this year. Tools and performance were a big focus last year, and this year we’re building on what we already have. Other sub-directions will be explored this year. Due to the history and current situation of the team, there are some points that everyone is trying to grasp, but in our team, they are not the focus of this year. Such as

  • Front end separation

There are also things that are not urgent to do in the current state of the team, such as

  • Front-end infrastructure services (including build and engineering servitization, rookie systems, internal project domain names and service resource application and deployment automation.. Etc.)

The above information can be interpreted as an expression of the idea that architecture is a horizontal global. Personally, the premise of making a judgment is to know what other excellent teams are doing and what the industry is doing. It’s possible to figure out what we need to do based on the current situation of the team. However, the process of getting to know others is actually a “humbling” process.

Sometimes the more you know, the smaller you feel.

You think you’re doing a good job at something, but someone has a team with better solutions and practices.

Therefore, the “overall situation” is not only the overall cognition and judgment of one’s own team, but also the “overall situation” assessment put together by other teams.

  • Big picture means – know clearly what the team should be doing in the current phase
  • Big picture means being clear about the team’s current situation, strengths and problems
    • Not proud of lost direction
    • Also not humble to find no way out

Architecture as I understand it: also vertical and deep

In my understanding, students who “do architecture” should not simply have a “holistic view”. It is also necessary to maintain a certain “absolute depth” for each vertical area.

Taking the above sub-directions of “global” as an example, I hope that students who want to do “architecture” can maintain a certain absolute depth in any of the current subdivisions. There may be some challenges to one’s energy and resources, but I think to a certain extent it should be.

As far as energy allows, each sub-area should be involved in the whole process of scheme discussion, formulation, code implementation and team landing.

In the case of our own team, we should at least know:

  • Base library and component library, UI framework
    • What should future forms of development look like?
    • What is the automated implementation of the migration of CommonJS module paradigm? What is the code implementation idea?
    • What needs to be done to wrap module dependencies weak to strong?
    • Does the control specification need to be migrated to WebComponents?
    • If the migration, what is the specification? How to determine the polyfill set of the minimum Feature?
    • How should the Polyfill code be implemented?
    • How to reuse UI components? Visualization or command?
    • How to better manage style-lib and component-level view-lib in the MIXin section of the UI library?
    • .
  • The part of the
    • What are the current status and pain points of ReactNative? What’s the solution? What are the difficulties in code implementation?
    • How does RN’s component library organize builds? How would a component of RN be written?
    • What are the solutions to RN in terms of properties and stability? What is the status quo?
    • What is the data reporting solution at the business level? What’s the idea in the code?
    • Can you judge the future clearly and know when to hold on? When is it time to look elsewhere?
    • What is the goal and significance of GDOS? Why do GDOS?
    • What are the difficulties in docking general algorithm and selection? How to make a commercial JSON schema?
    • Even the Java part, HSF docking can also participate?
    • .

With the above examples, I put forward detailed questions in each sub-direction, and have a cognition of important details and answers in my mind, which is also what I think students who are engaged in “architecture” must understand.

In the same way,

Tool level, specification level, engineering process, performance, unit testing, front end safety, etc., expect to be as deeply involved as possible in the concrete practice and implementation. (Including the specific implementation of the code…)

To build an architecture is not to only have idea and then push others to do it. More importantly, you need to be deeply involved in order to keep a clear awareness.

This is my personal perception, not necessarily true, of course

  • “Maintain depth while maintaining breadth.”

There will also be certain challenges for personal time and energy.

On the other hand, if the “architecture” is so large that it requires a team of more than five people to support it, then it is not too late to make a reasonable division of labor.

The architecture I understand is transparent and open

In the previous statement, the reference to “architecture” at the very least needs to be transparent to the team, come from the team, respect the team, and serve the team. And the open and transparent here refers to our company, so we should be transparent and open in the company.

  • There is no need to say much about the company’s own barriers, but at least at home, we should share a blue sky.



When you do not pay attention to, do not ask, perhaps do not feel, but when there is a desire to understand some things, but found that seems not so transparent imagination.

In last week’s weekly: Not Talking about Technology, Talking about Feelings, I actually mentioned some issues about the barriers of the “technology stack” and the “technology stack”, including the team barriers of the “front end” itself.

My point is:

  • Team technical barrier is not a problem, after all, each team’s business form, grasp the direction is not the same. But opacity is a problem, and it takes a bit of work to discover the best things about other teams.

In fact, looking back, there are many ways in the group to solve this problem, such as taobao’s “lazy”, Alipay’s “Zhi Shi Hui” and so on, from the way of regular theme sharing to try to smooth the opaque problem between BU. There are also ATA technical bloggers belonging to the group level, including the front end, which also has its own committee, essentially hoping to get through the information between BU.

It seems that we have these channels and should be able to solve the problem of opaque barriers. However, as far as I really feel, there are a lot of valuable information, programs, projects, etc., which I can’t get from the above channels.

It could be a “granularity” problem, it could be a “delivery” problem. We will not go into details for the time being. To be honest, I personally feel that the most direct way to break down the agony of what I feel is a barrier is the open weekly newspaper of @Pulch.

I recently learned a lot of valuable information about airline travel, and their recent focus on the direction of their efforts is, no doubt, mostly from the weekly reports of @pulch. Of course, this is directly related to the high quality of his weekly content.

So, one of the first things I did was to publish weekly reports on the wireless front-end infrastructure, architecture direction and progress since the first half of this year. At the same time, we are willing to discuss and communicate with others with humility.

I think the weekly newspaper system inside and outside Ali is a good start. Since there is an option to choose “public”, I think it is also necessary to add the function of “weekly newspaper attention”. As long as the weekly newspaper content of the person I follow is “public”, I can receive it regardless of whether his weekly newspaper directly cc me or not.

I digress a bit, but what I’m trying to say is that I’m looking for a way to quickly and efficiently know what great people are doing.

Recently, I started to promote a project called “Path of Learning from Classics” in the team. In fact, I hope that all the students in the team can keep their mind to explore the excellent things of other teams, learn about them actively in the form of learning from classics, and then bring them back to impart knowledge and solve their doubts. I hope the team can broaden their vision and ideas from it. Meanwhile, it is also a kind of growth for the students who become “Tang Seng”.

Architecture as I understand it: The key word is not “sophisticated,” but “appropriate.”

The subtlety and depth of the word “fit” has become more evident recently. From an outsider’s point of view, to judge the quality of a thing or a technical solution should not be viewed from your point of view, even the industry’s universal standards are not necessarily acceptable. Because what you might think is biased is “right” for his team right now.

In other words:

  • In my opinion, there may be no absolute distinction between the superior and inferior technical solutions, but the historical reasons and the status quo of the team have developed different looks. As long as it’s appropriate for the current team, I think it’s fine.

Here, I can’t help but think of the “love” thing. If you put it that way, doesn’t it feel a little like being in love? In common terms:

  • The love of beauty, everyone has; Beautiful girl, who all like, you laborious mind to chase after a universally recognized goddess, this thing can become, eventually become “golden boy and jade girl” spread for ages or become “toad wants to eat swan meat” vulgar story, the premise is to recognize yourself. If the current oneself is not worthy of the goddess, then why ask for suffering, it is better to temper oneself, to one day to the peak of life to win the white rich beauty is not too late;)

The analogy may not be appropriate, but the point is made. What I want to say is that whether the technical scheme and design are good or not. Yes, it does not depend on whether the technology you use and the scheme you choose are sophisticated and cutting-edge. It’s about whether he or she fits in with your current team.

Here’s an example:

  • ES6 is currently being implemented by a number of teams and is hotly debated. It can be understood as the productization of ES6, including the improvement of peripheral polyfill and the completion of a whole set of solutions. At present, it seems to be cutting-edge, future-oriented and sophisticated. If we had a team of just a few people, if we had a team of two or three businesses, and a relatively single shape, THEN I would have no problem embracing ES6, experimenting, and playing with new technologies quickly. On the other hand, if the size, status quo and composition of the current team do not allow such a big step, then it may produce great side effects if the “pulling out the seedlings and encouraging” way is pushed forward, development efficiency and quality assurance may be affected.

Therefore, architecture and direction should not be “sophisticated”, that should not be the goal, “appropriate”, is the best.

Doing the right thing with the right plan at the right time is like meeting the right person at the right time.