1 introduction

Do 21 years of technical review, there may be a different harvest. In the whole year, we invested more in technology, from small optimization schemes to specific system designs. I don’t want to review the small technical implementation that achieved the goal, but I would like to review some of the technical construction with relatively large investment, because in the process, such projects will have a lot of problems.

2 Front-end Monitoring

The self-developed front-end monitoring system has always been my own effort. To be honest, it is very useful and has been helping the team to solve many problems. But the system has its own problems.

• Difficult to get started
• Input and maintenance costs are high
• Coexisting with the Sentry used by the team, it’s a bit repetitive
• Not enough utilization

2.1 Difficulty in getting started

First of all, because it is a full stack JS project, three databases are also used, so it is quite troublesome to run the project locally. There are few front-end students with full stack ability. If a colleague wants to participate in the project, he needs to learn a lot of knowledge in the early stage.

Front and back end functions are more, the amount of code is also relatively large, look at the code to change the code is more laborious. The SDK for collecting data on the client side is more difficult. Most of the students are not familiar with many of the underlying APIS.

In the iterative process of the project, some colleagues who invested more energy gradually became familiar with the system and could develop some functions, but lacked a global vision. Some of my busy colleagues wanted to get involved, but they ran aground due to lack of time investment.

At present, only I have the best understanding of this system, and I am constantly optimizing and adjusting it. Therefore, I am a lone Wolf in this project for the team. If I run, this project is very embarrassing, but there is no accident, I will not run, so this project has not been the leadership to dry death ~

2.2 High input and maintenance costs

Monitoring system, because the collection of a lot of data, so the frequency of use is very high, every day there are millions of data storage. During usage, performance bottlenecks became apparent, so it took a lot of time to optimize and occasionally pay attention to the space footprint of the data (we tried to keep the data as long as possible). When other colleagues use it, they make a lot of suggestions or they want certain features, and that’s the cost. But that’s not a bad thing. There are new requirements that make the system useful.

It is also due to the high cost of input, so I am cautious. Sometimes, I may often reduce its priority. If it can reach 80%, it is enough; if it can be increased to 100%, it will cost a lot of money. The cost of achieving the extreme is too high. In most cases, it still depends on the cost performance of income.

2.3 the sentry coexist

Although Sentry is getting more powerful and the company is using it all the time, it’s been able to meet a large part of the company’s needs. However, it still cannot cover many scenarios. The data collected by our own monitoring can cover a wider range and achieve more capabilities. However, the open source system is limited by developers due to its universal design, and it is difficult to carry out secondary development.

Therefore, both monitoring systems are being used at present, which is a bit repetitive and easy to distract colleagues, which is a contradiction. But it’s not without its benefits, if one monitor SDK has a problem, the other monitor can still detect it, of course, the previous problem was our own SDK, so we still use Sentry to bottom out. The functions that cannot be implemented by Sentry are delayed by self-developed monitoring, which is the current team’s consideration.

2.4 Utilization rate is not enough

Before, due to performance problems and system function design problems, I have not vigorously promoted it, because it is a little awkward to use, a little slow, you know this system, but a lot of times it does not work. Most of the time, MAYBE I go in the background and find a problem and pass it off to people; Or a colleague has a problem and turns to me. This is also related to business traffic, the more traffic, the more complex the function of the application, the need for it, last year we used monitoring a lot of C-side projects.

Let more system access, people more active use of the system, maximize the value of the system, this is the problem to be solved.

2.5 Problems and Solutions

Difficulty in getting started:

Last year, we improved the project introduction document, as long as we follow the tutorial, there is no problem, technology learning, it seems inevitable, but someone can guide, there will be fewer problems. The single point problem is difficult to deal with. To cultivate a colleague who is familiar with this system, the corresponding colleague needs to have enough energy. In the construction team next year, we need to select a deputy and stick to it.

Input cost issues:

As for whether to invest resources or not, we should consult and communicate with the Infrastructure Committee to discuss and vote on the necessity of functional investment in iteration.

Sentry coexistence problems:

This is not a big deal for now, but having another team of colleagues learning from Sentry is a supplement to the knowledge horizon, and it’s good to keep it that way.

Utilization rate problem:

At the end of 21, I have solved a large part of the performance problems and system function design problems and put them online, so NEXT year, I will be more confident in promotion. The second is to collect the suggestions from colleagues after their experience and carry out iterative optimization to cover more demand scenarios.

3 Front-end route redirection system

Because the system is put forward and the design and development of the second half, so still in the initial stage of project, the system itself, reasonable design, the prophase done their homework, the design and evaluation are seriously, so the system running and version iteration is stable, after the first iteration is himself the project owner to another colleague. Show operation will not say, redisk about the system problems

• The new owner’s ability to control the system is not enough
• Developed features were watered down by others
• Low system usage

3.1 The new owner’s ability to control the system is not enough

This student participated in the system from zero to one, and because he was serious, he learned more knowledge. He also had independent thinking. But now that I think about the system, there are still a lot of blind spots in his knowledge, if I’m not in it for a long time, the system will design problems. Although he has initiative, I think that as the owner, he has not done enough. In each iteration, I told him what he needs to do and what to consider, and I directly supplemented what he did not expect. It’s bad for his growth, and it’s a drain on my energy.

So next year, you should be more demanding of him, and you should ask more questions and guide, rather than coaching.

3.2 Developed features were watered down by others

During the second iteration of the system, NATIVE colleagues hoped that we could provide them with the ability to manage their routes (RN route, NATIVE route and WEB route). Their function is to pull the configuration through background configuration, so as to meet dynamic update. Therefore, we carried out requirement review and technical review with the technical committee and NATIVE colleagues, and finally developed functions according to the requirements. And they didn’t answer. Because another colleague on the NATIVE team, who joined later, used a different solution. I was angry, too. We put in the effort, and you said you didn’t need to use it, and you didn’t tell us, and I came across it by accident. Up theory, main is to want to know the reason, then you know the reason, of course, is not a problem we system design is not good, the last also dropped, I think you want to use it with, the function of the development there, part of this you didn’t solve the problem, the back should be applied to, are on hold, no matter it. Feel to eat a dumb loss, fortunately this function input is not particularly big, so first.

Now to review this problem, I think, either the system itself was not well designed in the early stage, or the late change plan, did not communicate in place. At present, it seems that the plan was changed in the later stage, which was not discussed by everyone and wasted manpower. The plan for the later stage was not communicated with the committee either. Maybe the NATIVE team communicated with each other internally, but this matter has already involved other teams. After I learned about the situation, I did nothing. If the problem of wasting manpower should be held responsible, I should be the most responsible person. Therefore, in the future, we should gather people together to discuss this kind of problem, rather than finding the problem and leaving it at that.

3.2 The system usage is low

Speaking of this problem, I think of the colleague who proposed this requirement at the beginning. It seems that a business system he is in charge of has not been connected, but a colleague in another team has started to use it. At present, the company has little business access to this system. If you want to find a reason:

• Due to insufficient promotion, many old businesses have no motivation for access (due to investment costs and lack of proper reasons and opportunities).
• The system is still in its infancy and someone needs to test the waters
• Most of my colleagues took time to develop the system, which was not their main job. The system iteration was slow.

In terms of promotion, I think at least most colleagues are still aware of this matter, after all, we have discussed and shared with the committee. The old business, there is no power to access, I think it is understandable, now running stable, dedicated to reform seems to be no great use, but also prone to problems. In fact, I think it is reasonable and reasonable to take over our project when there is a change in business.

The system was tested in the early stage. I think there have been some businesses running for two months at the end of this year, which is also considered as the test water completed. It can be used at ease in the beginning of the New Year.

The slow iteration of the system shows that the requirements are not so urgent. In the previous iteration, we designed the system immediately to meet the business requirements and completed the development quickly. We went online before the development of the business system. As a result, the latter business system was delayed, so our usage was low again. Well, business is bad

Finally, there is the colleague who proposed the requirements, who, as the front-end architect, also proposed the requirements for other business needs. I thought about reviewing with him to discuss the later access situation and which systems need to be accessed (because he is more familiar with the company’s business projects), but I never did it. This matter, after the review today, I think I will go to him next year and discuss this matter first. Early solution, early let the project on the right track!

Public data charting platform

I worked on the system with a back-end colleague who now has too much time to write code, and the platform didn’t iterate much after implementing a few query requirements. The biggest problem of this system is that it has not been discussed by the front-end and back-end committees. At present, I am familiar with two back-end colleagues. The system itself is quite good, but it has not fully played its capacity. I don’t know whether there are many application scenarios that need this system. It’s dark at the moment, and MY vision is limited. So the biggest problem with this system is that we need to pull it out and look at it together.

5 NODE infrastructure team

Last year, we formed the NODE Infrastructure Team. Through front routing redirection system, we found a better technology project development pattern: in combination with everyone’s effort, find one owner, pull more interested friends to join, at the same time, do not give you cause too much of a burden, the strict design, segmentation task, share each other, develop together and achieve their goals. Finally, you can export your speech to share. That’s the good part.

As the person in charge, I think the biggest problem is that the document output and abstraction of the existing results are not enough. These also cost a lot of energy, and for various reasons, I just did not complete the final summary work that should be completed. How to do this thing, who to do it, the team building is also insufficient, my energy is limited, the team absorbed fewer people, things are a little difficult to promote. I will also consider that the team has many other things to invest in, the construction of our area should not invest too much manpower, how to find a balance. Think so come down, have to pull the committee colleague to discuss again.

Not long ago, I found out that the company still has the old NODE project from 6 years ago, there is something wrong with it, the version is too low to run locally. Such projects are also very costly and risky due to refactoring. Back or found the solution to the bug, so continue to hang, let it run first. This project has been neglected for a long time, now with the team, we have to take charge of this project.

6 the end

Based on the major technical projects I have been involved in, I have made some reviews and reflections on this. Now, pulling them through, the most important thing is that there is a communication problem. All technical projects need to be discussed in the early stage, otherwise it is easy to lose a lot of thinking Angle and make a half-baked product. After the completion of development, it is also necessary to review as soon as possible. It’s not like if I’m done, I’m done. Human resources were invested in the development, but not properly used in the follow-up. It was either a problem in the early design or a lack of operation in the late stage. It creates no value and wastes the company’s money. As for the technical capabilities themselves, they may have only scratched the surface without further improvement in later maintenance iterations.